## 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)