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.

Transcript

1. Hello. Let’s talk about Design Systems! DESIGN SYSTEMS: ENTERPRISE UX EVOLUTION
2. Anne Grundhoefer Senior UX Designer @annegrundhoefer Drew Loomer Managing Architect @drewloomer
7. HOW CAN WE FIX THIS? DESIGN SYSTEMS
8. http://www.multiscreen-ux-design.com (Wolfram Nagel / SETU GmbH)
9. http://www.multiscreen-ux-design.com (Wolfram Nagel / SETU GmbH)
10. “But I build applications, not Legos…” WE KNOW WHAT YOU’RE THINKING
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 ?
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
23. THE NEW STANDARD
24. Salesforce’s Lightning Design System is a leader in the space. It provides great accessibility guidelines.
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.
26. U.S. Web Design Standards supplies assets and direction for maintaining consistent experiences across federal government websites.
27. IBM’s design language serves as an instructional tool to help communicate their brand’s user interface through many different kinds of products.
28. Intuit Harmony has a great narrative of the reasoning behind their component designs.
29. Hillary Clinton’s Pantsuit empowers developers to create and ship products quickly while maintaining a consistent UI.
30. Hillary Clinton’s Pantsuit empowers developers to create and ship products quickly while maintaining a consistent UI.
31. BOOTSTRAP? WAIT… ISN’T THIS
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
33. HOW TO GET STARTED
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
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
36. BUILDING A PATTERN LIBRARY
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.
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
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
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
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
42. THINGS TO CONSIDER BUILDING A PATTERN LIBRARY 42
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.
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
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
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
51. BUILDING AN IMPLEMENTATION
52. YOUR GOAL: Enable faster and more consistent design and development
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:
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
55. CODE STRUCTURE: Small, configurable, and well-documented components
56. Small, configurable, and well-documented components STRUCTURE CODE
57. Small, configurable, and well-documented components STRUCTURE CODE
58. Small, configurable, and well-documented components STRUCTURE CODE
59. Small, configurable, and well-documented components STRUCTURE CODE
60. Small, configurable, and well-documented components STRUCTURE CODE
61. Small, configurable, and well-documented components STRUCTURE CODE
62. Small, configurable, and well-documented components STRUCTURE CODE
63. Small, configurable, and well-documented components STRUCTURE CODE
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
65. A design system can be a large investment of time and money, but it pays clear dividends. SELLING DESIGN SYSTEMS
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
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
68. Thanks! Anne Grundhoefer @annegrundhoefer Drew Loomer @drewloomer
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