Unpacking Our New UI Design Process

When we founded ZenHub a few years ago, our goal was pretty simple: We wanted to bring project management close to the code, and create a seamless way for people to manage their GitHub Issues.

Those were simpler times. So it was possible for us to make meaningful improvements to the way teams shipped code simply by adding to the top navigation and embedding project management features within GitHub’s interface. But over the years, we’ve added a lot more features, from Epics to Reports. And things were starting to get crowded.

We know one of the things our users love most is that we have minimal effect on the GitHub user experience. So while it might seem counterintuitive, we realized that to continue to have that effect as both ZenHub and GitHub scale, we’d need to reimagine our placement within the UI.

In this post, we’ll peel back the curtain on what we did and what we learned.

This is unique to a business building on another platform, but it’s a tough design challenge to build a product completely within the UI of another. And as both GitHub and ZenHub have scaled, we started competing for space. The GitHub top navigation bar is running out of space for more ZenHub features—and vice versa. As GitHub continues to grow out its product features, we realized we also need to accommodate for space and heuristics of navigation.

We had also learned a lot from launching our standalone webapp in July. Because we were essentially starting the design process from scratch when we did the webapp, we started with all the features we have today, rather than adding each one incrementally. And as we looked into our usage data, we began to notice different patterns emerging. People were using the webapp differently. This was by design: We built the webapp with project and product managers in mind—people who didn’t necessarily spend all their time coding anymore. But the data told us some other, surprising things as well.

For example, when we looked at our analytics, we found that certain features performed better on the webapp than on the extension. “Inviting your team,” for example, is a feature that is prominently on the top bar of the webapp, but has been hidden on the extension due to the lack of space. We saw that there were almost twice as many people using the invite feature on the webapp, even there there were almost four times the amount of users on the extension. This is huge: ZenHub is most valuable to people when they start collaborating, so we need to make it as easy as possible for people to get up and running. So one of our other priorities was to balance features like this across the webapp and extension.

As we started design on this project, we noticed that something we could really improve was the optimization of space on the Board. There’s a lot happening with the top GitHub navigation bar and the filters that we’ve created. We needed to come up with a way to add a sidebar that suited all screen widths and gave us flexibility in adding features over time.

We also had to factor in how to make ZenHub-level navigation better. We didn’t have much of an opportunity on this front with a top-level menu, so we knew we had a lot of room to improve here. For example, although multi-repo boards are one of our most popular features, users often tell us they aren’t aware they exist; the top-level navigation seems to be a single-repo. And certain features such as Milestones or Invite a Team (which also exist in GitHub’s UI) were either hidden behind a secondary menu, which made them harder to find, or were excluded from the extension entirely. Having a ZenHub-specific navigation helps us surface these.

To help us navigate all these priorities, we used journey mapping to map out the different platforms and workflows of interacting with ZenHub. Journey mapping is helpful because it lets us identify all the current touchpoints and compare with how we might change them. Journey mapping also helps us identify opportunities, like the ability to create Issues and Milestones from any ZenHub page, which was previously not accessible.

At first, the filter bar had too many buttons and didn’t scale well in different screen sizes. The sidebar took up a lot of horizontal space, and we needed a solution that would be flexible in platforms and screens. We tried many different iterations to accomplish this. We tried to place all the filters in a single filter—but users couldn’t always remember the top-level ones. Then, we tried grouping filters thematically, but people have different mental models for filter types. From there, we showed users a lot of different options.

Ultimately, we realized we had to reorganize some of the buttons to make better use of the space.

From there, our lack of space actually became an opportunity to get creative by incorporating smarter interaction design. Using animation prototypes, we were able to test out ways to dynamically change the view area as users interacted with the Board. For example, now, we have a sidebar that collapses as the Board scrolls horizontally. While the vertical space stays the same, the horizontal space dynamically corresponds to the user’s context.

We found that having a solid information architecture was key to balancing lots of information and functionality. The rest of the challenge was to use prototypes to figure out the best way to show and hide information.

We came up with a design that balances these needs well—and best of all, it gives us room to grow. Give it a try, and let us know what you think!