Within the digital industry, it is very trendy to talk of Design Systems (DSs). Their own definition of a “unique source of truth for an organization to design its own product” sets the level of expectation within the insiders’ community impressively high.
The large organizations’ parade products are designed according to a DS. All over the designer community are plenty of LinkedIn profiles self self-attributing expert and guru titles as the carrier of the real strategy to develop this final weapon.
After reading dozens of articles, a bunch of books and watching hours of videos, I came to the conclusion that on the one hand, the Design Systems are overrated by C-level people and senior managers and on the other hand they are used by some “experts” as a smokescreen for increasing the subscriptions to workshops and conferences. The side effect of all this scuffle is that there’s almost no improvement for the end-users in terms of user experience. If we put on our radar web tools such as financial and insurance platforms and public administration websites the frictions and the issues, for both internal and final users, are alive and well. When it comes to exploring how an organization is implementing 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 are the findings 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 on my radar enterprise platforms such as financial products, energy and commodity trading apps etc. Every time I have access to these products I stumble on the same big issue, the critical level of inconsistency in terms of 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 preceded the DS one), I’m referring instead to the clear shortcomings of the standard desktop experience. Notifications, system messages, web forms e call to actions are delivered in a chaotic way because of the lack of a consistent and sustainable development model that should be managed by a DS. Proper use of this tool should drastically reduce these gaps. The presence of these issues points out 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 in the professional worker’s shoes, such as a financial advisor focused on monitoring opportunities for her/his own client portfolio. In most cases, this type of user, over the same journey, has to face different interface types not only from a visual perspective but from both usability and accessibility angles. In my experience, I’ve 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 (eg the app shell) and carefully avoid the most complex parts of the software (eg 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 to 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 happening around the DS topic have as a side effect 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. To add more complexity to this scenario contributes to the common goal of these folk in reducing the production costs and maximising the financial returns. In order to achieve that, very often they 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 terms of design and speed up the coding phase in order to shrink the time to market. According to my experience, this approach will provide benefits only in the short term, while in the mid and long term, it will create serious issues. Large organizations, due to their complex way of delivering and maintaining the family of products they need to run their own businesses, should invest the right amount of time and resources in order to plan and define the strategy that mostly fits their objectives in the mid and long term. Can you guess what will be the short term strategy? The DS will be used as a pilot for a very simple part of the application to avoid provoking an impact on the family of products and not trigger any disgruntled target audience. Even easier will be to foresee what will be the result, the new version of the app sparks! Of course, it does, the benchmark is the previous version designed with a 10YO User Interface framework! Try to guess what will happen as soon as the team starts planning something more challenging such as the re-design of a whole application for bank back-office operations.
Trust me, the last place you want to be in 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 in order to deliver a product that, at least, covers a reasonable ratio of functionality and usability topics compared to the old version.
Conclusions
I came to the conclusion that is not required a large budget to find out what is the best option. It would be enough to audit the most important and complex functionalities/features and match 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 related to the organization’s capabilities. I see us as designers as the facilitators within the process to support the rest of the team in understanding that the DS topic is a very complex one.
The effort that the company is planning toward this target should have a unique goal providing a tool able to support and facilitate the operations to update and maintain the family of products. As a positive side effect, the organization 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