Jump to
Project context | Solution | Concept Design

The process is simple when a development team starts working on a project. Typically, a repository of code is hosted with a version control system. Developers then merge code into the main repository and experiment on branches.

The operational management of development teams needs to grow and scale at the same pace as the growth of the development team—though this rarely happens. As a result, countless development hours are wasted waiting for projects to be built. Without an eye on every step of the development process, slow build times can compound with flaky tests and unreliable code, ultimately leading to a massive amount of wasted development time.

My role

I joined Gradle as the Lead Product Designer and the only product designer in the company.

I collaborated closely with the frontend development team and the VPs of engineering to ensure we were building great, usable software.

Additionally, I led efforts at Gradle to establish a user-centered research practice and accessibility practice, to ensure we deliver solutions that continue to be usable, functional, and desirable.

Improving reliability with failure analytics

When developers' builds fail, it often results in low-quality code, wasted time, and huge distractions to the team.

The user-centered goal of the Gradle failure analytics tool is to uncover unreliable builds and tests across an entire codebase, quantify the impact of the problem, and ultimately diagnose the root cause efficiently.

With hundreds of developers all contributing builds to a centralized codebase, it is easy for the number of builds per day to grow dramatically. This results in valuable data that is easier to diagnose with robust filters.

Solution

The solution I designed is an "omnibar." This single, dynamic input enables a user to craft their own set of filter criteria.

Context and problem

Gradle Enterprise uses a set of filters that grew organically over several product releases:

These filters are robust, but they grew beyond what the frontend could easily support. Not to mention how tough they were to use on smaller screen sizes:

Prototype

Error states, keyboard navigation, and accessibility were core elements considered in this solution, with states and history also considered.

Selection of detailed design/components

Part of the exercise in modernizing the Gradle Enterprise filters was to overhaul the components and visual design. The goal of this initiative is to create a set of scalable, reusable, and consistent components shared between myself as the designer, and the front-end team.

These components were built to be high-contrast, utilitarian, and reflective of the technical user base Gradle is targeting. Shadow, highlight, and contrast were all used to create depth and scale in the user interface. Below is a selection of components, as well as how they came together on-screen.

Conclusion

Developers need simple solutions to find the information they need from the system and be able to take action immediately. This filter redesign brings the power and agency back into the developers' hands.