Skip to content

Instantly share code, notes, and snippets.

@jamesgary

jamesgary/gist:5485643

Created April 29, 2013 23:35
Show Gist options
  • 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

Revisions

  1. jamesgary renamed this gist Apr 29, 2013. 1 changed file with 0 additions and 0 deletions.
    0 gistfile1.txt → gistfile1.md
    View file
    File renamed without changes.
  2. jamesgary created this gist Apr 29, 2013.
    74 changes: 74 additions & 0 deletions gistfile1.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,74 @@
    ## 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)