Design systems are a way of keeping design & development teams aligned on approaches to certain UI elements of design. So that elements can be standardised and reused across a website or even different platforms.
Some of the benefits of this are that people are not redesigning the same elements over and over, and that the user gets a consistent UI experience across a product. To get an understanding of how design systems are currrently used this article explains them well. Some companies look to what is out in the wider world as to best practices and things that work well to leverage into their design systems such as date fields vs date pickers.
However design systems are foremost for the benefit of the designers and developers and not the end users. Perhaps understandably so as the are the ones that use it, but should it be the way?
Design systems are not a new concept they can be traced back to general systems theory and Ludwig von Bertalanffy’s work.
If the design system was for the end user of the product how would it differ what additional elements would be included?
What does the Customer want from a Design System?
Here are a few ideas:
- Consistent simple understandable UI
- Consistent Language
- Consistent Interaction Models & Flows
That consistancy is worth considering, and not just within your site, but across similar sites. Small differences are ok — but for instance users do not to necessarily seperate out a BA Flight booking from Swiss — they expect them to work in a similar way — its doing the same task.
When the UI patterns and interaction models are different it requires more thought and cognitive processing to understand how to use it, and this can introduce user errors where things don't follow the familiar model for them.
Consistent Interaction Models & Flows
The next potential pitfall is where things look the same but behave differently calendar date picking is a good example where there lots of variation in the design but often look the same you can end up selecting the wrong dates very easily, the graphical element of the UI is only part of the story and this is where most design systems are focused.
Another example is that I often expect the same interaction across Apple products, why shouldn't the interaction model of the App Store behave in the same way as Safari or iTunes.
Apple App Store example
When I use Safari the fastest way to go back to the previous screen screen is to swipe the magic mouse or swipe the touchpad on the laptop back however this interaction does not work in the App Store or iTunes. Instead to go back there is a variety of interaction behaviours required of the user to achieve this.
Selecting or going forwards is well established its a click or a tap.
In my mental model, back = swipe back on mouse or pad.
Why put interaction models into the design system?
These interaction models are repeated across websites and in apps to bring the same consistency of user experience, the design system seeks to provide a centralised resource for development and design teams to standardise around the UI. Why limit this to just the graphical elements as the interaction behaviours are just as important and fit side by side.
Another user centric way of looking at this is to make a list of tasks and interactions the user has with the site. (user stories)
What steps does the user need take to carry out the action?
There are generally a few key interactions that the user has with a website or app that are not always handled by the system UI such as:
- Entering Information
These interactions are often repeated over an app or a or website.
The same thinking is why Apple standardises gestures to provide that consistency of experience for the user and comfort and reassurance that comes with familiarity.
Further reading on consistency on interaction models in this article at UX Matters