Creating a Pattern Library

During a three month internship at Digitec GmbH I created a pattern library for their software product family D3. The D3 products D3 Sheets, D3 Curves and D3 Elements together form a pricing engine for FX and MM trading and are used by more than 40 of the world’s leading FX trading banks. The products are developed using the programming language Scala, the user interface is designed with JavaFX and CSS.

Project Approach

Why create a Pattern Library?

When I came to Digitec as an intern, only one UX Designer was working there. Short after we were three people, and while all the Design Information was in the head of the Senior UX/UI Designer, there needed to be a Design System to make communication easier. Moreover, many special solutions were built into the software, which could be replaced by other more standardized patterns - if these were written down and their purpose defined. Here is a short list of the hoped-for improvements through the introduction of a pattern library:

• Avoid duplication & reuse proven solutions
• Increase design (& code) quality due to the elimination of special cases
• Simplify communication between team members
• Ease onboarding of new team members
• Avoid misunderstandings between developers and designers

Research & Comparison of Pattern Libraries

After the decision was made that the product family should get a pattern library, research was the first thing to be done. I compared various pattern libraries and design systems from other companies:

• Material Design
• Human Interface Guidelines - Apple
• Lightning Design System
• Mailchimp Pattern Library
• otto.de Pattern Library

Moreover, I also researched how a pattern library can be structured and what existing concepts exist. I list a few of the most inspiring ones below.

• “Design Patterns” chapter in the book About face
  • Postural patterns: can be applied at the conceptual level and help determine the overall product stance in relation to the user.
  • Structural patterns: solve problems that relate to the arrangement of information and functional elements on the screen.
  • Behavioral patterns: solve wide-ranging problems related to specific interactions with functional or data elements.
• Atomic Design by Brand Frost
  • Atoms: Atoms are the basic building blocks of matter. Applied to web interfaces, atoms are our HTML tags, such as a form label, an input or a button.
  • Molecules: Molecules are groups of atoms bonded together and are the smallest fundamental units of a compound.
  • Organisms: Organisms are groups of molecules joined together to form a relatively complex, distinct section of an interface.
  • Templates: Templates consist mostly of groups of organisms stitched together to form pages.
  • Pages: Pages are specific instances of templates. Here, placeholder content is replaced with real representative content to give an accurate depiction of what a user will ultimately see.
• Otto Pattern Library by Wolf Brüning
  • Fragments (no actual patterns): Standard colors, fonts, icon(-font), sizes
  • Content: Patterns for the presentation of content
  • Outline: Patterns for structuring and organizing content
  • Interactions: Patterns that enable direct interactions of the user
  • Form: Patterns needed to build forms
  • Status & feedback: patterns that communicate the system status to the user
  • Layer & Popup: Modal dialogs & pop-up windows

None of the existing concepts seemed to be a perfect fit for our purposes. Therefore, I developed a new concept primarily based on Atomic Design, but extended for our purposes. I will describe the exact concept below using the practical implementation in the paragraph “Creation of the Pattern Library Documentation”.

Abstraction of the softwares patterns

The first step for actually creating the Pattern Library for Digitec GmbH was to thoroughly explore the products of the D3 product family and write down every recurring element. While doing so I assessed all of them and asked myself: What task(s) does this component fulfill? Which problem is solved by it? While some Patterns were really obvious, like Buttons and Checkboxes, others where a little more hidden and this work of abstraction also showed some cases of several patters solving the same problem that should than be unified.

During the process and since the Pattern Library is never fully finished also afterwards, there needed to be a guideline how to deal with candidates that might be added to the Pattern Library:

The new element...

• has no advantage → use an existing pattern
• has a clear advantage and can be used in other places → record as a new pattern
• has a clear advantage but canʼt be used in other places → accept as deviation
• is a better solution and can replace other patterns → include in Pattern Library, successively replace the old/other pattern

Creation of the Pattern Library Documentation

Since the goal of the Pattern Library was to ease the communication between different departments (like UX Design and Development), I decided to use the existing internal documentation Atlassian Confluence to create the Pattern Library. This way it is easily accessible for every colleague and no additional software is needed.

The Pattern Library was created in itʼs own space in Confluence having a landing page and navigation sidebar. The space was than split into the different parts of the Pattern Library: Design elements, Atoms, Molecules and Organismns. Later we added Processes and Guidelines because we noticed that there were more higher level patterns that need to be represented in the Pattern Library as well. I will go into detail about every category below.

Design elements

= the basic building blocks on which the rest of the patters are built.

Strictly speaking, these design elements are not patterns, but they are still an important part of the Pattern Library, because everything else is build on and out of them. They are colors, fonts, icons, cursors, appearances (such as shadows) and graphic elements (such as backgrounds) used in the software. In the Confluence documentation each different design element category has one page listing all the elements.

Atoms

= GUI items that canʼt be broken down further than into design elements.

Since there are a lot of Atom patterns in the product family, I have further subdivided them into the following categories (based on the book “About face”):

• Imperative Controls: Atoms that initiate an action/function, e.g. Buttons
• Selection Controls: Atoms used to select options/data, e.g. Checkboxes
• Entry Controls: Atoms that are used to make inputs, e.g. Textfields
• Display Controls: Atoms that change how the program is displayed, e.g. Toggle Selectors
• Navigation: Atoms that are used for navigation within the program, e.g. Accordions
• Explanation: Atoms to serve as an explanation for the user, e.g. Hints
• Indication: Atoms that serve as a reference for the user (iconographic character), e.g. Drag Indicators

Every Atom is has the same structure that is represented by a table. The structure as a table allows the usage of a Confluence macro that makes it possible to create a overview on the parent page (“Atoms”) where all the controls are listed with their name, preview and the problem they solve. Every Atom has the following categories:

• Preview: a clickable embedded HTML preview (created with Adobe XD)
• Problem: the design/ interaction problem the pattern is solving
• Usage: a short guide when to use the pattern
• Design specification: a link to the pattern in Adobe XD (developer preview) and if necessary additionally written down design specifications as well as a table showing all the different states of the control
• Cursor hinting: which cursor(s) are to be used with the control
• Keyboard control: specification of the usage of the control with the keyboard
• Usage in other patterns: a list of molecules that use the pattern/ atoms that are connected with it from a technical point of view
• Examples: examples where the pattern is used in the software
• Responsibility: person that is responsible/ the person to contact for this pattern. (We dropped this field at a later date, as it was never used and did not seem important for our purposes.)

Molecules

= patterns that are composed of other patterns (atoms) and design elements.

Molecules are more complicated/less abstract than atoms and occur much less frequently in software. Like Atoms they all follow the same structure, using a table for the overview page and different categories:

• Same as Atoms:
  • Preview
  • Problem
  • Usage
  • Design specification
  • Responsibility (dropped)
• Differing from Atoms:
  • Usage of other Patterns: patterns that are used inside the Molecule
  • Usage in D3: all the places where the Pattern is used

Organisms

= patterns that consist of molecules and atoms and form relatively complex, clearly delimited areas of the software.

I only identified two Organisms throughout the software. Since these are really complex constructs the probability that they are reoccuring is low. The two Organism pages follow the same structure, but are a lot shorter than the other Patterns, they only have these fields:

• Preview
• Design Specification
• Usage in D3
• Responsibility (dropped)

Processes

= patterns that represent recurring interactions/ processes.

After working with the Pattern Library for a while we added “Processes” since we were lacking the ability to define Patterns that arenʼt necessarily visible but more a description of a process/ user interaction. An example for a Process is Drag & Drop, which is possible on several places throughout the software and always follows the same rules: there is a drag candidate marked by drag indicators and several drop candidates, both components use different colors and different cursor hintings are in place.

As the other patterns Processes are structured in a table that makes up the overview parent page. But they use different categories, e.g. a Preview is not necessary since the problems arenʼt all visual.

• Problem
• Usage
• Design specification
• Cursor hinting
• Usage in D3

Guidelines

= patterns that support decision making.

Guidelines are the newest addition to the pattern library. They are on the highest level and donʼt follow any specific structure. Your goal is to define rules for a specific design problem. The two guidelines existing so far are Control States and Control Access. The Control States guideline describes the rules of usage and design choices of different control states like readonly, disabled, hover, active and pressed. While Control Access is a defined decision tree when to hide and when to disable a control.

Creation of the Pattern Library in Adobe XD

While creating the Pattern Library in Confluence, I also created a Library document in Adobe XD with all the controls. Each control is represented by a component and the whole document forms a CC Library that can be used in other Adobe XD documents. The components support responsive resizing and changing text labels in their instances. If a change (e.g. change of color or general redesign) is made in a component in the Pattern Library document it is reflected in all the documents using the component.