Design Systems Must Grow and Evolve

BlackRockEngineering
Jul 20 · 6 min read

As a client-centered technology, BlackRock’s investment management technology, Aladdin, is constantly evolving. Creating a successful design system for Aladdin is no different — it evolves over time according to user needs and expectations.

By: Yael Alpert, Creative Director for Aladdin

Design systems: A user-centered framework for consistency and efficiency

Design systems are an industry standard because they provide a common visual language that gives users clarity and consistency. Aladdin is BlackRock’s investment and risk management technology that BlackRock uses internally and we deliver externally to financial institutions, as well. The Aladdin Design system offers a common library of components, propagated across our applications, to provide a consistent look and feel to the family of Aladdin applications. An evolving design system benefits clients in many ways:

A user-centric approach to creating a visual language, with solid design principles

We wanted to ground our design principles on what we knew about our users; creating a design language that is driven by our users’ needs. We knew from the start that our users dealt with a high cognitive load and needed to navigate complex workflows on a daily basis. After conducting more user research, we distilled insights into three guiding principles:

1. “Get me what I need quickly and reliably” > Principle: Efficiency in workflow

2. “Get me from A to Z successfully, without interference” > Principle: Accuracy in task completion

3. “I want data how I need to see it when I need to see it, where I need to see it” > Principle: Clarity in data display

An invisible UI

We iterated on what this meant, in terms of visual design, and came up with the idea of an “invisible UI” that has a minimal structure, minimal brand, and minimal presence, allowing Data to come forward.

We used visual design foundations, such as color, typography, spatial systems, and more, to create a toolkit for this actionable design language.

What goes into a button?

With these principles in place, we began building our components. We needed the components to provide application owners and engineers an interface toolkit to get them away from the mundanity of designing and re-designing common elements like buttons or form fields and free them up to focus on solving more interesting software problems. By creating a centralized library of components, we would make a push for efficiency and design quality governance in building Aladdin applications.

Even the simplest component has many different details around it which requires several different practices working together under the UX roof.

For example, the process for designing a Button includes:

1. Functional specs that define how a button behaves upon interaction

2. Usage guidelines that describe when and how to use a button, as well as Dos and Don’ts. For example:

3. Parameters of the button hierarchy — we have a few types of buttons: Primary, Secondary, Tertiary, and Tertiary subtle.

4. Types of buttons that are specific to our products, such as, Destructive, Affirmative, Buy and Sell.

6. Accessibility built-in.

7. Telemetry built-in.

All of these considerations and iterations must be handled for more than 50 or so components and variations to create an actionable component library.

Evolution is key to success

With our Design System launched and implemented across over 40 commercial applications, we are already seeing signs of success. The look and feel is standardized and the user experience is improved. But this is only the beginning. This system is a benchmark and — as with any benchmark — we now seek to improve the baseline.

As users interact with our designs, we are positioned well to govern and grow our system. Adjustments will need to be made, as well as the addition of new components, added variations, and/or reviews of existing components. These changes and updates are all due to requirements and insights we get as different applications are implemented and users begin to respond.

User feedback drives evolution

Every user-centered design system must adapt and evolve according to user needs and expectations. We come to understand user needs through a variety of user research methodologies, including:

What evolution looks like: An example of how user feedback drives design

Tabs

Tabs are a common, highly intuitive means of organizing information into a clear hierarchy for users. Our original Tab component was available in two styles: classic and modern, each had the same functionality: pinning, adding, re-ordering, deleting, renaming, etc. When the number of tabs is greater than what can be displayed on the tab bar, an “overflow” solution is triggered, with extra tabs being stacked into a menu as shown below:

An imperfect solution

As users began using tabs, the overflow pattern — while common in other software packages — proved challenging for our particular user base. Heavy multi-tasking and repetitive tasks meant that the flexible nature of the overflow menu (tabs shifting in and out of the workspace depending on which tab you are currently viewing and the width of your browser window) wound up being too finicky and unpredictable. Instead, users needed a more straightforward visual hierarchy and mechanism.

Tab Bar: tabs revisited

We realized that we needed a tab solution that was simpler to use while still remaining robust enough to service the many different situations in which we employ tabs, at Aladdin. We also wanted to think of ways to simplify the code and abstract tabs a bit more from the content containers.

We call the new component Tab Bar, and it has two states: Basic and Advanced.

Basic Tab Bar is static and does not allow for any functionality beyond navigating content. Advanced Tab Bar allows for all additional functionality: re-ordering, editing, adding, and deleting tabs, to name a few. For both states, we added persistent carousel navigation that allowed users to scroll through tabs via a common and easily understood interface pattern. The overflow would still be determined by the width of the container, but tabs are simply hidden as they scroll past the edge.

Aladdinized components and patterns

As shown in the tabs example, evolving our system is looking at our benchmark components and seeing what can evolve and become “Aladdinized” by creating solutions even more closely aligned to our applications and our users’ specific needs.

In conclusion

Design systems need to evolve because we learn more about our users, and applications’ requirements, and the evolving business needs.

By unifying our approach to design across teams, we propagate best practices and build efficiency into our business all while focusing design on our clients, the users of Aladdin. A Design System is an integral and evolving part of any successful software business.

blackrock-engineering

Learn how we’re solving complex engineering problems at…