TLDR – The Great Bluff of the Design Systems
Nowadays, talking about design systems (DSs) within the digital industry is very trendy. The definition of this deliverable as the “single source of truth for an organisation to design its products” sets expectation levels within the insiders’ community impressively high. But I feel all that glitters is not gold.
Intro
“A design system is the single source of truth for an organization to design its product”.
– Anonimous designer
The designer community is packed with profiles of self-attributing experts and design systems gurus who claim to know how to develop this lethal weapon.
After reading dozens of articles, reading a bunch of books and watching hours of talks, I concluded that, on the one hand, the Design Systems are ignored by C-level folks and senior managers. On the other hand, some “experts” use them as a smokescreen to increase subscriptions to workshops and conferences.
The undesired side effect of all this scuffle is that the design teams and the end users will receive almost no benefit from it. Let’s take the example of the financial or insurance platforms and public administration websites. The friction team experiences in developing and maintaining the platform is visible by looking at how many variants of the same components users have to deal with. Ultimately, it is easy for the end user to suffer from the lack of usability.
When exploring how an organisation implements a DS, the questions without answers are always the same: which type of product/service is developed with that DS? How many people worked on it? Which skills were invested in this project? For how long? What findings do you collect compared to the previous/alternative way of designing a digital experience for your products?
User interaction patterns inconsistency.
As a designer, I mostly have enterprise platforms on my radar, such as financial products, energy and commodity trading apps. Whenever I have access to these products, I stumble on the same big issue: the critical level of inconsistency in user interaction patterns. I am not referring to the simple lack of homogeneous cross-device experiences (by the way, Mobile First is the bluff that goes hand-in-hand with the DS) but to the evident shortcomings of the standard desktop experience. Notifications, system messages, web forms, and calls to action are delivered chaotically because of the lack of a consistent and sustainable development model that a DS should ensure. Proper use of this tool should drastically reduce these gaps. These issues indicate that the DS is not mature or is used only as a reference for look and feel topics.
Legacy with the previous app versions
Trying to walk into the customer’s shoes, such as a financial advisor focused on monitoring opportunities for her/his client portfolio. In most cases, this type of user, over the same journey, has to face different interface types from a visual perspective and both usability and accessibility angles. In my experience, I noticed this is the result of the rush to wildly merge old versions of the product with the brand-new DS. On top of that is also the result of the excitement related to the adoption of the new DS that pushes senior managers and teams to try it out only for the simplest parts of the application (e.g. the app shell) and carefully avoid the most complex parts of the software (e.g. interactive tables). As a result, they end up with a Frankenstein that becomes more manageable and hostile at every new release. The correct adoption of a DS should provide, as one of the first outcomes, the boost of the communication between senior managers and product teams to facilitate and increase the responsiveness in planning and executing the transition between the old version of the product and the new one.
Struggles in planning the product roadmap in the mid and long-term
Struggles in planning the product roadmap in the mid and long-term
All the noises around the DS topic have a side effect on the breeding of digital monsters!
This is the first outcome of the anxiety of senior managers and C-level people in adopting a DS with the illusion this tool will be the cure for all ills. Adding more complexity to this scenario contributes to the common goal of these folks, which is to reduce production costs and maximise financial returns. To achieve that, they very often look for workarounds and shortcuts. One of the most common shortcuts is to opt for a third-party DS, such as Google Material Design, IBM Carbon Design, etc,
To save money and time in design and speed up the coding phase to shrink the time to market. According to my experience, this approach will provide benefits only in the short term, while it will create severe issues in the mid and long term. Due to their complex way of delivering and maintaining the family of products they need to run their businesses, large organisations should invest the right amount of time and resources in planning and defining the strategy that mostly fits their mid- and long-term objectives. Can you guess what the short-term strategy will be? The DS will be used as a pilot for a straightforward part of the application to avoid provoking an impact on the family of products and not trigger any disgruntled target audience. Even more accessible will be foreseeing what the result will be, and the new version of the app will spark! Of course, it does. The benchmark is the previous version, designed with a 10YO User Interface framework! Try to guess what will happen when the team starts planning something more challenging, such as re-designing a whole application for bank back-office operations.
Trust me, the last place you want to be is the meeting room where senior managers, product teams, engineers, and designers are planning the product roadmap related to the number of customisations the brand-new DS needs to deliver a product that covers a reasonable ratio of functionality and usability topics compared to the old version.
Conclusions
I concluded that a large budget is not required to find the best option. Auditing the most important and complex functionalities/features would be enough to compare the pros and cons of the different types of DSs (bespoke ones vs. from the shelf).
As usual, I firmly believe the secret is to have a pragmatic and honest approach to the organisation. I see us as designers and facilitators within the process, supporting the rest of the team in understanding that the DS topic is very complex.
The company’s effort toward this target should have a unique goal: providing a tool to support and facilitate the operations to update and maintain the family of products. As a positive side effect, the organisation will save precious time and effort to increase profits thanks to much higher responsiveness to deliver products and services fitting the audience’s needs.
Long-life to the Design Systems
Caveats and feedback
Your feedback is precious to me!
Have you ever experienced something similar?
Image credits
Photo by Michael Jasmund on Unsplash