Mission Control
Designing an internal dashboard for partner management.
The Problem
Early in Button’s history, many internal tools were created out of urgency. As a result, they were often built with little attention to user experience, no documentation, and few safeguards. In addition, links to external tools were scattered without our company wiki, without any clear organization. As a result, our suite of tools became hard to discover, understand, and use.
The Solution
Mission Control is Button’s unified dashboard for internal tools. A home screen-style launchpad makes it easy to find and launch external tools, and an improved interface for partner management allow our Partner Success team to set up new partnerships quickly and effortlessly. Finally, a clear information architecture and navigation make it easy for all of our product teams to contribute new tools.
My Role
Design: I performed user research and usability tests, created user personas, wireframes, and prototypes, and held design reviews to gather feedback for future iterations.
Engineering: I bootstrapped the app, coded the layout and navigation, and built the All Partners page.
The Team: 1 PM, 2 engineers, and me
Stage 1: Understanding our users
Needfinding
As a partnerships platform, we have a lot going on under the hood. Internal tools are our primary way of managing our integrations, and each team uses a different set, with different objectives. I knew that the first step to designing a better suite of tools would be to understand the goals, workflows, and pain points of our users.
At Button, those users are our Partner Success, Partner Engineering, and Customer Experience teams. To ensure I captured the unique needs of each team, I met with members from each and conducted short user interviews, asking questions such as:
On an average day, what tasks are part of your workflow?
How do you scope your work?
What do you wish you could do that can’t be accomplished using our existing tools?
Throughout the course of these interviews, I was amazed by the complexity of the workflows described. For example, common tasks such as QAing an order required upwards of ten different tools. Equipped with pages of raw notes and hours of recordings, I sat down to organize the information into insights we could leverage to build better tools.
User Personas
I began by summarizing the key information from each interview, identifying memorable quotes, and writing user stories for each. However, I knew that even in summarized form, it was a lot to ask for my teammates to read yet another doc. So, I decided to create user personas to share my findings with the wider company.
When designing these personas, my goal was to capture the main goals and challenges faced by our teammates without overwhelming readers. When selecting stock photos, I was careful to choose images that represented the diversity we strive for at Button. Finally, I chose typefaces and colors from Button’s brand guidelines to create a reusable Sketch template for my fellow designers to use.
Once I finished creating the personas, I shared them on Wake, then printed them out and taped them up above our physical sprint board for additional visibility. Mikey, our CTO and Tech Lead for my team, took the extra step of adding catchy names to each persona, like “Chester” for the Customer Experience Manager. Now, when we kick off our work each day, we’re reminded to focus the why behind our work: That feature tweak isn’t just an extra task on the sprint; it’s a change that will save Chester 30 minutes a day.
Stage 2: Organize the Information
Information Architecture
With the personas pasted on the wall and the web, I had a pretty good sense for how and why our team used particular tools. It was obvious that there was a lot of room for improvement. Many of the teammates I interviewed mentioned that the tools they used for particular tasks were scattered across various dashboards. Without a central place to find them, they often relied on bookmarks, Google history, or even Slack channels to find these tools.
To determine how we might better organize our tools, I began by reviewing my notes for each interview and listing out each tool mentioned in a Dropbox Paper document. Then, I split them into internal tools and external tools and grouped them using the user stories I’d already written in an information architecture document.
Nearly all of our internal tools are used either for managing partnerships, setting up integrations, or debugging issues with orders, which roughly correspond to our primary user personas (Partner Success, Partner Engineering, and Custom Experience). This division made it easy to draw up guidelines for where in the navigation new tools should live.
The external tools, meanwhile, generally fell into one of three categories: communication, performance, or integrations and engineering. Given the challenges I’d observed with discoverability, I wanted to make it easy to either browse the suite or find a specific tool by name, which led me to the idea of making the homepage of Mission Control a tool launcher.
Next, I moved to my favorite method of low-fidelity prototyping: pencil and paper.
Stage 3: Design and Iterate
Low-Fidelity Wireframes
For the launchpad, I drew inspiration from the iOS home screen, which lays out apps in a simple grid. To further improve discoverability, grouped them by category and placed a prominent search bar at the top of the screen.
The navigation was more challenging. With up to four levels of hierarchy (Partners > Groupon > Integrations > Commission Terms, for example), the structure would necessarily involve some amount of nesting. As with most design problems, I knew it wouldn’t make sense to reinvent the wheel. I browsed a number of similarly complex dashboards, including Intercom and Salesforce, checked out early concepts on Dribbble, and referenced the Nielsen Norman Group’s article on Mobile Subnavigation. Based on the patterns I observed and suggestions from my teammates, I came up with three variants to test: A sidebar with pop-out menu (A), a sidebar with internal nesting (B), and a top navigation (C).
Stage 4: Get feedback & iterate
30% Design Review
I presented an interactive Invision prototype of the three variants to the team in a 30% Design Review, which–named for its position approximately a third of the way through the design process–is our first formal step for gathering feedback from stakeholders.
The tools launcher page was well-received, gathering only minor feedback on the tools to include. However, the navigation was much more controversial. Each variant had its advocates, but the strongest reasoning came out in favor of variant A, the left navigation with accordions. The sidebar is a familiar pattern in dashboards and, by virtue of its vertical alignment, more scalable than the top navigation. Given the wide assortment of tools we use at Button, I decided to lean on the side of scalability and iterate on variant A.
Having sketched out a couple of options, I made a few changes to test:
Vertical Accordions
These vertical accordions clearly indicate hierarchy without taking the user out of context, which solved usability issues with my two previous iterations.
Transitions
Without transitions, the sudden appearance of the sidebar when switching to the Partners page was jarring. What’s more, the relationship between the All Partners page and the partner-specific page was unclear. With the help of my fellow product designers, I implemented a sliding transition to address these issues.
User Testing
Once I had an iteration I was satisfied with, it was time to get fresh eyes on the prototype. I recruited Mary, the newest member of our Customer Experience team, to walk through a usability test. As a result, I made the following tweaks:
A new Partners icon
When prompted to configure a partner, Mary didn’t understand the meaning of the below icon, which we were using to represent “Partners.”
She did discover the meaning through the tooltip that appeared on hover, but I suspected that she wouldn’t be the only one confused. After showing the icon in context to a few more Buttonians, those suspicions were confirmed. So, I went back to the drawing board and created a few alternatives. Our icon set is based on Material Design, so I took cues from the other icons involving multiple users, such as the group icons:
Then, I asked internal users who weren’t involved with the project what words came to mind when they saw the below icon. Even at small sizes, users consistently responded with words such as “partner” and “relationship.” Success!
Partner Overview
As a recent hire, Mary wasn’t familiar with many of our partners, and would often look them up on the App Store to find out their purpose. To make it easier for her to learn more about a particular partner, I introduced an Overview page that displays “at-a-glance” information for each partner.
90% Design Review
Equipped with the latest prototype, I held a final Design Review with the team. The updated navigation was well-received, and aside from some visual tweaks, we were ready to implement.
Stage 5: Build!
Sprinting
With an implementation-ready prototype in hand, the final step was to build the suite. Here at Button, each team’s Design Lead works closely with their PM and Tech Lead to prioritize what goes on the sprint. We knew that it could be easy for a project like this to drag out, so we decided to put other product work on hold and focus the entire team on the project for a single sprint.
I took the lead on building the UI, such as building the navigation and tools launcher page, whereas the other engineers migrated key functionality from our existing dashboards. Clearing the sprint other distractions helped us stay productive, and we delivered the first working prototype of Mission Control within a single 2-week sprint.
Impact
Data-Driven Iteration
Considering the scope of the project, Mission Control came together quickly: A single two-week sprint for the design, and another for the implementation. In the spirit of “ship and iterate,” we didn’t stop there. Post-launch, we monitored Mission Control activity closely using Google Analytics.
A month after launch, we were concerned by low engagement from our partner-facing teams. The low number of events suggested that they were defaulting to their old workflows, even though the tasks they were trying to accomplish were simpler in Mission Control. Some of this behavior could be explained by inertia, but some fault also lay with us for failing to formally transition our internal teams to the new flows.
To address the issue, we took two steps. First, we migrated the remaining functionality from our previous dashboards and held tool-specific trainings for our partner-facing teams. Second, we added a short segment on Mission Control to onboarding. Happily, these initiatives were successful. Within another month, usage had spiked, including frequent pageviews from new employees.
Efficiency
Mission Control has enabled our team to build tools more consistently and efficiently. The navigation has successfully scaled to accommodate a number of new features, including several contributed by other product teams, and made it easy to identify potential areas of overlap. And for our engineering team, centralizing our tools within a single repository has made it easier to share context and review one another’s code.
Acknowledgements
Thank you to Yaniv Gilad, our VP of Product, for investing in our team’s ability to build Mission Control–no easy feat at a fast-moving startup. Many thanks also go out to my fellow engineers on the Insights & Controls team, for their hard work building Mission Control. Finally, I’d also like to acknowledge Nelle McDade and Patrick Lewis, my fellow designers, for their valuable critical eyes and collaboration throughout the design process.
Design Details
