|
|
@@ -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) |
jamesgary renamed this gist