Redesigning an API dashboard

At Pusher, we maintain reliable and scalable realtime infrastructure so you can spend your time building awesome realtime features.

We recently started to build out our in-house design team, and that’s enabled us to improve how people see and interact with our products. One of the biggest improvements we’ve made so far is to our dashboard, and it’s resulted in a richer experience for our customers. Here’s a closer look at how we successfully redesigned this important part of our platform.

Why redesign the dashboard?

In recent years, our dashboard had been slightly neglected, but it worked. So why fix something that wasn’t broken? We wanted our dashboard to better reflect Pusher’s values: being simple to use, reliable, and built with developers in mind. Did our dashboard align with this new ethos? No.

We knew that we wanted to give our customers the best possible experience with our product and not just offer the bare bones. However, we were also very aware of the service we provide for our users—we’re an API. It was a balancing act between offering our customers helpful information while not bombarding them with too many unhelpful features. As an API, the reality is a lot of customers integrate Pusher and never look at the app again (this is great).

But for those who do use the app, we wanted to understand how we could help them get more value out of the experience. We also wanted to make the onboarding experience as easy and quick as possible for new customers.

Getting started

Before we got into the visual aspects of the design, we spent a lot of time planning out the process behind the scenes.

• Who should we involve in each stage of the project? Key stakeholders?
• Which customers should we talk to, and how we will we manage their feedback?
• What’s the best way to approach the project? Content, brainstorming, wireframing, prototyping, visuals?
• What does success look like?
• What are the personas of our customers?
• How do we want to approach it from a technical perspective?

Chatting with the experts: our customers

We started by going out and talking to our customers. Taking time out to do user research can at times feel laborious, but the information you gain is invaluable. We put together some main questions that we wanted answered:

• What do you use Pusher for?
• Why did you choose Pusher?
• What would make your experience better?

Don’t bombard customers with questions. Instead, be clear about the goals and outcome you want. While a lot of the answers aligned with our thoughts, we also picked up a few interesting ideas, such as Slack notification “alerts.” After we’d gathered sufficient feedback, we had a good insight into how we could improve our customer experience.

Understanding the features and user flows

After analyzing our user research, we drew up a features list for each of the pages and considered the user flows. What was the purpose of the page? What did we want the customers to see on the page? How did this tie into the user research?

Two of the most common flows were those who wanted to get started easily and those who wanted to get a quick overview of their account usage. It was clear that our current dashboard was not addressing these needs. We came up with various solutions to address the common issues. For example, we introduced a quick setup wizard to help our users get up and running in minutes and make it easier for new users. This flow then took them to the getting started tab within the app where they could easily copy the code snippets.

Quick and dirty

Early on in the process we knew that we wanted the app to be slick and easy to use for existing and new customers. Once we were clear on the features, flows, and how we wanted to approach this, we formed a smaller, more focused team of decision makers (product manager, lead designer, and frontend developer).

We split the project into various parts to allow for more exploration. One of the first parts we worked on was the framework of the app navigation. We started by sketching up our vision for the app (roughly on a whiteboard), following on from the features list and user research. We discussed it as a group to make sure it was aligning with the project needs and was practical from a technical perspective. It also quickly allowed us to identify any potential flaws in the design or answer any unknown questions. Can we pull in the customer’s data such as their avatar, and if so, where from? How many realtime apps do our customers use on average?

Having something tangible

Once we were clear on the approach, we mocked up a wireframe to make it easier to present our idea and thoughts back to the team. An important part of the design process, wireframing allows you to really think about how the product will work, free from any design restrictions. Wireframes are quick to produce and adapt, so it makes the feedback loop quicker and less painful.

Wireframes are great, but it can be difficult to recreate genuine end-to-end interactions such as our sliding navigation or how things would load on the page. We worked on an interactive build alongside our wireframes to replicate the genuine experience. We wanted to play with it and make sure it was intuitive for our customers and would just generally work as we’d intended.

This stage is the best time to gather as much initial feedback from potential users as possible. Fail early, fail often. There were lots of features we’d included that later dropped, such as the recent activity stream, as they weren’t adding enough value to the end user.

Look and feel

Our goal with this project was to keep the design clean and simple. We’re a tech company and our designs should complement our great product through clarity. We also we wanted to maintain the fun side of Pusher, so it was a balancing act. Having 2 main colors allowed us to create individual visual identities between the connections and messages throughout the dashboard.

The look and feel were about more than just the visuals. It was important that our tone of voice also aligned with this. We wanted a versatile visual identity that could carry across all of our products and services from print to web. It was important to consider how this visual style could work seamlessly across different devices and be future proof.

Slick animations and responsive design

As mentioned earlier, throughout the whole process we were building out an interactive prototype. We like to get things into build as quickly as possible to allow people to play with the prototype, and to make sure the interactions work across devices and feel natural.

It’s important to start pulling through real data early on in the design process. As designers, we often fall into the trap of taking the ideal situation and designing for that. Making sure your design works for the worst-case scenario is really important but often overlooked.

We paid a lot of attention and time to small details, such as the way we want our elements to load in and how users can get additional information from the graphs. Adding animations can enhance the user experience and help highlight certain elements. But animations can also become a nuisance and act as a distraction, so getting the balance right was key. It’s essential to consider how animations will work across devices. We tried “cool” animations but decided to strip them back. Usability always outweighs cool.

Loading animation ideas

We opted for a slide out navigation on the sidebar to make it easier for the user to jump between and create new apps. This allowed them to access more features without having to leave the page. From the early prototypes we realized that having 2 navigations on the sidebar was taking up too much space on the page and was unnecessary. After various prototypes we managed to make the sidebars swap out seamlessly to give the optimum experience without restricting too much of the page.

Customer feedback

Throughout the design process we’ve continued to work with our customers to gather valuable feedback. We wanted the dashboard to be complete enough not to send any instructions and allow them to use it as they normally would in a natural environment. The first stage: we drew up a range of customers and invited them to try out the dashboard during the beta stage. The chances are, only a small percentage of those asked will reply and actually want to participate. Time is valuable.

The user feedback was crucial at this stage but it was also important that we understood how people were using/interacting with the new dashboard. There’s lots of great software out there that allows you to easily track, replay, and analyze actual users on your app. It’s essential to use such tools, as well as the user feedback to get the full picture. Each process will gather different insights.

Our beta session ran for a week and we felt we had enough data at this point to make relevant improvements. Being able to identify patterns in feedback early on allowed us to make prompt updates and changes while still in beta. Some of the feedback included issues with our realtime stats loading. Some users had fallen out with our determined categories, so we had issues with their usage percentage and the way we were displaying them.

Releasing it into the wild

The perfectionist in me wanted to continue to improve the final design. But knowing when the time is right to release your product can in itself be a skill. It’s often a balancing act between getting it to a good place visually and from a usability perspective, while aligning with the needs of the business. As I mentioned earlier, at the start of the project we ask ourselves what success looks like. This helps us identify when it’s the right time for us to release each project and whether we’ve met the project goals. The joy of digital design is that we can and will continue improve the design and experience.

The dashboard was released into the wild last week, and we’re continuing to work with our customers to add value and improve the Pusher experience.

This post was originally published on Pusher.