Developing Design Systems: Patterns, Prototypes, and People

Developing Design Systems: Patterns, Prototypes, and People

You've heard the talk about how we should be designing systems not pages, and how taking a modular, component driven approach to design is key. All true, but developing design systems is hard, messy work. Too often scalability and modularity become afterthoughts in the design proces ”evidenced as pages featuring combinations of almost, but not quite, identical components are passed on to the front end designer to sort out. But scalable, component-based design is not just a single person's responsibility. To get everyone onboard we need to bake system-thinking into the entire design process. In this talk we'll dissect what constitutes a design system, and look at different prototyping techniques that can be used to prepare, present, and bullet-proof one. We'll also tackle challenges like: how to remain creative and ideate when taking a modular approach to design, how to define and document system rules, and how to stay organized. Front-end engineer and experience designer alike, you should come away from this session with a fresh take on patterns and prototyping, along with practical examples for how they can supercharge team collaboration.

Aff5641764408271f7bc398f2097edd0?s=128

Dennis Kardys

June 16, 2015
Tweet

Transcript

  1. Developing
 Design Systems 
 Dennis Kardys @dkardys #FiLive 
 PATTERNS,

    PROTOTYPES, AND PEOPLE
  2. CC license: @matt_j https://flic.kr/p/fksgQJ

  3. the patterns in an environment shape patterns of behavior
 [a

    horrible story about birds]
  4. “designing systems of components… -Stephen Hay


  5. “stitching atoms, molecules, and organisms together to form templates and

    pages. -Brad Frost 

  6. “bootstrap style systems for every client… -Dave Rupert


  7. a modular set of guidelines and components to improve
 consistency,

    efficiency, sustainability
  8. None
  9. None
  10. None
  11. None
  12. None
  13. Design Systems taking first steps

  14. 1. interface inventory

  15. None
  16. None
  17. None
  18. None
  19. 2. organize your code.

  20. None
  21. None
  22. CSS, Sass, SCSS, Compass, Less, BEM, SMACSS, OOCSS, ACSS, CCSS,

    etc… Front End Frameworks and Preprocessors (Do Not Repeat Yourself—so, whatever works for you!)
  23. 3. create useful documentation.

  24. None
  25. None
  26. None
  27. image courtesy Dean Hochman: https://flic.kr/p/nXSUzA

  28. design shangri-la our innermost desires projected

  29. or glamorized reference docs?

  30. should not be static should not be incomplete can’t be

    a developer’s problem x x x
  31. what does it mean to build a living design system?

  32. None
  33. Understanding Systems A set of interacting or interdependent components forming

    an integrated whole.
  34. delineated by boundaries, surrounded and influenced by its environment, described

    by its structure and purpose, expressed in its functioning.
  35. http://blog.noupsi.de/post/44607342301/open-judge

  36. image courtesy Richard Hefner: https://flic.kr/p/quWY6H you can’t design interconnectivity when

    you are inside a silo
  37. What are your system boundaries?

  38. page to page viewport to viewport across platforms across channels

  39. patterns are language. many expressions out of simple rules and

    structures.
  40. each patterns we design foster patterns of behavior element +

    environment + experience
  41. to the design/development/authoring teams: we need to generate behaviors, not

    specify behaviors.
  42. Creating Rules photo CC license: @wanderlass https://flic.kr/p/97VZ2t

  43. 1. avoid colliding with its immediate neighbors 2. be generally

    attracted to others of its kind 3. move in the same direction as the rest of the group. Flocking Logic
  44. Each simply coordinates its movements with those of its neighbors.

    The 1 Simple Rule
  45. “the chorus line hypothesis”

  46. Look left. Look right.

  47. the ultimate team skill is the ability to choreograph actions

    at a variety of scale. CC image: @melfoody - https://flic.kr/p/ea5DSh
  48. systems require rules.
 with the right laws in place, order

    (rather than disorder) will increase over time.
  49. imagine no rules. freedom vs. flexibility

  50. “we want drag and drop.”

  51. None
  52. None
  53. systems require rules.

  54. prescriptive specifying what you should do proscriptive identifying only what

    you should not.
  55. system rules what the system permits and restricts you from

    doing.
  56. editorial/design rules guidelines for how you should use different elements.

  57. principles the rules the capture the system’s intent and purpose.

  58. None
  59. Weave it all together. how will you design without seams?

  60. Ideation Modeling Mapping Refining

  61. Ideation

  62. ideation coming up with ideas iteration refining ideas

  63. Design Charrettes

  64. 1. Work with a blended group. 2. Generate the maximum

    number of ideas. 3. Alternate between solo and group ideation. 4. Surface conflict and build consenus. 5. Inspire DESIGN CHARRETTES
  65. Centerpoint
 the core patterns and behaviors that define your system.

  66. Inspiration Documents

  67. 1. A tool to provoke conversation. 2. Use it to

    answer YOUR questions. 3. Describe rationale not “design options”. VISUAL INSPIRATION
  68. Sketching

  69. 1. Show multiple sketches. 2. Make each sketch unique in

    concept. 3. Discuss viability of concept and direction. 4. Never let your stakeholder hold on to them. 5. Avoid iteration. SKETCHING (for presentations)
  70. modeling
 (shaping the elements)

  71. Element Collages / Style Tiles

  72. Element Collages / Style Tiles

  73. Element Collages / Style Tiles

  74. Paper Prototypes

  75. Structured Content

  76. Content Patterns (templates)

  77. layout (pages)

  78. Navigational Patterns & Flows

  79. mapping
 (find the points of intersection)

  80. None
  81. structured content objects feed the data model

  82. data model helps define patterns and components

  83. styleguide

  84. code content design image CC Nate Weigl https://flic.kr/p/7R8RqM

  85. refining and iterating

  86. None
  87. None
  88. • purpose • intended behavior • examples of states •

    system or editorial rules • use cases • data source • performance requirements Documenting Patterns
  89. stress testing too much content. too little content. poorly formatted

    image.
  90. None
  91. the story of Coyote and the Frybread.

  92. http://www.flickr.com/photos/thaths/6200904390/

  93. http://blog.noupsi.de/post/44607342301/open-judge

  94. image courtesy Richard Hefner: https://flic.kr/p/quWY6H

  95. How can you extend your influence beyond your sphere?

  96. Thanks! Dennis Kardys @dkardys #filive