THE SOLUTION

Create a modern design system with standards and flexibility

Our design team would set out to create a Design System with UI components that would be extensible and usable regardless of their placement. Since our standards would need to be applied to a larger system as-a-whole, they couldn’t be designed to be too fluid or too rigid. Not only did the design system need to accommodate the current application we were working on, but also extend to a myriad of disparate military cyber defense applications combined into a large system. Needless to say, the fit had to be “just right”.

We also needed to move fast, so we based our standards on an existing Design System while weaving in usability principles discovered from our own research. We’d also “get the map from the natives”, working with developers to understand their challenges, to speed adoption.

A STRATEGIC APPROACH

Approaching a Big Problem with Thought and Care

In previous projects, our team had experienced tension due to confusion about roles; we’d bumped elbows because proper swim lanes hadn’t been established. In this project, we worked together to decide each team member’s role so that we all could contribute using our strengths. We also created a “decision authority” framework, which established which team member had the final vote in each area of project decision making.

Before kick-off, we were able to define deliverables through team discussion. We created design sprints for each design system deliverable, and placed each of those sprints on a timeline with their corresponding team ceremonies.

In past projects, we had learned that our team’s members availability could shift at any time, so we planned for different working "modes": different ways of working that could be utilized based on who was available to work at any given moment.

“Full team mode” was initiated when all teammates were available. My role was managerial in this mode, regularly checking in on delegated tasks and guiding the design sprints against their timelines. In “Partnership Mode”, myself and another team member would work together to progress the designs. Check-ins and ceremonies would be minimal to speed the work, but our communication would remain frequent. If I lost all of my team members to other agency projects, I switched into “Individual Mode”, where I progressed the work as quickly as possible, making little time for anything else.

BUILDING AN EMPATHIC FOUNDATION

Understanding the Needs of All Involved

We wanted to take an empathetic approach to ensure that our efforts were impactful and relevant. We wanted the system to resolve real, day-to-day challenges being faced by developers. We set up empathy interviews and consulted with them before, during, and after each sprint.

A few weeks into our work, our client’s priorities changed. The project that had originally been slated for five months was reduced to two, so our strategy had to undergo major revisions if we were to complete the work on time. Timelines were changed, schedules adjusted, and a new approach developed.

We decided that we could speed production by basing our design system on Carbon’s Design System, a highly extensible set of standards developed by IBM. Along the way, we would make sure to include custom functionality and usability findings from our research where appropriate. Carbon’s principles would act as our guide, and we would create new components based on our teams’ unique needs.

DEFINING CURRENT-STATE

Building a Shared Understanding of Scope

In addition to our empathy interviews, we needed to work together as a team to understand how many component variations existed across the application. We decided to initiate a component audit, where we would screenshot and document every variation of existing components (including style variations like color, typography, visualizations, and other user interface elements).

As we worked to piece together the scope of current-state design within the application, we built an extensive collection of usability best practice research, documenting sources as we worked. We wanted to design as intentionally as possible, and this collection of research allowed us to provide a rationale for any decision that we had made within the new interface.

IDEATING WITH THE DEVELOPMENT TEAM

Teamwork to build components

As the design team worked with each other to create new components, we stayed in close communication to review each other’s work. This way, we could ensure that all design work was thoroughly vetted, and that decisions were made with proper scrutiny, including a wide range of perspectives.

We also shared designs with the development team as we worked. That allowed us to solve for issues that developers caught early on, exposing needs that otherwise would’ve gone unaddressed. Catching these concerns now would save precious development hours during implementation.

ITERATIVE TESTING

Working with developers to implement piece-by-piece

After our components were fully designed and the system approved by our client, developers began a difficult implementation process. At first, we encountered problems because the design system was iterated at a "half-step". The application’s design had gotten stuck in an “in-between” state, and started to look badly disjointed. Components continued to emerge with unexpected complexities that needed to be worked through.

It became apparent that our development team needed to create a sandbox to work through the myriad of inconsistencies that arose with such a large effort. The team created a new enclave where they could slowly integrate the design system with measured improvements. As they worked, our design team started reviewing their progress daily. We helped document any revisions needed as they worked to release more components.

Eventually, all of the kinks started to work themselves out. Our partnership with the development team had paid off, and the application continued to appear more consistent throughout.

THE RESULT

A Well-structured and Efficient Design System

Our efforts have enforced design governance and increased efficiencies by reducing the number of combined components used to create new functionality. As a result, designers and developers can focus on creating more involved workflows instead of focusing on granular UI elements.

The usability principles our team worked to develop continue to be enforced throughout the application. These standards have sped the production of new functionalities, and designing new sections of the application takes much less effort. It is estimated that our work is saving a combined 21 hours per design pattern, equalling an estimated $2,394 saved each work week (based on designers, developers, and managers paid an average of $120,000 per year in a work week in which 2 design patterns are implemented).

Using these figures, the total amount of time and pay that our client will save as a direct result of this effort is an estimated 42 hours per week, 2,184 hours per year, and $124,488 per year.

REFLECTIONS

Taking on a large, system-wide Design System project is always a politically-challenging effort. Everyone needs to have a seat at the table if the new system is to be implemented in a relevant way. Challenges arise when team decision-making authority isn’t clearly defined, especially if it’s not even mentioned at all. Taking the extra steps to enforce a chain of hierarchy can feel needless or overly rigid at first, but it’s essential in a large effort that’s apt to expose diverse and entrenched opinions.

A rock solid, structured plan-of-action can help smooth the waters, creating consensus across a range of opinions. However, disagreements are inevitable around a design system. Rightly so, there’s a lot at stake. But without a well-structured hierarchy, design teams are doomed to spin their wheels, wasting their time in endless compromises and needless hair-splitting. Vision will get lost in the process.

Plan hard, and keep planning. Creating a Design System requires just as much diligence in strategy as in creating the system’s standards themselves.

Key Learnings and Takeaways

1. Be flexible as a team lead. Don’t lose hope when the goalposts inevitably move. Pivot your strategy and continue to move forward.

2. It’s important to stay in constant communication with your team. Always be “testing the wind” when leading a large effort.

3. Make sure to maintain your situational awareness. Take care that your strategy and planning are meeting the moment.

4. Stay nimble: Be ready to shift modes and improvise when resources (time and people) start shifting.

5. Speed up adoption by recording the rationales behind your design decisions.

6. Ensure your designs are relevant by letting developers and other stakeholders have a say early and often.