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.
Web, iOS, Android
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 bucket, or (like many wedding photographers) were frustrated that they were being forced into one bucket, when they often traveled for work.
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 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. Every member of the company should have a good 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.)
This is an interesting question for us, since we have a well-defined audience that goes through some very clear emotional changes. We need to think about how we tailor features and communications depending on what part of the wedding planning process our audience is in.
Early couple interactions (homepage, social, photos, signup/onboarding, intro emails): We want to be light, inspirational, and overtly humorous at times. Couples are still in the 'honeymoon' phase -- inspired, excited, and bubbly.
Later couple interactions (transactions, vendor communications, troubleshooting/support): We want to still keep our friendly tone, but shift more towards helpful and confident and lessen the humor. Couples at this stage of the process are more concerned with trust, security, and getting things done.