Borrowed and Blue

Wrangling a large dataset of wedding photos and vendors. I worked to re-vamp the designs system and collaborated closely with our lead Rails engineer to rebuild the site with a focus on speed.

🏎 Complete site redesign reduced style complexity and improved performance
🌁 New architecture around photos increased engagement and TOS
🔎 Worked to adjust information architecture to be more scalable

Let's clean it up.

One of my first projects was a complete, site-wide redesign in tandem with a Rails re-write  (we were several versions of Rails behind). It was a challenging task on a short timeline, but I worked closely with the lead Rails engineer on the project and we turned around a faster, more organized site (supported by significantly improved post-redesign analytics).

I developed a new, simplified design system to use moving forward, and managed to dramatically reduce redundancies in our front-end codebase.

I worked closely with the engineering team to evaluate our dataset, and develop systems that provided additional relevant content, wherever you were on the site.

A significant portion of our time was spent identifying unused code and design components, simplifying our rails app to minimize unnecessary or inefficient database requests, and optimizing page-load times.

How do we utilize our data to provide something unique?

A key differentiator for B&B was our dataset of photos from real weddings...AND the vendor information. This meant that we had the opportunity to turn the inspiration phase of the wedding planning process directly into action.

To improve this inspiration --> action flow, I designed a new photos experience where couples could easily browse photos by location or venue. We already had the photos (attached to weddings)...and wedding had venues (and therefore coordinates, after our rails re-write)...and with some clever joins to optimize query speed, we could tie locations + all vendors + wedding together on photos.

Compare this experience to Pinterest, where you might find a photo of a beautiful centerpiece, but that search is completely dissociated from vendors available in the same area as your wedding venue. On B&B, access to purchase/more info is *immediately accessible*, a key value proposition for local vendors on the platform.

As a v2 improvement, we also supplemented our data by training our image set in Clarafai in order to identify the characteristics of each individual image and surface the most appropriate vendors as needed (aka, a picture with flowers should show the florist for the wedding, but not the DJ).

How can we build a more scalable architecture?

The existing data models and information architecture forced the site (and our customers) into a very siloed organization based on regions. These regions had been useful as Borrowed and Blue launched and rolled out content in different areas, but at scale, they were a huge headache. The old navigation was *very* siloed:

This kind of organization was a decent strategy for SEO, but hampered growth once B&B decided to go nationwide with their vendor and wedding database. The database models hadn't been designed with growth in mind and the entire product was essentially locked into these fixed silos. The architecture was siloed in a [location]/[category]/[profile] structure, with no ability to search between locations.

We did a significant amount of work to make the vendor models more flexible. Additionally, we rethought the the customer-facing search experience and developed a new search algorithm that took into account location/radius, vendor profile completeness, customer ratings, and more. This also involved some repositioning on the vendor side, and we built a new version of our vendor dashboard to focus on profile completeness and new features.