Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Design Systems, Checklist
- 1. Design Systems, the Full Story Tim Schoch Global DesignOps Conference
- 6. FIVE PILLARS
- 9. DESIGN SYSTEM CHECK LIST
- 13. GOAL
- 14. SCOPE
- 18. INITIAL SETUP
- 19. USERS
- 20. TECHNOLOGY
- 23. LAYOUT
- 24. CONTENT
- 28. ERRORS
- 32. INTEGRATION
- 34. EVERYTHING
- 35. SCALING
- 36. PREACH IT
- 37. FOCUS
- 40. WE TRADE PERFECTION FOR SPEED AND CONSISTENCY
- 41. IT’S A PRODUCT
Editor's Notes
- Design Systems are Beasts that want to get tamed! Highly Challenging Very Complex Hard to Sell and extremly rewarding if done right I’ve curated a check list that helps setting our design system up Tim Schoch Freelance UX Designer Switzerland mostly larger projects/products worked with and for several design systems Seen what worked and why some failed
- First style guides Then UX Patterns Now Functional Components Bring Design and Dev together
- Not a one-off Long term commitment Q??? who treats design systems as products
- Design Systems exist to simplify building other products. Keep this in mind as UX Designer! No dribbblization just because “a Design system is expected to have XYZ” Be proud of your design system! Stay humble and focussed.
- Shift Work from Product Team to Design System Team Opportunity costs: product teams provide value, not perfect micro interactions
- Concept I came up with Five Stages that a design system goes through. Mix Product Owner, UX Designer and Dev
- Sell Research Design Build Maintain Not linear: Mix and Match Decissions from the End influence the Design Pillar
- Sell Research Design Build Maintain Not linear: Mix and Match Decissions from the End influence the Design Pillar
- Looks familiar? No Research -> Design Actionism
- Two distinct approaches Fast -> One Product Structured -> Multiple Products
- This is the URL to the checklist, make sure to take a photo of this. Open Source Share it Send me your questions
- Article that you can copy to a Word file or Confluence and use as a guide. Go through this checklist at the beginning, and write down our rough ideas. Not perfect Revise once we get there.
- Let’s have a look at the Check List Sell
- Let’s have a look at the Check List Sell
- Understand Product teams Business cases Contexts Not too deep pitch
- What Problem are we solving? What Benefit do we offer? Talk to the important people and find out. Do all Expectations match?
- Based on our research, what will we deliver? There aren’t many must haves in a design system. Make sure you promise only what you need in the required fidelity! Start small, expand where needed
- Design Systems aren’t built in a vacuum Necessary people on board? Find allies and sponsors. Pitch our story!
- After a successful pitch next stage is research
- After a successful pitch next stage is research
- Get intimate knowledge about your product teams situation Get to know all your products Create a shared vision
- Rules and UX Principles - Simple Principle: Fun and colorful vs. minimalistc - Casual Users vs. Professional Users Often a team effort Form the Character of your Design System Lighthouse to check decissions against
- Do we have enough understanding of the users of our products? Worth chatting with the product teams Create a hollistic picture to understand the needs you’re catering for
- Check In with the devs of the product teams Define the tech stack most suitable for our products
- Of all the five pillars, this is my favourite.
- Of all the five pillars, this is my favourite.
- Following questions might sound simple Don’t skip them We want to design a system that works, not one that just looks good
- Our Layout depends on product needs Content density different in specialised B2E application from public facing website
- Design of components varies based on content Story designers often want to perfect components deal with all edge cases I’ve been in meetings where several UX designers tried to find the perfect solution Until someone asked: «do we actually have this situation?» Keeping this in mind helps us to focus
- There are some very important decissions to make when it comes to building our design system
- A lot of the complexity comes from how to enter and edit Data Based on all we know so far, what Manipulations do we really need? Does it have to be inline Edit in a Table? Or Master-Detail? Just a Dialog? Inline Edit in Tables is hard to get right both from a development standpoint aswell as regarding the micro interactions. Choosing something simple here is a great way to cut down the costs. But how important is efficiancy to the use case? Product decissions: worth the effort?
- A key to a good user experience is how we handle things when they go wrong. More than Validation How do we prevent Errors or make our applications more error tollerant?
- Testing and documentation are just one slide here, but they’re one of the most important steps for any decent sized design system. Both might be considered «unsexy» - but if we get it wrong and adoption for our design system will drop. Docs: They’re under pressure, go with what’s easy to use Testing: Trust in our quality, that we don’t break their product
- Let’s takle the last pillar
- Let’s takle the last pillar
- Design Systems don’t look after them selves. Long term support infrastructure
- As Design Sytems grow, evolving them becomes harder and harder Automate as much from the beginning Release Notes are one of the most undervalued things in a Design System. Let me show you why
- «Our Design needs to breath, it needs space to live!»
- Add 5px padding -> Grows, thats fine. But it breaks the Buttons.
- Add 5px padding -> Grows, thats fine. But it breaks the Buttons.
- Not just properties in code Components have a visual API Q??? what CSS properties are breaking changes? Everything that changes size: margin, padding, border, line-height Also Colors: accessibility can break if you change the BG color of a Button
- Depends on the size of our design system
- Wrap this up
- build only what you really need Nest Components in Components The more you build, The more complexity rises, Edge cases appear, More things to test The Slower you move
- Product Owner! Features are like Chilis
- Product Owner! Features are like Chilis
- Product Owner! Features are like Chilis
- Remember! True for both product teams and UX Designers. We can’t design the 100% optimised AppFlows but must adhere to standards. Devs don’t have to spend time perfecting interactions and focus on business logic
- Lastely: It’s never a One-Off. You need to have a long term plan, even if you start small. Design Systems need DesignOps
- Slides, more articles and links on this topic Followup -> leave email, recieve followup next week.