The Struggle: Finding a Past Build

—

Anyone who's built a Gatsby website can easily host it on Gatsby Cloud — but in user interviews, I discovered that developers frequently wanted to find past versions of their sites. The only way to do this was to scroll down in a site's build history, often through hundreds or thousands of builds, until they happened upon the right one. I knew there was a better way.

By allowing developers to filter their site builds by criteria that's meaningful to them, I figured we could not only save people time but also provide our users with a mental model for the complex world of cloud builds.

Phase I: Planning

—

Since build filters were an entirely new concept, I brought in product and engineering partners early on to help me create a timeline for design, testing, and implementation. It was crucial to get the filtering criteria and interaction design right, so I included two rounds of usability testing and ample time for iteration.

Phase II: Ideation

—

I then began sketching early solutions, starting small with ideas for simple filter criteria like build status and author before expanding to layout and preset filter designs. I also took time to envision how the addition of filters might eventually affect the top-level site navigation.

Then it was time to jump into Figma.

Phase III: Design

—

Since this project would primarily address build filters, the existing UI for build history would largely stay the same. I leveraged Gatsby's design system to mock up simple dropdown filters for date and build type, and I experimented with displaying filter parameters in the search bar — a design pattern that appears on other developer-centric platforms like Github.

After a review with the design team, I prototyped the Figma mockups and prepared for the first round of testing.

Phase IV: Usability Testing

—

For the first round of testing, I chose power users who had experienced the frustrations of finding builds first-hand. I used six scenarios to test my design, which resulted in five key design changes for the next round of testing. Most surprisingly, the test participants were confused by the search parameters interaction, expressing a preference toward more traditional ways of clearing filters.

Phase V: Iteration

—

I turned the filter parameters into a regular search bar, along with changing the individual filters into selector inputs. Based on feedback from test participants, I added an author filter to benefit users with large teams working in Gatsby Cloud.

I also added checkboxes to the filter options, testing whether people would want to filter by multiple items within the same filter type.

Phase VI: More Testing

—

For the second round of testing, I chose customers with the most builds in the last 30 days since they'd have a large build history to comb through. The author filter was not a success; however, every single participant organically suggested the ability to filter for failed builds.

After reviewing the usability test results with the front-end engineer, I was ready to make my final round of design changes to be implemented.

Phase VII: Implementation

—

I then worked with the design team and the front-end engineer to visually refine the UI, clarify technical concerns, and develop a timeline for design QA post-implementation.

Results

—

After filters launched, I set up Fullstory funnels to measure usage and catch usability hiccups. We got great user feedback now that people were able to filter their builds, including a shoutout on Twitter (along with a suggestion for improvement). Filtering has helped to lay the foundation for a larger navigation restructure. Ever onward!