Releasing a Major UI Rewrite

Last year we rolled out a new version of our product UI. It is the official fourth large-scale UI redesign we’ve rolled out with Bonsai. Our app was first launched in 2011, so that’s a rate of a rewrite every 2.5 years or so.The latest iteration is a culmination of a year and a half of design, discovery, research, and testing, done in short bursts. Despite the long timeline, we released something we’re proud of. We did this by defining our problem space clearly, being adaptable to changes, and using new tools that helped clean up and simplify our front end.

The Problem

Why go through all of this UI trouble? As our app features increased, the space to host their names in the horizontal navigation became increasingly cluttered. With every new project we shipped, the usability expiration date of the widening top nav loomed closer:

To fix this, we decided up front to move to a vertical layout to give us more space:

When a page relies heavily on tabs, like our last UI, all of the content gets moved down the page. If a feature has sub-feature pages, then this further pushes down the main content, making it tabs all the way down.Such a style wastes valuable vertical space and forces unnecessary user scrolling. By contrast, the vertical nav shifts the focus to the content. You can ignore the navigation if you want—it doesn’t become a gateway visual space on every page before reading new content. It also helps organize information, using a familiar pattern in documentation sites: helpful vertical side navs of all of the content available.

Moving to a vertical nav could have done this without changing all of our code and CSS rules, but as threads were pulled, the problem space became bigger. Usability and lack of composability in base components. CSS bloat. HTML bloat. Crazy utility class name strings. Our original pursuit of “making more room” turned into a design and frontend debt pay down.

We went back to first principles and focused with laser vision on the problem at hand: clear up space and make navigation in the app clear and intuitive, but execute it simply and clearly.

Execution

First, we’ll look at the mess that got us here, then dive into the people and ideas that influenced the rewrite, and review the high-level process and critical tools that helped us get this sizable project across the finish line.Ready for a teardown? 👹

The Before

We could have just left our critique of bonsai.io’s dashboard UI at “it sucks,” but identifying why certain parts of the app weren’t working was imperative to making the case for spending the energy to fix it correctly.

Vague terms of “outdated” or “flat” weren’t going to cut it. We needed to be specific. Let’s take a look at some the poor old decisions we made (read: mine).

1. We lacked a hierarchical structure to ground the eyes. There was inconsistent vertical rhythm measurements between sections. The general entire-screen-bucket-stack of items awashed the page with the same colors and highlights, giving you no direction of where to look at. It lacked any good or bad first page impression. A general “meh” experience.
2. We accrued an increasingly long horizontal tab of features, which became unmanageable with the product feature roadmap.
3. There was wasted space on important but scannable details. We constantly asked ourselves on the team, “What’s the most important thing people want to first see here?” They may need to confirm some details, but it shouldn’t take up that much real estate. The importance of the item on the page should match its dashboard footprint - in other words, don’t give features that don’t matter a ton of space.
4. There was an inconsistent use of lines and grey fills (“wells”). This made focus and legibility on content difficult. This was an easy fix, but was one of those design debt issues that frog boiled all over the app since our team always had other more important tasks to focus on.
5. Items whose functions were similar (in this case, reporting on resource usage), were not grouped logically for easy eye scansion.
6. Lack of consistency with titles, subtitles, and where headings go in relation to boxes - inside the box? Outside? We hadn’t decided on a pattern to use everywhere.

The After

1. Improved horizontal navigation, with some grounding headers and just enough icons for quick scanning.
2. Established hierarchy of important information at the top of the page, with consistent vertical and horizontal rhythm. The name and account information are on the top, as well as a status indicator that the cluster is “on.” The next most important items follow: details, traffic and activity patterns, and the less actionable items are at the bottom (tenants, usage reporting, other features).
3. User and app menus placement doesn’t reinvent the wheel — they are in a location people expect: the top right. Some early prototypes of the dashboard played with this convention, which didn’t go well during user testing. We promptly moved it back.
4. Consistent labeling, minimal font choices, and predictable patterns of information surrounding the panels (title, subtitle, then action items). We decided on a pattern and stuck to it.
5. Like items are grouped together. We refactored our most used components to simplify layouts and groupings. This created bigger, repeatable layout molecules from basic component atoms.
6. Decided on a colored background with content logically grouped and wrapped in cards, and stuck with it.
7. Not everything was thrown out with the bathwater. Components whose function and design still worked were not overthought. We kept a lot of the same base styles. If it ain’t broke, don’t redesign it.

Influences

The actual redesign kickoff started in late 2018, but it was a culmination of a lot of inspiration, personal principles, reading habits, and experiences collected over many years, collectively pooled by all of the people that contributed to the project.

Usability Testing

Our primary concern for redesigning our app wasn’t “a prettier UI.” Rather, we wanted to put our effort into thinking about how to organize the app space more logically. As in architectural design, we felt the actual use of the product, as a house, should define how it is remodeled. To help us in this effort, we reorganized our feature capabilities based on the jobs they were completing for our users. After grouping these jobs in like subjects, we ran a usability test in-house with current customers, teammates, and local Austin industry folks.The results of the usability test allowed me to watch people interact with our proposed navigation, collecting data not on what they thought about the design, but what they were actually able to accomplish. To prevent our volunteers from getting distracted from details like type, branding, and complex features, I kept the clickable prototype (which I built with Jekyll and deployed on Netlify) UI simple and design-agnostic.

The study was completed and analyzed over just a few weeks. And while it wasn’t a simple endeavor, it allowed us to focus on the real problems of our dashboard and test suggested changes instead of mull or squabble over them internally.

Functional Minimalism

A loaded term in the new millennium, I don’t mean the ofttimes oppressive ‘minimalism’ comprised of an “aesthetic language through which to assert a form of walled-off luxury”—no, this was instead a dogged pursuit of all of the things present on the screen. What was the minimal amount of “stuff” we could fit onto the screen to provide the best functional value users are looking for? What’s the function of a particular line? An icon? If we couldn’t answer, then it had to go.

A trivial example is our login page. This form didn’t change much from its original layout, but one passing comp included an hr line between the email and password login and the Google SSO button.

Was the hr line necessary? No: the “OR” and whitespace do the job of separating the buttons. So, we chose the layout that kept the spacing more consistent, sans the extra line. This particular example is not just inconsequential, but completely unnecessary to mull over. It’s just a line. I consider principles like this one to be a cognitive heuristic you decide on upfront, whose efficiency value is worth the tradeoff of trying to being overly intentional about every minute decision. You don’t have to be intentional about every decision, but it pays off to be intentional about which heuristic you want to consistently employ. Without a firm and reasonable framework in place, small decisions like this can overtake a designer’s cognitive load and waste time and resources. The benefit of our functional minimalist heuristic is that it made the daily and hourly task of executing the redesign a lot less fraught and hand-wringy.

Every Choice Is Changeable

When physical products are designed, there’s no pr to make a quick change (that would make for costly recalls). But in software and UI design, we have the ability to quickly change things if they aren’t working - as long as your underlying framework is stable and relatively resistant to unforeseen bugs. In my early days, I was more precious about my UI changes. And while perfectionism is an inescapable goal, I was often reminded during this process that “perfect is the enemy of done.” I’ve now changed my view of this popular rehash of Voltaire—perfect is the enemy of testable. We have to get it in the hands of people before we can make assumptions about whether something would be good or terrible. At the end of the day, I knew our effort here was going to be better than what we already had, period. That helped lower tensions and anxiety about the risk of making so much change all at once. At the end of the day, it’s reversible if everything goes to shit—and, shipping it can tell you more about what you got right and wrong than just agonizing about it in a vacuum.

Rapid Iteration

It’s impossible to make informed decisions about visuals without visuals in front of us. In processing ideas for changes, we tried to make as many mocks and iterations as reasonably possible. We wanted to speak brass tacks about our new design rather than rely on vague assumptions about what people might be referring to. The best way to make actionable progress when working in visual projects is to point to it and talk about it. For now, our iteration tool of choice is good ol’ Sketch.

Websites and Books

A lot of small decisions were smoothed over by absorbing the advice from these books and articles over the years. This is a small list of the most important ones for myself and the team.

• Every Layout
• The Design of Everyday Things
• Erik Kennedy’s 7 Rules for Creating Gorgeous UI
• GoodUI.org
• UX Collective on Medium
• Butterick’s Practical Typography

The Buildout Tool that Made the Difference

Even with a great Sketch mockup, we needed some new tools to help us achieve a clean slate on our frontend. One of the most important moments during the rebuild was the discovery of Every Layout (ELO) by our founder, Nick.Every Layout is a site that goes deep into CSS and browser rendering concepts, stressing the importance of treating your CSS like a rendering function for your browser instead of making rules for every pixel and em on the screen. In short, it relies on the native functions of browser rendering instead of hardcoding every pixel. ELO requires some intense reading and an open perspective towards your Sketch mockups, but using the framework’s concepts helped to boil down all of our interface components into small repeatable patterns. We threw out most of our CSS and and completely restarted with a clean slate with the new lightweight library, adding just enough custom component and branding to feel consistent with our branding. The result was a huge CSS minification and built-in consistent vertical and horizontal rhythms for every section of the app.We’re really grateful for the work Pickering and Bell put into Every Layout, and consider it a cornerstone piece of documentation for everyone working on the front end.

Looking Forward

In the end, the new dashboard took much longer than any of us would have liked, but we learned a lot about our team dynamics and decision processes, and gained some great tools. Most importantly, we clarified our principles of how we approach design, which will pay dividends in the features to come. At the end of the day, all of this was in service of providing a healthier framework for new functionality.Cheers,Alli & The Bonsai Product Team ❤