Skip to content

Instantly share code, notes, and snippets.

@jamesgary

jamesgary/gist:5485643

Created April 29, 2013 23:35
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save jamesgary/5485643 to your computer and use it in GitHub Desktop.
Save jamesgary/5485643 to your computer and use it in GitHub Desktop.
Download ZIP
Incremental Design - Rebecca Miller-Webster and Savannah Wolf - RailsConf 2013
Raw
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment