03 05 2020

Design system principles

Reviewed a list of design system sites today.
Google’s Material
Lightning for Salesforce
Fluent by Microsoft
Polaris for Shopify
Photon for Firefox
IBM design language
Australian Government Design System
Nachos for Trello
Not super strict, but mostly these are design systems that aim to support multiple apps, tools and services on multiple platforms.
I specifically looked at:
The guiding design principles: which ones and why
Top level sections for exploring the full system
Top level sections
Can be short on this: a quite consistent pattern of entries for “Getting started, Styleguide, Resources/downloads. What’s behind there varies a lot in depth and quality, mostly depending on the size of the organisation behind it. IBM goes very deep, Nachos understandably less so.
Design system principles
The most common pattern is to list a noun or short statement that expresses a characteristic of the type of designs the system wants to support. “Clarity”, “Empower but dont’t overwhelm”, “Universal”, “Engaging and immersive”, “Approachable”, etc. Material only lists 3 high-level ones but has more per section below. Nachos maybe goes a bit long with 10.
Not many of the systems listed mention content, text, words as an important part of a design. Shopify says: “Thoughtful, consistent interface content is a core element of a well-designed user experience.” IBM puts “Defer to content” as the first guiding principle for their visual design guidelines.
Even less mentions of designing for people. This may be inherent to what these sites do: describing the aspects of the system itself. Most of the times the human centered part is put under a usability or accessibility section further down the hierarchy.
One interesting outlier
IBM design language takes a different approach. Instead of listing the high level characteristics the systems aspires to, it defines 6 universal experiences:
Discover, try and buy – Meet users where they are. Show, don’t tell. Create a seamless transition from “try” to “buy.”
Get started – Invite users in and show them what they can do.
Everday use – Users should get personal value every time they interact with your product.
Manage and upgrade – Upkeep and receiving the newest improvements should be as elegant and predictable as using the product every day.
Leverage and extend – Everything wants to be mashed up. Each part of your offering should be available as an API.
Get support – Support users in the ways they want to get help. Expand their knowledge and encourage them to share.
These put user-centered design center stage, using a life cycle approach. It acknowledges that there are different stages in familiarity with the product and identifies different clusters of scenarios and tasks. Everyday use is something else than Manage and upgrade. Different frames or lenses for looking at the same product(s). This also implies that the same app, product, or even a single new feature has to worked on from all these perspectives.
Thinking about first time use (getting started), regular use (typical tasks), advanced use (extending, customizing) and managing/upgrading are all very relevant perspectives on how people work with Drupal maintenance support plans. One example: “Getting started” currently gets special attention, see improving the Drupal maintenance support plans evaluator experience.

Tags

drupalplanet

Source: New feed