Patterns Day 2019 retrospective

Inayaili de León -

5 untruths about design systems

• Designer working on Design Systems for Azure DevOps (Microsoft)

• Previously : 7 years at Canonical (Ubuntu)

Untruth #1 "Everyone loves and understands our work"

• People just want to use whatever tool is easiest to achieve their current objectives.

​

• As a consequence, you constantly need to sell the added value that the project brings and adapt your message to the needs and requirements of the different teams in the company.

Untruth #2 "Our documentation is always up to date"

• In reality, we don’t always have the time to document things.
• "Design System websites are for teams what Instagram is for life : a façade".
• Take time to improve things bit by bit.

Untruth #3 "Everyone works together in harmony"

• People will go ahead and just build something that matches their needs.
• We shouldn’t block people from using the system, but should have process in place to improve the system.
• You need to be comfortable in the knowledge that a Design Systems team will work slower than a ‘features’ team.

Untruth #4 "No one ever needs custom components"

• People will go ahead and just build something that matches their needs.
• We shouldn’t block people from using the system, but should have process in place to improve the system.
• You need to be comfortable in the knowledge that a Design Systems team will work slower than a ‘features’ team.

Untruth #5 "We validate everything"

• Sometimes there is not the time to get things through the entire process of testing, auditing, etc.
• Continuous, gradual improvement.
• Make a rule that a component is 100% valid until it has user-tested feedback ?

Amy Hupe -

"Content is King"

Content Designer on the GOV.UK design system https://design-system.service.gov.uk/

Content and design systems ?

• Microcopy e.g. what example text to put on buttons

• Components documentation

• Content best practices (component usage)

Focus on making sure people :

• find the documentations

• use it

• contribute to it (when needed)

Good documentation is...

Clear

Naming is a crucial aspect of making the documentation clear : making sure people looking up a thing can find it

• at GDS components are like objects, so they use nouns.
• at GDS patterns are ways of ding things, so they use verbs.
• "Permissive" search

Useful

• Resist the temptation to write too much doc ("good documentation is about writing the right things at the right time for the right reason - every line of content in your documentation is one more thing the users will have to do")
• Use real content whenever you can

Honest

• Include a ‘known issues and gaps’ for a pattern or component in the documentation.
• This could help others contribute fixes, and additional information required to make the components and patterns improve over time.