I joined New Relic as a design manager at the time when we were transitioning to New Relic One, a new product concept that would move beyond traditional monitoring and embrace observability by providing users with a real-time view of all their operational data in one place. As part of my role, I managed a team of 10 design professionals, ensuring effective collaboration with engineering and product management to build a product that met our client's needs and fulfilled the vision of senior leadership and our stakeholders.

My team's goal was to unify the existing products under one common umbrella—one that would be flexible enough to accommodate all of the diverse solutions New Relic offers today as well as any new solutions they may offer in the future. Our first step was to determine what we wanted users to be able to do with New Relic One. The answer was easy: We wanted them to be able to get up to speed as fast as possible, ask their data questions, and get answers they could trust. To achieve this goal, we first had to rethink how data was visualized in our systems and how users could make decisions based on that data without having to navigate through siloed product offerings.

It's hard to redesign an established product.

When I started at New Relic, we did not even have a dedicated team to deliver a strong set of rules, guidelines, and artifacts— components, patterns, unified SDK, etc., that we could use to build the product our users were demanding from us. We only had one designer and one engineer working part-time in creating a set of components for what we called “third-party apps”—an SDK and a set of components our users could use to build their own apps and extensions on top of New Relic. The foundations were quite promising. Daniel Guillán and Miguel Jiménez were the masterminds behind this effort, and what they built was impressive and very effective to extend the product’s capabilities. Still, we were struggling to provide these tools for internal use, and teams basically were shipping new functionalities locally, which made it quite difficult to ship the cohesive, silo-free experience we wanted to deliver.

On the product side, we had a structure in which designers were embedded in product teams, but we were lacking the needed alignment across verticals. Not only to deliver a cohesive experience for the redesign we had in front of us, but also to be able to work in the design needed to radically transform the product.

What we did:
It was pretty clear that we needed to have a team of designers and engineers working together full-time in translating the success of the third-party tooling to be used internally. I set up myself to get executive buy-in to invest on this effort by proving the pos, and together with Dani (who became the technical product manager of this team, on top of his design duties, we established a dedicated effort with three designers and three engineers to build New Relic’s first design system: One Core.

The initial investment of a design system is substantial: the research, identifying the current problems that will be solved, and brainstorming solutions to those problems with multiple teams and team members. Then there’s the time involved with maintaining the output. Finally, there isn’t an immediate return on investment.The hours spent add up pretty quickly. It’s far too easy for businesses to get caught up in this initial friction instead of seeing the broader picture.

Still, we needed to find the way of redesigning the product. To do this we established what we called Design Spikes. It emphasizes considering the problem and requirements in depth first, and then generating and evaluating potential solutions second. We appointed two of our most seasoned

“Ownership” of the design system can be confusing and even develop independently of the entire team. Designers and engineers have different views of what the so-called source of truth is. For example, designers think more in terms of user interface, user experience, and visual design, while developers think in terms of production code.So, who owns the design system? The designers? The developers? What happens when there’s turnover within these teams or new members are added?

What we did:
Everyone needs to be clear from the beginning: Everyone on the design and development team owns this system. Everyone on the team needs to be involved in the design system project, as they see things differently and bring different thought processes to the table.

Coupling the DS with our redesign effort.

We couldn’t close shop while redesigning the product. Building the design system had to move in parallel with building the product. After identifying the highest complains from our customer, we set up a course of action on which areas of the product we’d need to rethink from a design standpoint. We set up what we called “Design Spikes”, which was a way to identify the areas that where creating more friction by reviewing user reviews, and then creating an end-to-end vision for the core user experience. We involved senior leadership in the process to always check we were aligned with the business vision, as well as with the designers working in each business vertical. As a result, we delivered a high-level, pixel perfect solution with all the updates needed.

If the DS is not implemented, it's useless.

There’s sometimes a confusion between having a design system and a set of guidelines. In our case, we needed to break the product silos to provide a cohesive experience where people could navigate through content and not through modules. We developed, scaled, and maintained the design system by providing a set of foundation, a library of user interface components for designers and developers, and documented guidelines and common interaction patterns for designers and engineers.

What about accessibility?

In 2021, New Relic commissioned an external accessibility assessment which confirmed almost 2000 accessibility issues with varying levels of severity across the board. Problems range from poor focus management too low contrast text, to lack of screen reader support.

We built an accessibility foundation right at the core of the design system which will help teams build more accessible UIs out of the box —and improve the current ones out of the box, by providing components, documentation, and continuous improvements.

Among other tasks, I worked on a revisited color palette to deliver increased contrast between light and dark shades of the scale, expand the number of accessible combinations, and tweak middle shades to deliver more harmonious and perceptually uniform colors.

The palette was created using a color appearance model (CIECAM), designed to model human color perception, and take in mind the contrast levels so we could define accessible color combinations (WCAG AA and AAA levels). These changes fixed more than 600 issues on the low foreground and background contrast.

Final thoughts.

It was a massive effort that transformed the face and core behavior of the product in a record time.

You can check my contributions to the Firefox OS UI in Mozilla's Wiki →