A summary of how Sketch and Abstract can be used to manage a complex cross-platform product offering aimed at both internal and external stakeholders. I also include some of my personal thoughts on the state of design tooling.
In Part 1 (this article) I talk about the maturing of the tech industry and how its complexity increased the need for Design Systems.
In Part 2 (upcoming) I talk about tooling landscape and the reason for picking Sketch and Abstract to help bring a Design System to life.
Finally, Part 3 (upcoming) covers the process of our Design System, tips and tricks for Sketch, Abstract usage, what’s included in our documentation, and how we surface Design System-related activity within the company - from user insights to releases.
A Maturing Industry
At the very low end of the design maturity scale, we have companies with a designer head count of one of fewer. In these companies, the source of truth is often inside people’s minds, spotted around documents and presentations, and in the implementation itself.
Within an agency context, design artefacts are often abandoned at the end of a project. The most wasteful process would have designers create a Sketch file from scratch, expand it over the course of a few months, and abandon the file upon project completion.
Product companies, however, have design artefacts with a longer shelf life compared to the fire-and-forget output of typical agencies.
At product companies, design artefacts not only have a much longer timespan, they typically involve multiple products, multiple platforms, and parallel work streams with sometimes unpredictable release schedules.
Because of the extended shelf life and larger teams, ownership will be shared and change over time as designers change teams, leave, and join the company.
Stakeholders in a product company span C-level execs, product managers/developers/designers (and an equal set within managed services), marketing/sales/customer support, and finally the end-users.
In a mature company, releasing working digital products is a commodity, the real challenge is to release the right product.
It’s easy to forget that interaction design pattern libraries have been mainstream for 20 years now. Many decades before the year 2000, style guides ensured consistent representation of a brand across goods and services.
In more recent years, Design Systems has become a very popular theory to increase productivity, as well as ensure product consistency and quality.
The big difference compared to pattern libraries is the inclusion of ways of working and advocacy, in other words, Organisational Design is key to Design Systems.
Organisational design [covers] the creation of roles, processes, and formal reporting relationships in an organisation. – Wikipedia
Agile is an example of Organisational Design. It aims to solve the problem of low and risky productivity originated by the Waterfall process, by introducing a specific set of processes and methods.
Design Systems main aims are to increase productivity, quality, and buy-in. Productivity is increased thanks to reusable patterns, reusability in turn increases product quality because patterns are the sum of a collective intelligence, and finally, advocacy promotes the benefits of the system leading to a greater buy-in and success of the system and thus product(s).
Certain Design Systems further improve product quality by outlining success measurement techniques, and pattern-specific metrics – e.g. Pinned Toolbar increases conversion by X%, Rectangular Stories are misunderstood by users compared to Circular Stories (e.g. circular like Instagram).
Design Systems is an abstract theory you can read and understand.
But how do you go about building a concrete representation of a Design System?
There are obviously many tooling combinations you can use, off-the-shelf products like Sketch, Figma, Framer X, or custom middleware applications like AirBnB has done.
The next article will look at the current off-the-shelf tooling landscape and outline the way we’re using Sketch & Abstract, Slack and Confluence to document and advocate for Design Systems at a medium-sized startup.