Building & maintaining UI components with a Design System, Part 2

A design system is a collection of building blocks, design principles, and tools that enable teams to create outstanding user experience the Dynatrace way.
Today I will focus on one fundamental part of the Dynatrace Design System: how we create, maintain, and use UI components as building blocks for our product. In case you missed it, be sure to read our earlier blog post, Introducing the Dynatrace Design System: How we scale up high-quality UX, Part 1, before continuing.

Why do we componentize our UI?

User interfaces can be broken down into UI components, which are parts that can be reused on every page. Besides the underlying layouts of a user interface, these components build the basis for user interaction. As “making the user feel in control” is one of the major aspects of good user experience, consistency in style and behavior is essential. Creating consistent UI components isn’t only about a visually unified and professional presentation of our product across the whole user journey, there are many other benefits:
  • Consistent UI components reduce cognitive load for users. Therefore, more attention is on our content. Using consistent interfaces is usually faster because users don’t have to learn something new every time they use our product.
  • Using an interface that feels familiar is less likely to result in user errors.
Based on this, the development of user interfaces needs to be set up in a way that ensures and supports consistency. As design updates are now more frequent, a well chosen setup enables rapid implementation of updates across the entire product, all web entities, and design resources. Therefore, part of the Dynatrace Design System is an Angular library that contains our core UI components. This, however, doesn’t mean that every part of our user interface is a core UI component. There are use cases where things should stand out and therefore need to be presented differently, in both visual appearance and behavior.
core component vs. custom implementation
While the input field is a core component, there are custom implementations only used on one view.

How to get started

To get started with a component library, it makes sense to roll-out a set of standard components (for example, button and form components like checkboxes, input fields, and selection controls) and continue from there. For us at Dynatrace, starting with a library of all components didn’t fit our agile-based development approach. We created new components as the need arose. Everytime we create a new component, we decide if the component should be a core component for our Design System. Depending on the use case (is the component specific to just one view, or will it be used in multiple views?) we decide whether or not to add it to our Design System. Adding new components often results in updates to existing components so as to guarantee a consistent user experience.

What makes a good UI component?

A UI component is defined by its specific style and behavior. Often, it’s also connected to a specific use case.
The visual appearance of a component is tightly coupled to its behavior and can’t be separated or redefined.
Changing the behavior of a component can be tricky once people are already familiar with it. Unexpected behavior leads to frustration and errors.

What about mobile?

The web is responsive and so are its interfaces. Responsive interfaces must be built upon responsive components. This means that components can have one specific style while being responsive.
The Dyntrace table component on different screen sizes
The Dyntrace table component on different screen sizes.

Pair-devsigning

Avoid spending too much time getting to the perfect solution. Small, fast iterations that include both design and development are preferable. Coded components can be tested and enhanced progressively, as they’re used in additional views. As design files and implementations can run out of sync with one another, be aware that a single source of truth is needed. For us, this is our codebase, because our users don’t care what’s in our “Sketch App” file.

Common UI patterns

Designing a new component that blends into the product UI can be a challenge. A good basis is to define the bits and pieces that all your UI components have in common. Often it’s the small things that make your UI unique. For Dynatrace visual design, this includes a 3px border-radius, Bernina Sans regular font, and our color theme. Other common UI patterns include the structure and layout of pages, animations, and the behavior of UI components.
Example for a pattern description.
The alignment of buttons is one of our patterns.

Create a checklist for your components

While focusing on a single component it can be difficult to keep track of everything. To make sure you don’t miss anything, create a component checklist. Here’s what ours looks like:
  1. What’s the components use case?
    Table: present, sort, and compare data.
  2. How does the component behave?
    Table: the number of columns can be dependent on the screen size. Rows may be expandable and contain additional details.
  3. How is the component’s behavior or use case different from that of other components?
    Table: in contrast to a simple list, the table holds multiple columns that can be sorted. The table is used for comparing large amounts of data.
  4. Can this component adapt to one of the following corner cases? First time user, pro user, reaction on errors (validations and feedback), empty state, loading state and huge amount of data.
    Table: Yes, the table reacts to errors. Yes, dedicated empty and loading states are defined. The table component can be paged and there are tables that allow multi-line content (for example, for Database statements). Otherwise content needs to be abbreviated, the overflow can be hidden in an expandable row.
  5. Can this component be combined with others? How?
    Table: Yes, the table is often combined with buttons (in each row) and a filter field for filtering the table entries.
  6. Does this component support keyboard interaction?
    Table: Yes, navigating through the table rows as well as expanding and collapsing expandable rows can be done by keyboard.
  7. Are there any accessibility improvements to consider?
    Table: Yes, but this is highly dependent on the type of table. Information about advanced keyboard navigation and aria attributes can be found here. (https://www.w3.org/TR/wai-aria-practices-1.1/)
  8. How does the component react to different screen sizes?
    Table: the number of columns shown is dependent on the screen size. Rows can become expandable on small screens.
  9. Are there multiple versions of this component?
    Table: Yes, a default, an expandable, and a version with actions.
  10. Is the component themeable?
    Table: No.
  11. Are there any animations to consider for this component and what do they look like?
    Table: Not the default one, but the expandable rows.

In a nutshell

Identifying, building, and maintaining core building blocks for a Design System is a challenge. Start with defining what makes the UI unique. This definition of UI patterns assisted us in shaping new UI components that blend perfectly into the existing product UI. An Interface where every component has a specific styling, behavior and use case. Create a checklist that helps you get your UI components ready for production. A great set of components is the basis for creating amazing user experiences!

Stay updated