This is a guide to a reference design sprint. Of course it isn't one size fits all. This version works as a skeleton in my brain, for me to visualise progress.  Then I cherry pick the stages that work and scrap the ones that don't.

Stages

1. Kickoff

2. Foundations

3. Build

4. Clean 

Stage 1: Kickoff

• Talk. Don't underestimate the need for buy in from the team.

• Set an achievable timeline. Baby steps over perfection.

• Speak their language. Tell engineers about how design-development time will be cut in half, tell PMs that your shipping time will reduce, etc.

• Build your design system team with multiple voices. Include a frontend engineer to tell you more about how Storybook works, QA to suggest ways to evaluate deltas, Product, Interaction Design, Visual Design, Content Writer etc. 

Stage 2: Foundations

• Conduct inventory for your product. This could be a simple spreadsheet or a Confluence document to track all the reusable UI components. This alone will start to reveal inconsistencies in your existing design language

• Setup the foundational patterns - colour, typography, scale, grids, icons. At this stage it's more about creativity and bringing different ideas to the table

• You can look into existing UI kits as a base starting point

• Put regular meetings in place, if possible lead it like a sprint.

A sample design system sprint

Duration: 2 weeks
Team members to involve: Designers, Product owners, Developers, Scrum master

Week 1 timeline

• Monday to Thursday:
  Designers choose a set of components that were ready for developers. These could be completed new components or edits to existing components.

• Friday:
  Scrum master writes out the tickets with descriptions of the work, links to the Figma files, any other documentation

Week 2 timeline

• Monday: Sprint planning meeting.

  Scrum master leads the meeting with designers and developers. The chosen tickets are moved from Backlog to the week's sprint. The designers conduct a demo of the ticket components and also answer any questions that arise. Prioritisation and estimation of story points is done. Each ticket is assigned to a developer. 

• Friday: Demo day

  At the end of a sprint (May be 1 or 2 weeks long) the developers host a demo of their work through the sprint.  Evaluation and basic QA.

• Friday: Sprint retrospective

  A meeting for the team to discuss what went well, what could be improved, any feedback. In smaller teams, we clubbed demo day and retros together.

Stage 3: Build

• Create atoms, molecules, organisms.  This is the part that involves design team starting to build buttons, input fields, forms, etc

• Documentation

• Don't skimp on documentation. Usage guidelines are essential for teams to be able to find correct information and build in sync. Quickly jotted down bullet points are just as effective as content writing in formal prose. You can refer to existing UI kit documentation.

• Governance

• Design systems don't mean a ton of unmanageable processes. Large companies with distributed teams rely on them, but for your team, governance can mean simply talking to another team member to check if edits to a button are okay.

Some references for UI documentation

• Atlassian

• Untitled 

Stage 4: Clean up

When you are starting building a product from scratch you can skip this step. However, if you are tackling another team's files or reusing any old designs, this step is quite dreaded yet necessary. 

• Label old screens with a comment or a frame so that other designers know they haven't been brought into the design system yet

• When touching an old component, you can start by checking if it adheres to the new patterns. Replacing foundational elements (colours, typography, patterns etc) and then publishing the component can modernise it. Sometimes it is simpler to create it again. Slowly you can remove all hard-coded and orphaned pieces.

• Document any exceptions to the rules

Stage X: Alignment

This is a stage that can and should be inserted at multiple stages of the process. It simply means alignment with different teams. Often this has led to some unexpected findings 

• Designers can validate their designs from a engineering standpoint

• Started using plugins to automate accessibility testing

• Developers start to advise designers on how the UI works behind the scenes

• With tools like Storybook, developers can invite designers, PMs, and other stakeholders to test and submit feedback on new UI elements before release.

Conclusion

In this post I wanted to delve into the process instead of focusing on the end results. Thus I did end up using some jargon, and skipped some of the seamy details. Please give me a shout if you want to discuss anything in detail! Get in touch