$30 off During Our Annual Pro Sale. View Details »

Design Systems: Enterprise UX Evolution

Design Systems: Enterprise UX Evolution

A journey on the lessons learned, challenges faced, and best practices for creating and maintaining an effective interface design system.

Anne Grundhoefer

October 24, 2016
Tweet

Other Decks in Technology

Transcript

  1. Hello.
    Let’s talk about Design Systems!
    DESIGN SYSTEMS:
    ENTERPRISE UX EVOLUTION

    View Slide

  2. Anne Grundhoefer
    Senior UX Designer
    @annegrundhoefer
    Drew Loomer
    Managing Architect
    @drewloomer

    View Slide

  3. View Slide

  4. View Slide

  5. View Slide

  6. View Slide

  7. HOW CAN WE FIX THIS?
    DESIGN SYSTEMS

    View Slide

  8. http://www.multiscreen-ux-design.com (Wolfram Nagel / SETU GmbH)

    View Slide

  9. http://www.multiscreen-ux-design.com (Wolfram Nagel / SETU GmbH)

    View Slide

  10. “But I build applications, not
    Legos…”
    WE KNOW WHAT YOU’RE THINKING

    View Slide

  11. View Slide

  12. View Slide

  13. View Slide

  14. View Slide

  15. View Slide

  16. View Slide

  17. View Slide

  18. View Slide

  19. View Slide

  20. View Slide

  21. • Need to look and behave similarly
    • Implement similar UI components
    • Duplicate low-level functionality
    • Must be white-labeled or themed
    • Are built on different tech stacks
    • Suffer from visual regression bugs
    A Design System will provide value if your products…
    D O I N E E D A D E S I G N S Y S T E M ?

    View Slide

  22. • Provide a single source of truth for building UIs
    • Save time and money
    • Increase consistency
    • Decrease maintenance
    • UX teams focus on the experience; dev teams on
    implementation
    • Improve user experience through well-defined
    and learned behaviors
    BENEFITS OF A
    DESIGN SYSTEM

    View Slide

  23. THE NEW
    STANDARD

    View Slide

  24. Salesforce’s Lightning Design System is a leader in
    the space. It provides great accessibility guidelines.

    View Slide

  25. Lonely Planet’s style guide is actually a living
    component API that developers can include in their
    project to pull in the latest UI.

    View Slide

  26. U.S. Web Design Standards supplies assets and
    direction for maintaining consistent experiences
    across federal government websites.

    View Slide

  27. IBM’s design language serves as an instructional tool
    to help communicate their brand’s user interface
    through many different kinds of products.

    View Slide

  28. Intuit Harmony has a great narrative of the reasoning
    behind their component designs.

    View Slide

  29. Hillary Clinton’s Pantsuit empowers developers to
    create and ship products quickly while maintaining a
    consistent UI.

    View Slide

  30. Hillary Clinton’s Pantsuit empowers developers to
    create and ship products quickly while maintaining a
    consistent UI.

    View Slide

  31. BOOTSTRAP?
    WAIT… ISN’T THIS

    View Slide

  32. WHY NOT?
    • Those are rapid prototyping tools, not
    design systems
    • Their components do not consider your
    unique context
    • Not detailed enough
    • You take power away from your
    developers
    • You are beholden to their timeline and
    community
    B O O T S T R A P O R F O U N D AT I O N

    View Slide

  33. HOW TO GET
    STARTED

    View Slide

  34. Pattern Library
    UI Components, Page Templates, Reference Files
    (.psd, .ai, .sketch)
    Code
    Coding Standards, Supported Browsers and Devices, Versioning,

    Pattern Implementation
    Brand Identity
    Fonts, Colors, Meaning, Visual Language,
    White Labeling Logo/marketing related
    Editorial Guidelines
    Voice and Tone, Word List, Capitalization and
    Punctuation
    Foundations and Principles
    Guiding Design Principles, Accessibility
    Targets, Animations, Scaling, Grids

    View Slide

  35. “A Design System isn't a project. It
    is a product, serving products.”
    A design system is not simply a style guide. It is a living thing whose value is realized only
    when products successfully implement the patterns of the system.
    Nathan Curtis
    Design System Evangelist

    View Slide

  36. BUILDING A PATTERN LIBRARY

    View Slide

  37. • Check up to 25 components you feel are most important to include
    in the first version of the design system.
    • Cross out at least two sections you think are unnecessary or
    unimportant for your applications.
    • Add a star by up to five components that you should expect to
    spend extra effort getting right.
    Participants:
    Identify components
    with a checklist
    1
    A simple checklist can quickly identify which
    components are essential to an organization.

    View Slide

  38. The cut-up gives visibility on how you are doing
    things today, and the level of complexity a
    component needs to accommodate.
    2Cut-up components
    from various interfaces
    • Organize and print out screenshots from the existing site and/or
    applications
    • Create categorized sections (forms/buttons/navigation/etc.) based
    on the component checklist
    • Participants cut up each page into components, separating
    components into their assigned category
    • This exercise generates momentum, brings clarity, and trims fat

    View Slide

  39. Before you start designing components,
    you need to establish a base.
    • Establish low-level design principles
    • Start with color, typography, iconography, units of
    measure, grids, spacing
    • Align on what you are going to name each component
    3Lay a solid foundation
    for your components

    View Slide

  40. Rebuild each of your UI components, one
    at a time, from the ground up.
    • Identify the smallest pieces and build from there
    • Define which pieces inform others
    • Write down reasons why you made certain
    design decisions
    4Design components
    from scratch

    View Slide

  41. For a design system to thrive and survive,
    it needs a sufficient level of management
    and organization.
    • Create the order for when you are going to tackle each
    component
    • Schedule weekly reviews with stakeholders and
    developers
    • Establish long-term governance
    5Work closely with
    your team

    View Slide

  42. THINGS TO CONSIDER
    BUILDING A PATTERN LIBRARY
    42

    View Slide

  43. Your Software’s Context
    You cannot simply design whatever you want. Take into account all
    of the software you have today when designing, and frequently
    refer back to the results of the component cut up for reference.
    Your Users
    Who are you designing for? Are your users bank tellers, auto
    mechanics, grandparents? How are they accessing your software?
    For how many hours a day? Remember that designers and devs are
    also users of the design system.

    View Slide

  44. • Modern vs. legacy web browsers
    • Native/web hybrid
    • Native desktop app for Mac/Windows
    • Native mobile app for iOS/Android
    Which devices/environments do you need
    to support?
    Device Support
    • Mobile
    • Tablet
    • Desktop
    • Large Screens
    • 4K/Retina
    • Watch
    What are your responsive breakpoints?
    How does that affect our component design?
    Responsive

    View Slide

  45. • Create flexible systems that consider the
    experiences of people with disabilities from
    the start
    • Maintain reasonable contrast ratio between
    text and background colors
    • 4:5:1 for small text
    • 3:1 for large text
    • Use online tools
    • wave.webaim.org
    • colorsafe.co
    Do you need Section 508 and WCAG 2.0
    compliance?
    Accessibility
    • Make your CSS highly configurable
    • Select smart defaults by making the contrast
    between colors as high as possible
    • Leverage color algorithms in your CSS
    preprocessor for dummy-proof color schemes
    • Consider providing a Light UI or Dark UI for
    different environments
    Does your experience need to be easily
    themed or rebranded?
    White-Label

    View Slide

  46. • Nothing – the component exists but hasn’t started
    • Loading – waiting for the component to render
    • None – the component has initialized, but it’s empty
    • One – you have some data
    • Some – the ideal state for this component
    • Too Many – Too many results/characters/etc.
    • Incorrect/Correct – success/error
    • Done – correct input has been received
    Designing for all states
    • Active/Hover/Focus – elements that can be interacted with

    View Slide

  47. View Slide

  48. View Slide

  49. View Slide

  50. View Slide

  51. BUILDING AN IMPLEMENTATION

    View Slide

  52. YOUR GOAL:
    Enable faster and more consistent
    design and development

    View Slide

  53. A Design System is not an application framework and
    should not be coupled to one.
    Build self-contained components
    • Create a prescriptive application template
    • Build on or for one particular framework
    DO NOT
    • Focus on building long-lasting vanilla HTML/CSS/JS
    • Keep your components “dumb”
    • Consider all your systems
    DO
    Enable faster and more consistent development
    YOUR GOAL:

    View Slide

  54. Provide useful assets and comprehensive documentation
    of how and when to use each component in the system.
    Deliver obvious value
    Enable faster and more consistent development
    YOUR GOAL:
    • Define required HTML structure
    • Include production-ready CSS and JS
    • Be semantic and accessible
    • Make components configurable
    • Ensure consistency

    View Slide

  55. CODE STRUCTURE:
    Small, configurable, and
    well-documented components

    View Slide

  56. Small, configurable, and well-documented components
    STRUCTURE
    CODE

    View Slide

  57. Small, configurable, and well-documented components
    STRUCTURE
    CODE

    View Slide

  58. Small, configurable, and well-documented components
    STRUCTURE
    CODE

    View Slide

  59. Small, configurable, and well-documented components
    STRUCTURE
    CODE

    View Slide

  60. Small, configurable, and well-documented components
    STRUCTURE
    CODE

    View Slide

  61. Small, configurable, and well-documented components
    STRUCTURE
    CODE

    View Slide

  62. Small, configurable, and well-documented components
    STRUCTURE
    CODE

    View Slide

  63. Small, configurable, and well-documented components
    STRUCTURE
    CODE

    View Slide

  64. Central
    Repository
    ROLL IT OUT
    Ensure adoption by making your Design System
    easy to consume and update.
    Publish multiple ways Make it collaborative
    Update frequently Ensure reliability

    View Slide

  65. A design system can be a large
    investment of time and money,
    but it pays clear dividends.
    SELLING DESIGN SYSTEMS

    View Slide

  66. http://www.usability.gov/what-and-why/benefits-of-ucd.html
    *Benefits of User Centered Design
    $1,652,400 annual savings or 21.25% time saved
    Assumptions are in back up slides.
    (x hrs)*($4050.00)*(48 weeks) = annual savings
    100 devs
    each save 2 hrs
    per week
    =
    $388,800
    annual savings*
    100 devs
    each save 30 min
    per week
    =
    $97,200
    annual savings*
    100 devs
    each save 5 hrs
    per week
    =
    $972,000
    annual savings*
    100 devs
    each save 1 hr
    per week
    =
    $194,400
    annual savings*
    Time saved
    when art direction
    isn’t needed
    Time saved
    from rework
    Time saved
    when components
    are compatible
    Time saved
    when assets
    are available

    View Slide

  67. • Provide a single source of truth for building UIs
    • Save time and money
    • Increase consistency
    • Decrease maintenance
    • UX teams focus on the experience, dev teams on
    implementation
    • Improve user experience through well-defined
    and learned behaviors
    BENEFITS OF A
    DESIGN SYSTEM

    View Slide

  68. Thanks!
    Anne Grundhoefer
    @annegrundhoefer
    Drew Loomer
    @drewloomer

    View Slide

  69. http://www.usability.gov/what-and-why/benefits-of-ucd.html
    *Benefits of User Centered Design
    Hourly rate assumptions
    ratio = 2:1:1 (2 offshore :1 onshore employee : 1 onshore contractor)
    offshore rate = $18 x (50 devs) = $900.00 hrly
    onshore FTE rate = $48 x (25 devs) = $1200.00 hrly
    onshore contractor rate = $78 x (25 devs) = $1950.00 hrly
    Avg hrly rate = $40.50 x 100 developers = $4050.00 hrly
    Annual resource costs per 100 resources = $7,776,000
    (x hrs)*($4050.00)*(48 weeks) = annual cost

    View Slide