Why we need design systems
You may have heard the case of Hertz suing Accenture to the tune of 32 million dollars recently. The website that was, eventually delivered (6 months late) was so sub-standard they needed to rebuild it again. The Register writes;
Among the most mind-boggling allegations in Hertz’s filed complaint is that Accenture didn’t incorporate a responsive design, in which webpages automatically resize to accommodate the visitor’s screen size whether they are using a phone, tablet, desktop, or laptop.
The story, though catastrophic for Hertz and damaging for Accenture, reflects something else. That is, if a systematic approach to digital design was employed then this would never have occurred. So how in 2019 can this still be happening?
We need to go back to why we have design systems in the first place
It’s as much about alignment and agreement on direction of a site in a brand’s context as the design and technical aspects of the delivery of the interface. We have a site telling this story at Hello Great Works as an explainer. But in essence this is how we believe websites and apps need to be built. And any visual design needs to be digital by default with code at its core.
The Yahoo! Pattern Library
Ten years ago I had a workshop with some smart people from Yahoo! who gave some key insights about how to embed your design system in product development teams. They were ahead of the curve in those days, creating a library (they shared) with replicable coded assets that all stakeholders could recognise and all developers could use.
With the benefit of hindsight, and working with design systems for a number of years, the importance of this way to design and build digital products has become a necessity. This is due to digital being critical to companies and the large scale of development that occurs every day.
There are five key themes emerging in my work with teams developing products and services in the last year…
MULTIDISCIPLINARY — A design system is NOT just for designers.
They need to have developers at their core. they need to be checked and verified with those that will build the interfaces with code. This code could be web based or native. It doesn’t matter. We need to regard developers first and designer workflows second.
DISTRIBUTED — The point of a design system is to have a knowledge centre and to be able to distribute components easily amongst a team.
That is all it is for — distribution of facts. This is important as these ’truths’ are what drives product development decisions and facilitates agility in teams. Agility aids innovation so keep this in mind. The purpose is to progress with confidence in our decisions and do so as rapidly as possible. And it needs to be code, everything else must lead to code and design decisions.
COMMUNITY — They fulfil the need to promote debate and conversation around important elements of a design. Whatever the individual is considering is important in their own reality is not the same as the team’s reality and the business’s. These three spheres are extremely important for POs and PMs to be aware of and to call out. PMS/POs have in most businesses the responsibility to carry through the best experience for a user. Nothing else really matters and they need to be able to discuss decisions in terms of providing the best service for customers.
WORKFLOW — Visual and interaction design happen at different stages and this must be appreciated by the team. iteration requires a certain level of fluidity to allow decisions to be made that a developer can run with without their work being redundant. Knowing when an idea is ’sandbox’ versus ‘decided’ is critical for a developer’s workflow. It is also likely that every task has a Jira ticket/story/epic associated with it which means more players in the process and likely changes in priorities.
OWNERSHIP — Design systems do need maintenance and a level of administration and they will evolve over time and change. There is a need to revisit components or phase it out due to a new technology making the component. Above all the creation and maintenance of a library is like so many design led activities — iterative. This requires focus and ownership by more than just one or two people in the business but at board-level. A design system should be considered the Intellectual Property of the company. Associated assets (Sketch files, Code repositories and documentation) all form the core experience design of the brand in digital. It is a strategic imperative for every company to begin the job of creating and owning their own design system and it needs to be embraced by all levels of the business that it serves.
Going back to the Yahoo! workshop 10 years ago, two points were made that today are extremely important to repeat. The first is in reference to innovation and design thinking;
People will not turn away from saving time and money. Rapid prototyping enables that.
- Lucas Pettinati
It’s a good reminder about why we invest in building and running design systems for digital products. They enable a quick turn around in seeing working prototypes, and that is key to the agile methodology that so many businesses employ. They are the perfect catalysts for cultural change within an established ‘way of doing things’.
So what is at the core of putting out product that improves a business and increases its digital maturity? It is that design systems give the ability to build bridges between disciplines and ensure a collaborative working environment.
It’s all about relationships and if you don’t have a good relationship then no tool (or methodology) is going to fix that —
Erin Malone
These tools of collaboration are unbounded by process or methodologies. That can only be a good thing and will help to guarantee this being a solid foundation for the developer community. It will also enable those working on products from different disciplines to be brought closer together.
With a design system a site that Hertz needed to be built could be accommodated regardless of requirement changes and scope creep. In my experience, the complexities of devices, screen sizes and different interaction models demand this approach. Anything else is too risky for businesses to consider developing products or services without one.
Originally published at https://www.userpathways.com on May 9, 2019.
