Incremental Design - Rebecca Miller-Webster and Savannah Wolf - RailsConf 2013

gistfile1.md

Incremental Design

Rebecca Miller-Webster and Savannah Wolf

• Rebecca: Developer, Savannah: Designer

• How do you make design changes?

• Big redesigns are often long and frustrating

• Designers throw the design over the wall

• Developers either are confused by it, or 'screw it up'

• Redesigning page by page can lead to technical debt, and is awkward

• Solution: Incremental Design

• What is ID?

  • Same Agile principles as SW
  • Tiny deployable design changes
  • It creates a conversation between design and development

• Product challenges:

  • Two product models (single/couple dating parts of HowAboutWe)
  • Aggressive Timelines
  • Split testing metrids,
  • Make great design

• Small changes can be big pains (moving sidebar breaks mobile)

  • Better to find those pain points earlier than later

• Have reusable components that can be used anywhere

• It's okay to release imperfect design, since you're improving incrementally

• Fry the bigger fish first

• Design Team: get request, start requirements, and as soon as wireframes form:

  • Ask devs is this possible?
  • And is this possible in this timeline?
  • Hash out tweaks to find out how to make it easier
  • Then pass it off

• Devs incrementally apply changes, constantly check in w/ design

  • 5 minutes or less conversations
  • The more conversations you have, the faster they become
  • Builds trust

• Techniques for design process

  • Align yourself w/ developers
  • Springs/Reviews/Retros work for designers too

• Techniques for development process

  • Get strict about your styles
  • Changes better be worth it, since devs will fight against it naturally
  • Style guide available for devs and designers
  • Has fonts, colors, grids, etc
  • PSD style guides are never up to date
  • Keep it on the web so it's living
  • Code style guide exists too (on github)
  • Have a conversation if you want to deviate/add anything

• Markup is about content.

  • Drop classes when you can

• Look at your CSS as code

  • Apply good clean coding principles to CSS
  • Variables are your friend
  • Variable names should represent their meaning, not what they actually are
    • i.e. $skinnyUnit vs $22pxWidth
  • Scope your variables
  • Use mixins (usually prefereable over extends)
    • Highly reusable

• Get logic out of your views

• Generate classes depending on state of object

  • This works for copy and html attrs too
  • View tests are much easier

• Encapsulate repetition into partials

• Big (unattainable goal): Can all design changes happen in CSS?

  • Markup is the copy
  • Models are the logic
  • CSS ought to be all the design

• Challenges: Mostly emotional

  • Devs think that some changes are stupid
  • Designers think that what devs make is ugly
  • Compromise!
  • Be a part of the process

• Designers AND Developers, not Designers VS Developers

• Also creates a conversation between you and your users

  • Users see their money being applied to visible changes
  • Big changes are bad (see Facebook)