To build a digital product...
I left you hanging yesterday with the question: what is a design system?
That’s a big question to answer in a single email, so let’s break it up. Today, I’ll start super simple and explain the core concept, and tomorrow I’ll go into detail about the common pieces of a design system.
🛠 How do you make a digital product? (The oversimplified version.*)
Planning. When someone, say the leadership of a company, wants to build a digital product, like a website or a mobile app, they usually start with an educated guess that this product will provide value to a specific group of people (market segment). These people are sometimes called “stakeholders” because they have a “stake” in the outcome of this business guess. They employ user researchers, who use different methods of testing to confirm or modify those guesses.
Designing. Once stakeholders have a good guess for the product and some promising research (which helps them secure a budget), they hire designers who use digital tools like Photoshop or Figma to create a visual prototype of that product. This might be a PNG for every possible screen of a mobile app, or it might be a wireframe version of the website. This helps stakeholders picture what the potential customer might experience when using the app.
Building. Once they’re able to picture the finished product, they give the green light to another group of people: engineers (or developers). Engineers build the actual digital product using code. They use the visual prototypes as a blueprint for the customer-facing parts of the app or website.
More building. But there’s more to software than how it looks. They also have to think about how it behaves — what happens when you click a link or submit a form or rotate your phone into landscape mode. They do their best to understand and carry out the choices of the designers, being mindful of the business value the stakeholders hope to deliver to customers.
If everyone did their job well and the business guess was right and with a little bit of luck … success! A new successful digital product is born.
💯 You succeeded! Now change it. And make more.
Once the product is launched successfully and users find it valuable, stakeholders want to improve or expand it based on new business guesses (validated by user research, hopefully!) That means that the people who built it will need to keep building it.
But most successful companies don’t have just one digital product, they have a few: an iOS app, an Android app, an app website, a marketing website, etc. Each of these products often requires a unique engineering skillset to build, so the team that built the original product will probably not be the team that builds these other products.
More engineers are hired to build those other products. More designers are hired to keep up with the visual prototypes being requested by stakeholders across all products. It’s hard to keep up with all of the business guesses and requested changes and engineering compromises…
🕸️ Things are getting complicated.
Each team might work well together on its own. They might be able to design, build, and get updates to their own product out the door on time. But the larger the number of products the company offers, the less “in sync” all of the different teams will be. It’s an exponential problem.
This organizational complexity can lead to fragmentation.
Fragmented technical solutions. Fragmented design choices. As each team solves their own team’s technical and design problems, those solutions unchecked can sometimes lead to a fragmented user experience. “Why does it work this way on the website, but not on the app?”
🦸 This is where design systems can help.
What if we could capture the intentions of a product designer in a way that’s more scalable than just an image? If we could somehow codify key design decisions and make it easier for those design decisions to be integrated into all the digital products. That’s a core promises of design systems.
I’ll sign off with my definition of a design system:
A design system is a set of principles, procedures, and tools used to render the intended outcome of designers.
Tomorrow, I’ll explore this definition in more detail. I’ll review the parts of a design system and explain how, done well, they can solve some of these problems of scale and fragmentation.
* I generalized quite a lot. For example, most designers and engineers usually work closely together, passing design ideas and code back and forth. Some designers use tools that don’t require coding. Some engineers do design work. In general, though, this is the basic process.
—
Cheers,
Up Next: To build a design system...
Design Systems Daily
Sign up to get daily bite-sized insights in your inbox about design systems, product design, and team-building:
New to design systems?
Start with my free 30-day email course →