Borrowed and Blue took a unique approach to the competitive wedding market. With tens of thousands of images of real weddings, our competitive advantage was a massive and accurate dataset of weddings, photos, and appropriately tagged local vendors.
B&B was acquired by Zola in 2018. You can see some of my work (basically verbatim, including CSS classes) on Zola.com.
At the time I joined the team as a senior product designer, B&B's valuable dataset was hampered by an outdated tech stack and an information architecture that made site usage slow and unintuitive.
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 algorithms 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.
Of particular concern were the data models and information architecture that forced the site 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.
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 silos. Vendors wanted to be involved, but many didn't quite fit into a particular bucket, or (like many wedding photographers) were frustrated that they were being forced into one bucket, when they often traveled for work.
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. We also maintained a version of the "regions/markets" for SEO reasons.
The redesign was not simply a design exercise. Over time, the way that sales, marketing, and engineering referred to various parts of the product had become jumbled. There was a lack of language consistency company-wide. I undertook a project to help us align across teams about how we communicated with customers and referred to our product.
This is the "whiteboard diagram" illustrating how all the moving parts fit together. Ideally, each member of the company should have a decent understanding of how the company "works" as a whole.
Our choice of language when describing our product should remain consistent from code → customer. We should strive to maintain the same conventions in the database, all the way to what features are called on the front-end and how we talk about those features in emails and support communications. (Ex. We can "Save" a Vendor/Venue/Wedding, we don't "love" or "add" content.)