Opportunity

BetterCloud was already a market leader in its space - one of the very few companies that offered IT administrators an enhanced ability to control their organization via Google Apps.

Our problem was that the platform hadn't been redesigned in years, and we were facing increased churn due to customers requiring a more updated UI with enhanced functionality.

Simply put, the product looked and felt dated and everyone agreed it was time for a facelift.

Our customer base was technically savvy IT administrators. During foundational research, they universally commented on a variety of needed improvements from site architecture to visual design.

We had a total team of two designers, and in conjunction with our front-end developers, we had to define an entirely new design system, build it out, and assign rules and usage for governance.

Preliminary Research

We performed contextual interviews where we watched users working in the current interface. From this we were able to identify specific pain points that helped us hone in on areas of opportunity as we embarked upon our information architecture. To best support our new IA, we then conducted in-person and remote card sorting exercises and task analysis with users across the country.

Establishing a Design System

In preparation for overhauling the entire product, we knew we needed to start by building the foundation of our new UI by creating a set of reusable patterns and components.

Our team of two (just me and the other designer) created epics for larger concepts (layout, navigation, typography, etc.) and then created story-level tickets for specific items with acceptance criteria.

It was critical that design used a ticketing system as we built out components, as it provided a space for collaborative conversation and communication.

We approached each component slowly, starting with the anchor of the product - the left navigation. It allowed us to standardize colors, logo, typography, spacing, and information architecture that would also set the tone for the rest of the experience.

Designing More Complex Functionality

Part of our primary goal of our redesign was to support new features and enhance functionality, so we needed to create additional controls to allow users to sort and filter in a more powerful way than they had before.

Heavily influenced by JIRA, I designed several components that allowed users to filter a column based on several selected items within a list, and then sort that column.

When I built these, I always included the general flow and function of the feature, with a real life example below that we could easily pull from for use in detailed design or prototyping.

Defining Page Types

Using this building-block approach, I systematically designed the elements > components > styles and then page types for the product and defined general examples of how they should be used.

I was particularly proud of pushing for the overlay panel / blade that allowed the user to keep some context on the referring dashboard while still performing necessary actions within dynamic cards.

Once we were mostly on board with our design standards, we built out the framework and detailed design of our individual pillars of the application and shared those with our engineers using Sketch and Zeplin.

Prototyping and Usability

We conducted extensive usability testing with users using prototypes we designed in Sketch and made interactive through InVision. It’s always a humbling process when you put something you’re sure people will fly through with ease, just to find out that they’re not as confident in a workflow as you are.

As a result of research, we were able to quickly iterate on our designs to iron our usability wrinkles, and in some cases, entirely rename parent-level navigation items that were simply unclear to our end users.

We also presented at the company’s annual customer summit, where we took the stage and talked about the different sections of the app that we respectively led. I got up on stage and was able to proudly speak to my work on the following sections, knowing that they met accessibility standards and had been thoroughly researched:

• Directory: The jumping-off point of the application, where admins search / sort / filter against users to conduct dozens of administrative actions.

• Audits: User, file and asset management as well as the place to create and manage reports, sharing permissions, and policies.

• Settings: Standard admin-level user settings & contributor permissions, integration setup, and billing.

• Help (Proposed): The in-app experience for contextual help powered by ZenDesk’s widget, mapped to our KB content inventory.

Lessons Learned

Research early and often

This was a key reason we were successful in what was a big undertaking, and it was through the regular insights from our constituents that we felt so confident in our design decisions. We were fortunate to have a lot of direct and frequent feedback from our CEO and board, and we got the chance to pivot and adapt approaches from cross-functional feedback and critique.

Don’t be a designer / writer / researcher

I think I did a decent job of being able to take my designer hat off while I was conducting research, but there is something incredibly valuable in having someone who is further away from the work write test scripts and assess the usability of your work with an objective lens.

Learn more about engineering constraints first

This was a project in 2015, and we ran into a lot of issues with relying on an existing framework. We waned to push some design conventions and make this feel like a truly enterprise product, but often ran into roadblocks between what the developers could support and with what we wanted to implement.

Burnout is real

Finally, I learned that while I thrive in having my hands on all facets of the design process, I’ll never take for granted the ability to have additional resources. It is simply too much to have two designers undertake a redesign project of this scale.