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.
However, at the time I joined the team as a senior product designer, the valuable dataset was hampered by an outdated tech stack and an information architecture that made site usage slow, difficult 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 new, faster, more organized site (assertions supported by the post-redesign analytics).
It was incredibly important to stakeholders on the company side (and the vendor side) that the site be a beautiful representation of weddings and photography.
One of the primary goals of the redesign was to make the different parts of the site feel more connected and increase time-on-site. 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.
The previous iteration of the site had developed a wide range of inconsistent styles, UX paragdigms, and development practices. I developed a new, simplified design system to use moving forward, and managed to dramatically simplify our front-end codebase.
The site had significant issues with page load times, cross-browser compatibility, and n. This was due both to tech debt over time, but also tied to early front-end design choices. A significant portion of our time was spent identifying unused code and design components, and simplifying our rails app to minimize unnecessary or inefficient database requests.
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 good for SEO, but hampered growth once B&B decided to go nationwide with their vendor and wedding database. 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. I undertook a project to help us align across teams on how we communicated with customers and referred to our product. Below, I've included a few examples.
A shared conceptual model of the 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 this.
Shared language that everyone on the team uses to describe the product.
Shared design resources so we can have a unified vision for design.
Shared code components that allow engineers to build quickly and effectively. We should strive to minimize the amount of custom code that goes into any given page, especially on the front-end.
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.
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 these features in emails and support communications.
We can Save a [Photo/Vendor/Venue/Wedding]
We should be using a consistent verbal action AND iconography across the site. Right now we have "Love this Wedding" with a heart (and incremented counting of "Loves"), "Add to Wishlist" with a star (but hearts on vendor pages = weddings, not "Loves", which is problematic). These issues will be exacerbated by the introduction of Photos. Having a single action will make the site and user actions, more clear and understandable.