Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Documenting design patterns

832 views

Published on

As UX becomes increasingly Agile, a need arises to quickly create and iterate new interface elements. Many popular frameworks exist to document front-end design patterns. Most of them connect directly to the website's CSS, and help developers easily create new interface elements and templates.

But what happens when the design and UX team can't work in code? How can we create truly cross-functional design documentation that works both for developers and designers?

In this session, we will describe the process we have been working on to document our existing design patterns and create a working set of elements that allow both for rapid iteration of design prototypes and implementation of templates in code.

This session is for UXers who work with teams that include both front-end developers and visual/interaction designers, who need to create and iterate on interfaces in rapid, Agile environments.

Published in: Design
  • Be the first to comment

Documenting design patterns

  1. 1. dani@tzk-design.com :: @danigrrl Documenting Design Patterns for cross-functional product teams
  2. 2. dani@tzk-design.com :: @danigrrl About Me Senior UX Designer, Harvard Business Review Group UXD Bootcamp, General Assembly Author, Drupal for Designers (O’Reilly, 2012)
  3. 3. dani@tzk-design.com :: @danigrrl Design Patterns at HBR
  4. 4. dani@tzk-design.com :: @danigrrl The Great • Based in site CSS • Mobile first • Creates repeatable, reusable design patterns • Speeds up front-end production
  5. 5. dani@tzk-design.com :: @danigrrl The Not So Great • Documentation lacking • Disorganized • Design team still working in PSD comps
  6. 6. “Why don’t you just use this helper class?” <div class=“credit text-very-tight line-height-loose push-1 medium-3 columns…
  7. 7. dani@tzk-design.com :: @danigrrl Legibility/inconsistency issues
  8. 8. dani@tzk-design.com :: @danigrrl Contrast issues
  9. 9. dani@tzk-design.com :: @danigrrl What to do?
  10. 10. dani@tzk-design.com :: @danigrrl Step 1: Inspiration
  11. 11. dani@tzk-design.com :: @danigrrl
  12. 12. dani@tzk-design.com :: @danigrrl
  13. 13. dani@tzk-design.com :: @danigrrl Step 2: Start Organizing
  14. 14. dani@tzk-design.com :: @danigrrl
  15. 15. dani@tzk-design.com :: @danigrrl
  16. 16. dani@tzk-design.com :: @danigrrl Step 3: Document principles & guidelines
  17. 17. dani@tzk-design.com :: @danigrrl Principles & Guidelines • Guiding principles • Colors • Typography • Iconography • Responsive grid • Visibility helper classes
  18. 18. dani@tzk-design.com :: @danigrrl Other considerations • System messaging • Interface copy • Design/user testing protocols and process • Interaction standards
  19. 19. dani@tzk-design.com :: @danigrrl WAIT.
  20. 20. Why is User Research in here? That’s not really “design.”
  21. 21. We’ve been trying to make the wiki* a central location for all this stuff. *that nobody ever reads
  22. 22. dani@tzk-design.com :: @danigrrl The process is still evolving http://commons.wikimedia.org/wiki/File:Evolution-des-wissens.jpg
  23. 23. dani@tzk-design.com :: @danigrrl Thank you!

×