Case Study: How We Redesigned Our App’s UI in Only Three Months
Collaboration and flexibility are the name of the game
Let’s face it: The phrase “enterprise web app” doesn’t exactly conjure visions of usable, attractive software. Visual design isn’t often a priority; given finite resources and paying customers, the choice between the next big feature and improved aesthetics usually comes down in favor of the feature.
That’s true even at a company that values design like Heap, which offers behavioral analytics for websites and mobile apps, without your needing to know the data questions you want to ask before you launch. When I joined as VP of Design, it was with the recognition of design debt we knew we wouldn’t be able to fix on day one. Instead, I started a design debt backlog that we’d tackle over time and looked for opportunities where systemic progress could arise out of feature work.
Over the course of 2018 this resulted in numerous UX improvements and some consolidated styles. But it didn’t touch a fundamental problem: Our look and feel was dated, and over time — and in the absence of designers — it had fragmented into inconsistency. While there’s no easy way to quantify how the look and feel affects user sentiment or prospective sales deals, it was a concern.
So, in October 2018, I sat down with our CEO, chief marketing officer, chief revenue officer, vice president of product, and front-end engineering lead. We agreed a revamp of the look and feel needed to happen at some point, and we had a short window of engineering time on the schedule. We decided to go for it.
But our engineering window started within a few weeks and closed around the end of the year; there wasn’t much time. How could we update the UI of our entire app, from design to launch, in three months?
The process
Designing scrappy
No mood boards, no focus groups, no stakeholder interviews: We went from decision to design, fast.
But we didn’t want to design in a vacuum. Our two-person design team (me and our product designer, Ray) gathered screenshots of products that might serve as inspiration. I was intrigued by the simple elegance of Sketch’s dark mode and Blender’s forthcoming redesign, as well as Betterment’s mix of flat, bold lines with sophisticated typography and bright color, and Robinhood’s spare, technical look.
Then, we each got to work mocking up a typical Heap screen in two to three new styles. But what were the specific requirements and constraints? How would these new styles relate to our broader brand as represented on our website?
It would be bold to suggest we ignored all of that and did whatever we wanted. It might be partly true, but it would be an oversimplification. Here are the principles we based our abbreviated design process on:
- The perfect is the enemy of the good. Here, that meant reminding ourselves that any consistent, clean, modern design system would be an improvement over the status quo. Any such system, once implemented, would be more conducive to its own evolution than what we already had. A more thorough upfront design process might yield something better than a quick-and-dirty one, but the difference wouldn’t be nearly great enough to justify a more in-depth approach.
- Data density matters. Products like Heap must show far more data at a far greater density than the average consumer app. That in itself places useful constraints on the design: Because we need to let the data shine through, there’s less call for (and strong reasons to avoid) much decoration.
- Limit whitespace. Many products, especially in the consumer space, can afford to create visual hierarchy and a sense of calm via whitespace. Not Heap — we have a lot of data to display! So we had to find other ways to achieve those visual ends.
- A consistent brand doesn’t always require a consistent style. The Heap brand is well developed on our marketing site, but that visual language isn’t appropriate for the app itself. So while we took a few cues from it, we felt comfortable ignoring it, too.
- Be different. We knew we wanted something modern, but we didn’t just want to look like everything else; we were hoping to be at least a little distinct.
- Transcend current functionality. While we weren’t making functional changes, we certainly planned to do so in the future. So we needed a flexible style — one that supported our existing features and would stand up to the addition of new ones. Often, the route to flexibility is through simplicity.
- Know what you’re building. Heap is an app, not a website; a desktop thing, not a mobile thing.
Armed with five round-one options, we pulled stakeholders into a room and discussed, ultimately selecting one design of mine and one of Ray’s.
I didn’t want our final design to feel like it was exclusively mine, or exclusively Ray’s. I’m a fan of designers working in pairs when possible, as the result is often stronger than what either would come up with alone. So Ray and I swapped. He did the next iteration of mine and I did his.
This second iteration caused our two designs to converge, making the choice less about one distinct style versus another and more about typography, the style of UI elements and controls, and color scheme:
Working in parallel
So, great. We had one mockup. Not a design system. Not a style guide. One mockup. And we had engineers ready to get started. To stay within our short window of time, we’d have to work in parallel, building out the system as the engineers implemented it. That we achieved this without rancor (and with such a high-quality result) is remarkable, and a testament to how collaborative the team is at Heap. A few techniques helped:
- Collaboration, not handoff. A lot of ad hoc conversation took place on Slack, or swinging by each other’s desks to discuss details as they arose. If we — or our engineers — had insisted on highly polished mocks and specs, this would have taken a lot longer (and been a lot less fun).
- Breadth-first design and development. We created a few “hero” screens, then focused on components that exist across the app — leaving one-off UI for last or not addressing it at all, especially on less critical screens. This worked because our engineers implemented our breadth-first changes in a robust enough manner that we avoided “dark corners”: No Heap screen ended up utterly neglected by the project. Not even Settings.
- Responsive and flexible attitudes. We designed some screens and details that won’t see the light of day, and that’s okay. Likewise, the engineering team had to redo a few things based on designs we just hadn’t gotten to fast enough, and that was all right with them.
- Productive stepping on toes. Designers and engineers all got into each other’s tools to bridge the gap and avoid messy handoffs — designers worked in Web Inspector to explore style details, engineers jumped into Figma to grab our latest work even as we edited it.
- Leave some things alone. This was a re-skin. It left almost everything in its current location. It was hard to resist the temptation to move things around, but we did, and it helped tremendously.
- The engineering team consolidated as they went, for instance taking multiple definitions of the same CSS style and bringing them together so that a future change (the next day, for example) would be far easier.
- Every project involves compromise; that’s not unique here. What mattered was our ability to be pragmatic together — the corners we cut and the trade-offs we made weren’t done in isolation, or over designer (or engineer) objections. We were able to make decisions more deliberately and in ways that minimized their negative impact on the design.
Over the course of the project we refined our style and system, most notably switching from a dark purple to a light gray sidebar. That was Ray’s doing, and it took me a while to get used to it — but I love how clean and modern the result looks. And, it served as a catalyst for us to go more and more minimalist over time — to keep decoration to a minimum and let the data shine through.
That minimalism also helped us achieve the goal of a UI that feels clean and open without an overabundance of whitespace. Through incredibly lightweight cards, subtle shades of gray, simple separators, and yes, judicious use of whitespace, we created a modern look and feel that supports reasonable data density.
Preparing for the worst
Redesigns like this are notorious for their negative response: To existing users they can feel like change for its own sake. Because that change calls attention to previously ignored details, users often attribute unrelated, pre-existing issues to it as well. They might feel like the app is slower even if actual performance is unchanged, or “discover” bugs that are ages old.
Visual work is highly subjective. Inevitably some users just won’t like it — and it’s not like they’re wrong. (Because this is the internet, though, that dislike is sometimes expressed as “Your design team is incompetent and my gerbil could design something better.” The correct response is, of course, to recruit the gerbil.)
Here’s what we did to mitigate potential negativity:
- Internal expectation-setting. I was direct with the team about the reception we might receive, because I didn’t want a couple weeks’ hatred to demoralize them or endanger the project. This mostly went over fine, but there was some surprise when I said things like, “Best case is nobody notices the change.”
- Careful planning with our go-to-market teams (account managers, product marketers, and sales) to give them a sense of the context of this redesign and some time to prepare customers.
- Internal “dogfood” launch to look for bugs and to use employees as a bellwether for customer reactions.
- A three-week customer beta with surveys.
The result
We were well prepared for hatred when we launched the redesign, but we didn’t get it. The reception was overwhelmingly positive. A post-launch, in-product survey asked customers how much they liked the new look, and on average they gave it 7.6 out of 10. (If that seems low, recall that “nobody notices” was an acceptable outcome.)
That’s not to say everyone loved it. Here’s some customer feedback, both good and bad:
- “I think a good design is often apparent when you don’t remember what the old one was like. Today, I started using the new UI and so far no troubles at all…Great work!”
- “The new design looks very ‘flat’ — I don’t know how else to describe it.” (I think this is negative but am not sure.)
- “It looks a lot cleaner. Lots of whitespace.”
- “I liked the side bar the way it was before. I was able to see everything I could do without clicking.” (Absolutely true, but a trade-off we felt was necessary.)
- “Doesn’t look like it’s from the 90s anymore.”
- “I find the new font harder to read.”
- “Looks clean, but I am always a little nervous about change and not being able to find something.” (My favorite for its honesty and introspection.)
I don’t anticipate making another visual change of this magnitude for a while, but we will continue to evolve and polish what we have. We’ll tweak colors and styles to ensure affordances are clear. We’ll extend our system as new design work requires it. We’ll look at ways the system can bring design and engineering together, such as shared React components between prototypes and production. (Already Ray has created a set of multi-state Figma components; once you’ve inserted a dropdown in your mockup, for instance, you can access any potential permutation via overrides.) We’ll look for the things we missed — icons we removed and need to replace, alignments that aren’t quite right. And we’ll find the time to keep polishing. We were thorough enough that Heap has no truly “dark corners,” but there are a few that could stand to get brighter. Design is never truly done.
If this project sounded fun to you, Heap is always hiring. We’ve got fascinating problems to solve and need smart, humble, quirky people to solve them. Drop me a line!
If you’d like to read the engineering perspective on this project, check out Austin Whittier’s post, “Redesigning Heap Without a Feature Branch.”
Thanks to Raymond Liaw, Timery Crawford, and Anojh Gnanachandran for their help in editing and refining this post. Also available on the Heap blog.
