Jul 23, 2014
Moving Faster by Starting Over
On learning the true cost of design debt and reimagining RelateIQ’s visual style
Hitting the Limits of Our Visual Style
When RelateIQ publicly launched in 2013, we used an image of a sunset on our homepage to signify the end of relationship management. Something new—our relationship intelligence platform—was on the horizon.
Until then our team was focused on delivering our users’ most requested features, but features alone don’t make a great product. During that time, some of our work introduced unexpected design challenges that limited our ability to create the best possible user experience.
Instead of hobbling along with a brand that wasn’t working, we stopped moving forward, rethought our approach, and solved this problem with a complete visual redesign. Here’s how we went about it, and what we learned along the way.
The Threat of Design Debt: Why We Needed a Redesign
As we designed new features within our original style, we realized that we needed a broader range of options—a secondary typeface for added hierarchy, a wider spectrum of colors for illustrations and data visualizations, and so on.
As happens so often in time-strapped start-ups, we began creating one-off styles for new components of the product—an expensive decision that increased both design and development time. Adding new button or modal styles in one part of the application introduced inconsistencies elsewhere and created a disjointed user experience. Plus, the code to support these projects was becoming bloated, slowing down the site and our release cadence. You could think of all of this as “design debt” we were rapidly accruing over time, and it was impacting user experience. We continued trying to make incremental changes to the overall style, but couldn’t guarantee that a change we made in one area would work in all instances.
For any project to be successful it needs clear criteria to measure against. For this project we needed to address: user experience, readability, usability, and flexibility (more on this to come). We knew we couldn’t satisfy all these requirements unless we balanced the books, so to speak, and rid ourselves of all that design debt before we could move forward.
Formulating a Plan
Before proposing a visual redesign to our leadership team, the design team needed a plan. We chose to begin work outside of the office because it was the only way to truly detach from the demands of our current projects and the existing design. It also gave us the freedom to explore the full realm of possibilities. There is nothing worse than trying to think openly in a room filled with reminders of the current design, as well as curious comments from colleagues.
We each gathered examples of color, typography, iconography, and UI elements that we felt aligned with our new direction, as well as samples from our competitive landscape. Unsurprisingly, we found a sea of blue, illustrations of fluffy clouds, product shots, and bad stock photography saturating the market. RelateIQ is inspiring change, and we wanted our design to reflect that aspiration.
Color: A Company-Wide Exercise
The hardest part about choosing colors is that everyone has an opinion on them. People have strong associations with specific colors—not only with the products they represent, but their symbolic meaning as well. For example, blue symbolizes trust, loyalty, and wisdom (which is probably why it is so prevalent), whereas purple (our initial brand color) typically represents power and ambition. It is often difficult for people to articulate why they prefer one color over another, but they usually sense how a color makes them feel.
For this exact reason, you might think that including the entire company in this decision would be counter-productive. We did it anyway.
We weren’t looking for consensus on color, but convincing an entire organization that rebranding is the right option is difficult to say the least. Therefore, getting buy-in was essential. The design team selected a series of 16 color gradients and 20 adjectives and asked RelateIQ employees to cast votes for the words and images that best encompassed our brand.
Everyone was a part of the process, and the team seemed to value the experience. Instead of working feverishly in secret and savoring our big “ta-da!” moment, the designers trusted the team to make our initial concepts even better. After all, the last thing we wanted was to have the organization reject the new palette after a big reveal—an all-too-common misstep in the design process.
The image that received the most votes was reminiscent of a vibrant sunrise fading from a deep blue to a crisp red-orange. We didn’t interpret this as an explicit vote for the color orange—it was about discovering which color combinations best matched the company’s vision as understood by the people who live and build toward that vision every day: our teammates.
Establishing a Shared Experience
Once we got that buy in, we fondly named the project “Pixel Wars” and converted a corner conference room into a war room. We set up shop, pinning up mock-ups and reference images. The war room not only let us focus solely on the redesign, but also gave the rest of the company a glimpse behind the scenes. The physical presence immediately lent credibility to the project, helping the entire team rally behind the designers as they pushed every pixel closer to our ultimate shared goal of user delight.
Balancing Individual Creativity with Collaboration
Collaboration is a tricky thing when it comes to design. When done right, teammates tease great work out of one another, building on each other’s ideas. When done wrong, work becomes constrained to the small intersection of tastes where all the teammates converge.
To avoid this problem, we used a general template that included all the basic visual elements in RelateIQ, including buttons, pop-ups, modals, and dropdowns (also known as a UI kit). With this template, we worked individually to produce a total of 20 versions of the UI kit with different color palettes, then evaluated them as a team.
Bearing in mind the findings from our internal color exercise, we whittled the contenders down to four design directions with some clear patterns: darker navy backgrounds for contrast, brighter teals for calls to action, and warmer tones for notifications and alerts, plus a variety of neutrals to support those primary colors.
Identifying the Optimal Path to User Delight
The criteria for evaluating work is one of the most important parts of a design project—it’s what drives designers to push their thinking beyond what simply looks good to what works best for the project at hand. Once again, we returned to the criteria we established as foundational needs:
1. User experience: Was the UI kit versatile enough to extend across the entire product, thereby creating consistency and predictability for our users?
2. Readability: Our customers use our product for long periods of time, often in lieu of their inboxes, so it was important that the contrast was easy on the eyes. If that app was bright white, it would be like staring at a light bulb for eight to ten hours a day.
3. Usability: Did the design address usability inefficiencies we’d identified through interviews and feedback from users?
4. Flexibility: Our final requirement was that the design extend across multiple platforms, including web, mobile, and marketing materials.
Based on this list, we ended up picking the best elements of the four designs to produce two contrasting versions: light and dark.
Turning to the Dark Side
Because it’s always good practice to test products on users other than designers (and in the spirit of organizational involvement), we set up the two versions on monitors side-by-side and invited a handful of colleagues in at a time to evaluate them. Since we were moving fast, and had limited resources at our disposal we went with what was available: our always helpful teammates.
We asked for feedback on the elements that were most effective given our aforementioned criteria (user experience, readability, usability, and flexibility). The response to the version with dark lefthand navigation was overwhelmingly positive. For example, people said it helped them focus their attention on the primary content area.
This feedback gave us insight into not just what looked good in our subjects’ eyes, but also the reasons why they responded so well to specific elements. It deepened our understanding of the impact of the different elements of the design.
Bringing It to Life
At this point, we had general guidelines set, opting to go with the dark version of our two final contenders. We got to work furiously applying those guidelines throughout the app in just two weeks. To make sure we covered everything, we started by taking screenshots of every possible view (including all hover states).
It was feverish work, but it had to be done right. The four of us were designing side-by-side in our war room, which was crucial to achieve consistency during rapid development. We also maintained a shared document that functioned as our working style sheet, so we were able to copy over elements from other pages with ease. Periodically, we’d print out our individual progress and tack up on the wall to evaluate how the patterns worked together, or if any adjustments were necessary. Once we agreed on any necessary modifications, we would update the style sheet and move on to the next section of the app.
No project of this magnitude goes off without a hitch, and the next transition—from design to development—is where we made our biggest misstep.
Working with Front-End Devs
While the design process was underway, we documented the new colors, type styles, etc., but neglected to think about how any of the new styles would work as a system. This would have been more valuable to our developers in understanding how all of these new styles would translate to systematically defined SASS, and ultimately CSS.
Instead, once we handed off our pixel-perfect mocks to the front-end team, they didn’t know where to begin. We were clearly speaking different languages, and it dawned on us that the best use of our time would be to sit down and define the variables together.
We started with color, assigning names to the full spectrum of colors in the new visual style and contextually defining our style declarations. So instead of using background-color $navy2 to define the color for the lefthand nav, we used background-color $globalNav with $globalNav: $navy2, which then points to the appropriate color. We continued this process to define typographic styles, icons, form elements, and so on.
darker colors in that family were followed by a negative number (-1, -2) and lighter colors were followed by positive values (1, 2…)
Once the front-end team started coding, we uncovered all the edge cases we’d overlooked. To tighten feedback loops and work faster as a team, I relocated to sit next to the developers. As we encountered outliers that didn’t fit within the system, we identified the closest match from the pre-defined variables or worked together to rethink our existing definitions.
We hammered out all of the various scenarios, then made sure to lock them down in a way that would create faster design and development in the future. Now, all of the final styles can be seen in our developer’s style guide, so there is no question as to what options are available moving forward. It’s an excellent tool to onboard new developers and ensure that all of our hard work is carried forward.
to form elements—documenting all the button and menu styles in the app.
These thoughtful decisions enabled us to change global patterns with ease, and, in the end, we eliminated 10,000 lines of CSS. Now, our infrastructure makes it easier to refactor styles in the future.
Launching the Finished Product
When the visual redesign went live, we knew all of our hard work was worth it. Not only does the new product deliver a better user experience, but it’s quicker, easier on the eyes, and a better reflection of our brand.
For those of you at start-ups (or even a larger companies) who are thinking about a similar undertaking, here’s the bottom line: a complete redesign is not an easy task, but if you find yourself in a similar position to ours last year, it’s worth it.
Today, we’re free to move quickly without design debt weighing us down, and we’re one giant step closer to delivering a product our customers can’t live without.
If we had to do it all over, here are the three things I’d keep in mind:
- Don’t go for the big reveal. Involving the team early and sharing our progress along the way contributed to our success.
- Work with the engineers who will be implementing your vision throughout the design process. Even though we got the engineers involved early, we should have done it even earlier. Had we been running in parallel the entire time, we would have been able to mitigate issues that came up during the implementation phase.
- It will take longer than you think. Make a reasonable estimate and then add 25-50% of the time you anticipate as a buffer.
