Successfully reported this slideshow.
Your SlideShare is downloading. ×

Design Systems, Checklist

More Related Content

Design Systems, Checklist

  1. 1. Design Systems, the Full Story Tim Schoch Global DesignOps Conference
  2. 2. FIVE PILLARS
  3. 3. DESIGN SYSTEM CHECK LIST
  4. 4. GOAL
  5. 5. SCOPE
  6. 6. STAKEHOLDER AND PROCESS
  7. 7. INITIAL SETUP
  8. 8. USERS
  9. 9. TECHNOLOGY
  10. 10. LAYOUT
  11. 11. CONTENT
  12. 12. DATA MANIPULATION
  13. 13. ERRORS
  14. 14. TESTING AND DOCUMENTATION
  15. 15. INTEGRATION
  16. 16. EVERYTHING
  17. 17. SCALING
  18. 18. PREACH IT
  19. 19. FOCUS
  20. 20. WE TRADE PERFECTION FOR SPEED AND CONSISTENCY
  21. 21. IT’S A PRODUCT
  22. 22. LINKS +ARTICLES ICONS 
  23. 23. Thank You Tim Schoch tim@timschoch.com @tim_schoch Global DesignOps Conference

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.

×