The Need for Low Fidelity

Developing a wireframe library for better design discussions with stakeholders

Design Systems

Process Design

6 min read

Background

Although an efficient method, always designing with only the components already available has its limits. Earlier this year, a handful of UX designers on the team began expressing the need for a lower-fidelity design library.

Over the course of several weeks, I worked with these designers to address the various collaboration issues they were experiencing, and came up with a solution to reduce their frustrations.

Role

Senior Product Designer, Design Systems at Rubrik

Stakeholders

UX Designers, Design Managers, UX Researchers

Timeline

April – May 2022

The problems with starting in high fidelity

1. Design reviews focused on the wrong thing

In the early phases of a project, the feedback designers are generally looking for is on the overall UX flow and page layout. So, when designers presented high-fidelity mocks during early reviews with stakeholders, the feedback often focused on minor details rather than the big picture.

I had multiple projects where design meetings would go off track because of a typo or an incorrect sentence. When going through a workflow of 10+ screens, we end up only reviewing two screens the entire meeting, because the PMs and engineers are too focused on the details.

Daniel Nguyen

Senior Product Designer, Rubrik

In addition to product and engineer collaboration, when high-fidelity designs were used in customer research studies, customers often got distracted by the intricacies of the design. This, in turn, prevented the customers from being able to provide focused feedback on the main objectives of the study.

2. Design mocks used to finalized strategy

In some cases, when the product requirements document (PRD) continued to evolve during the design process, the product manager (PM) relied on designs from the designer as discussion materials to solidify the product requirements with other stakeholders. Starting the design process in high fidelity can create a bottleneck in these situations.

In more complicated multi-stakeholder projects, product managers use design mocks to discuss ideas with other stakeholders before the design strategy is finalized. When rough concepts are presented in high fidelity, the audience might mistake them as mature proposals, which causes confusion and inefficiency in communication.

Zee Liu

Product Designer, Rubrik

3. Wireframing from scratch takes too much time

When needed, designers took it upon themselves to make wireframes from scratch. However, doing so took way longer than using already available components from the design system library. Thus, the lack of a readily-available wireframe library ended up creating more work for designers, or discouraged them from taking the extra step of rough design explorations altogether.

Creating wireframes from scratch is a bit different when working on such a diverse product. Even in low fidelity, it takes effort to get the spacing and overall look just right so that stakeholders can understand what they’re looking at. It requires a level of accuracy to create functional wireframes.

Sai Mohanty

Product Designer, Rubrik

problem statement

How can we improve the quality of product stakeholder collaboration and user research insights by reducing the workload of creating earlier phase designs in lower fidelity?

Building the wireframe library

After multiple designers on the team raised these concerns, we had a kickoff call with the relevant designers and design managers to discuss the potential solution of a wireframe library. Wireframes are essentially low-fidelity designs that represent a clear overview of the page structure, including the layout, flow, and functionality, without intricate details like colors and specific styles. The goal of creating a wireframe library was to provide designers with components flexible enough for experimentation, that also deliver the most valuable information to stakeholders.

There were three core requirements that went into building the wireframe library. We wanted the library to:

1. Contain foundational and high-need components

The wireframe library does not need to be as extensive as the high-fidelity component library, but should contain design foundations and core building blocks of most pages. These components included navigation, tables, filters, buttons, inputs, menus, charts, and placeholders for icons and illustrations.

2. Serve different use cases via varying degrees of fidelity

We wanted just enough fidelity for non-designers and customers alike to understand what they were looking at and be able to have meaningful discussions about it. This meant that the visual hierarchy needed to be maintained without the use of color and flourishes, but purely through size and contrast.

3. Map to our existing high-fidelity component library

In order to reduce the amount of work needed to transition from wireframes to high-fidelity design, the structure of the wireframe library needed to be aligned with the design system library. By making sure the same components are named and categorized across both libraries, we could leverage Figma’s feature to swap components used in a file from one library to another.

This method, unfortunately, won't work as well for wireframe mockups that explore new design patterns that have yet to be developed. In those cases, the library swapping may only be beneficial for swapping global components, such as the page header and background surfaces.

Special features of the wireframe library

With those practical considerations in mind, I constructed the wireframe library over two weeks. The structure of the library and components were kept consistent with the design system library. However, a couple of unique aspects were incorporated into the wireframe library as well.

Placeholders

To achieve a certain level of low fidelity, there needs to be the option to not include exact copy or content in the design. I created placeholder styles and asset placeholders for this purpose.

These components are unique to the wireframe library, but could also be used in high-fidelity designs to indicate a place where the icon or illustration is not yet created or finalized, and avoid using existing icons or illustrations which could cause confusion.

Content toggle

Since different projects might need different amounts of context for the wireframes to be understandable, I created two variants for every component in the wireframe library; one with content, and one without.

The default variant for all wireframe components has editable text fields and distinguishable content, if applicable. Wireframe components with content are meant to be used when real copy is needed to provide enough context in the explorations.

For wireframing work that is still in the early exploration phase, when the copy is not yet important, or the focus is only on the overall UX, the designer can toggle off the “Content” property to get the variant with placeholders replacing the content.

Atomic design approach

Not only are wireframes helpful in exploratory projects, they are also used in projects that lean on existing patterns. For exploratory wireframing work, the designer mostly needs the fundamental components to piece together a working layout. However, for projects that work off of existing layouts, the designer may want to leverage wireframes that are full page layouts.

In the wireframe library, in addition to core components, I included more complex page templates to serve as a starting point for designers in their wireframing work.

Unveiling the library to the team

When presenting new things to the team, whether it’s a new component or a whole new library, the most important question to address the audience is: how does this affect them?

After validating the wireframe library with the initial set of designers, I prepared a presentation to the rest of the team during one of our weekly all hands meetings. Keeping in mind that not every designer on the team had experienced the need for wireframes, I emphasized that the addition of the wireframe library was not to impose an extra step in their current workflow. The purpose of the wireframe library was to serve as another tool for them to utilize when needed up to their discretion.

Over the next couple of weeks after sharing the library with the team, a handful of designers started adopting usage of wireframe components in their workflows. The most validating feedback was hearing that the wireframe library saved designers time in getting their ideas out into mocks.

The wireframe library helps me get my ideas out quickly without having to spend extra time creating what already exists, so I can get feedback on my designs sooner.

Sai Mohanty

Product Designer, Rubrik

The new wireframing library makes it very clear which designs are in progress and allows me to talk more about the workflow rather than the pixel-perfect details, which should be discussed at a later stage.

Daniel Nguyen

Senior Product Designer, Rubrik

As more designers start incorporating wireframing in their workflows, I anticipate suggestions for improvements to the wireframe library. In future developments of the wireframe library, there will potentially be more robust foundational components, as well as more complex wireframe components, for designers to leverage.

Retrospective

As a designer focused on design systems work, I’m always trying to find ways to continually improve our component libraries and design processes. Although I sometimes wrestled with the concept of a low-fidelity component library feeling like a step backwards in design system maturity, what I learned from talking to designers on the team was that the lack of one was noticeably-felt in their previous work.

Having a wireframe library helps designers get ideas out into rough mocks quicker and focus stakeholders’ feedback on the right aspects during early design reviews. Wireframe components give designers a base of visual hierarchy and cohesion to work off of, instead of having to start from scratch.

Working in a team where velocity is highly valued, we often prioritize minimizing time to production. However, if every new feature had to be made using only existing components and patterns, we would be missing out on a lot of potential for innovative design. And ultimately, we want to enable designers by providing them tools that allow them to create inspiring solutions.

Check out my other work

The Great Migration from Sketch to Figma

5 key differences between Sketch and Figma design system libraries

Refactoring Filters

Improving the usability and usefulness of table filter components

Rolling out Rubrik’s UI Themes

Designing the first time user experience introducing bright and dark themes