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
Disposable design artefacts are the norm when running an agency. At the very worst designers would create a blank Sketch file, do a few months or even just days of work, and abandon the file once the project is complete.
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 much longer timespan, they typically involve multiple products, multiple platforms, and parallel work streams with sometimes unpredictable release schedules.
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.
Finally, now that releasing working digital products has become a commodity, the challenge most companies face is being able 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.