A short introduction into design systems, and the first step in creating your own.

Ana-Maria Ghinita

·

Follow

Published in

UX Collective

·

7 min read

·

Dec 3, 2018

--

1

Listen

Share

One of the challenges facing us, as a design team at Infinitec, is maintaining a consistent, cohesive and captivating experience across our digital ecosystem. In 2 years we have already designed our 4th iteration of the product and with the last iteration, we have come face-to-face with some very painful realities. If we chose to ignore them this would lead us to a place where no designer wants to be, the black hole of the Design Universe — a place I call, the Frankenstein Reality. (if you want to know more about this just leave me a comment, I’m happy to elaborate :) )

Because we knew we wanted to avoid reaching that dark area of the design space we embarked on a journey of product discovery, retrospective, analysis, and synthesis. One that would help us learn from our own mistakes, and improve the development of future iterations of our product.

We started off by asking ourselves a series of questions (inspired by our friends at UXpin) such as:

• Are we always happy with the speed of product development?
• Do our interfaces share the same design patterns, colors, typography, and other styles?
• Do we always have enough time to deliver a quality product to meet KPIs?
• How much time and money do we spend on redundant design or code tasks?
• How much time and money do we spend cleaning up design or technical debt?

The painful conclusion was that our iterations always failed to bring a positive answer to any of these questions and this meant, just like Karri Saarinen says, that we needed to innovate not just on our products but also on the way we built them.

This being said, in the last 3 months my team and I decided that the solution out of the Frankenstein Reality was a design system — in other words a centralized hub for showcasing our design rules, principles, and frontend components; a place for people familiar with the Infinitec ecosystem, and for anyone wishing to learn more about our work. And we named it Aurora.

The system is specially created for applications that satisfy financial and banking requirements and is committed to improving the experience of users and product designers. Taking advantage of unitary specifications, Aurora makes design and prototype more simple and accessible for all project members, which comprehensively promotes experience and development efficiency for our applications and products.

At the moment Aurora is not open to the outside world, however, the process we take on a day to day basis to create and expand ‘her’ is not a secret and I am happy to share it with you all.

Let’s talk about foundations

And I don’t mean the ones girls put on their faces before applying their makeup. I mean those basic guiding principles that all design systems should have regardless of the technologies and tools behind them. These guiding principles have already been defined on the designbetter.co website but I am enumerating them again bellow nonetheless:

• Consistency. The way components are built and managed follows a predictable pattern. It comes without saying that the first, most important task is to define the rules of your system, document them, and ensure that everyone follows them.
• Self-containment. Your design system is treated as a standalone dependency. And lives in a source control repository independent from your main codebase.
• Reusability. You’ve built components so they can be reused in many contexts. In other words patterns need to be modular (components are self-contained with no dependencies), composable (components can be combined to create new patterns), generic (components can handle multiple use cases), and flexible (components can be tweaked and extended to work in a variety of contexts).
• Accessibility. Applications built with your design system are usable by as many people as possible, no matter how they access the web.

Let’s talk about structure

A design system is more than just a style guide or pattern library — it’s the blueprint for product development. All the design principles, visual assets, and patterns are thoroughly documented. All code references are included for each piece of design. As a result, design can scale right alongside development.

It too just like anything else in the product development process has a structure and it’s 3 main groups are:

The Building Blocks — in our particular case these can be customisable depending on the partner;

UI Patterns — there are the elements that from experience we have found fit the best within our product and our application and are the bare minimum when it comes to building it;

The Rules — these we introduced to help partners that want to create their own FE based application and would like to have some guidelines and best practices that help them achieve this goal faster and better, and keep them away from reinventing the wheel;

Once the foundation and the structure are in place you can start building your own design system and here are the 5 main steps, outlined by our friends from uxpin, and these you can use a reference, in your design process:

1. Create your interface inventory
2. Get buy-in from the team
3. Define your design principles
4. Unify your visual design
5. Create your interactive component library

Step 1

Now that we have understood all that, we are ready to start. And today I am going to describe the first step that we took on this journey and what we looked for.

To begin the process of scaling our design operations with a design system, we had to understand the current state of our design and development ecosystem. The first step towards that is building an inventory of all the different patterns, colours, text styles and assets used in our product so far, and bellow is a checklist that we used to start our inventory:

Create the Patterns Inventory

• Take screenshots of design patterns/ collect design patterns from design projects, to form an inventory of all the different versions of patterns
• Check the frontend code and/or talk to developers about the architectural approach used across the codebase.
• Identify if we can use FE architecture (if it is modular) to categorise patterns in the inventory
• Categorise patterns in the inventory using categories from the architecture

Create the Colours Inventory

• Traverse the code files and list all the colour variables and/or all the colours used in CSS files
• Take note of the number of places where a particular colour appears
• Organise colours by a common denominator. Can be hue, shades, tones and tints or simple by similarity (all the greys, reds, greens etc.)
• Sum up the number of different colours, colour variables and take note of interesting anomalies (such as the number of different shades of grey)

Create the Typography Inventory

• Walk through the UI and check all the text styles through a browser console.
• Take notes of any inconsistencies in text styles in one project.
• Form a typographic scale by ordering text styles in the order of the informational importance (from h1 to small text). Create multiple scales if necessary.

Create the Icons Inventory

• Identify all the icon libraries used across the product
• Mark inconsistencies across the icons (e.g. two icons from different families used in one UI, two similar icons assigned to different actions, two different icons assigned to the same action etc.)
• Check if there are different ways of implementing icons across the product portfolio

Create the Space Inventory

• List and document grid systems used across the product portfolio
• List existing grid breakpoints for responsive UI
• Identify existing grid behaviour — fluid vs fixed grids
• Identify and document, column, gutters, padding and margin patterns
• Investigate the need of having a gird unit and a common scale

Create the Data Visualisation Inventory

• Identify all the graphs used across the product
• Mark inconsistencies across the graphs
• Check if there are different ways of implementing data visualisation across the product portfolio

Create the Navigation Inventory

• Identify, list and document all navigation types (Menus, Breadcrumb, Tabs, Steps, Pagination)
• Identify the behaviour of these types of navigation on different screens

With this checklist in mind we printed out all 200 screens of our application and my design team and I embarked on a 1 week workshop observing, analysing and writing down everything that we found. It’s not a surprise that we found many inconsistencies: different components for the same pattern, a very large number of text styles, and colour palettes used randomly throughout the application, just to name a few.

We used the conclusions and results of this workshop to put up a presentation for the FE Team and later on for the Business and Product Teams to argument our decision of needing a design system.

Further reading suggestions:

Thank you for reading! Until next time!