Design System 1: Vision and Platform

I'm so happy about this. I can finally say we've started work on building a Design System here at Taopix. Here's what we're learning along the way...

A bit of background

The reason we're now in a position to be able to begin implementing a Design System, is that we've started work on rebuilding the front end of the main online editor application (i.e. the UI people use to create photobooks etc).

This is not only an ideal opportunity to create a Design System, as we can get everything lined up from the beginning, but it's a necessity if we're going to do a good job of building that front end.

Researching Design Systems

There are no shortage of resources online for researching design systems, but here's a few things we've found useful to help get you started:

• Sign up to Design System News
• Read this: NNG Design Systems 101
• And this: Accessibility In Design Systems
• And have a look at these great examples:
   • Gov.uk Design System
   • Co-op Design System
   • Shopify Design System

The vision

The design team have been thinking about this and researching Design System practices for some time now, mainly out of our own interest but also hoping that the day would soon come; so we're pretty firm in why we want to create one and what benefits it will bring.

Why do we want a Design System?

• Reduce decision making when designing and building a new feature or UI
• Componentise the front end code to make it easier to build, maintain and improve
• Ensure our UI is visually and experientially coherent and consistent
• Enable our customers to build their own UIs

What is a Design System to us?

• A documented library of UI components (code) with accompanying usage guidelines
• Broader design guidelines and principles for framing future UX and UI decisions
• Specific design specifications to stick to when creating new UI components
• The actual code package that makes up the component library

From the above, you can see that we think the backbone of a Design System is the Component Library itself.

This is an important point, as we want to avoid building a documentation platform that is independent of the codebase and therefore requires additional work to maintain it, which will likely result in an out of date Design System.

Decision 1: How to host it

We've decided that we don't yet need to create design guidelines, since while we're building it, we're the only people using the system and of course, we're designing it as we build it. That part of the Design System will be a case of documenting what we've done after the event to enable other people to use our components.

So we decided that all we need right now is a front end for the component documentation.

We discussed are a few different solutions, broadly they were:

• Create our own online component documentation website
• Use something like Confluence to publish the documentation. This would give us a bit more control over versioning and things like that
• Use a Component Library platform like Storybook, Fractal or Bit.dev

The solution presented itself: Creating a documentation system would be a lot of work; each component would have to have a page created for it with code examples and usage guidelines added into whatever content management system we chose.

But the main factor in this decision was the discovery that platforms like Storybook act as the Component Library itself, as well as the documentation content and front end. This is because they exist as standalone applications that read your actual component library and present it in its own searchable front end.

We chose Storybook, as we preferred to work with open source - we've already got some ideas about how we might extend it - and we liked the way the documentation is managed using Markdown. The documentation website is also great to use.

Video from storybook.js.org