Why Can't We All Just Get Along? Improving Designer/Developer Collaboration


Published on

Presented at the Agile2011 conference.

Published in: Technology, Business

Why Can't We All Just Get Along? Improving Designer/Developer Collaboration

  1. 1. Why Can’t We All Just Get Along?<br />Improving Designer/Developer Collaboration<br />Agile 2011 - August 2011<br />Allison Corbett<br />Copyright © 2011 CA Technologies<br />
  2. 2. Welcome<br />
  3. 3. Overview<br />Mythbusting<br />Exercise 1<br />Improving collaboration by improving the process<br />Exercise 2<br />Agile collaboration tools<br />Tips & techniques<br />Exercise 3<br />Wrapup and questions<br />
  4. 4. Mythbusting<br />
  5. 5. “Developers don’t care about the user experience.”<br />
  6. 6. “Designers just make <br />things look pretty”<br />
  7. 7. “Developers are lazy”<br />
  8. 8. “Designers don’t care how hard it is to implement”<br />
  9. 9. “Design isn’t a real skill <br />like programming”<br />
  10. 10. “Developers aren’t creative”<br />
  11. 11. “Developers are from Mars, designers are from Venus”<br />
  12. 12. Exercise 1: In Their Shoes<br />In Their Shoes<br />
  13. 13. Exercise 1: In Their Shoes<br />What do they want?<br />What are they afraid of? <br />What pressures are they under?<br /><ul><li>Developer
  14. 14. Designer
  15. 15. Product Owner</li></li></ul><li>Lightning Introduction to User-Centered Design<br />
  16. 16. The Case for Design<br />Design is becoming a major competitive advantage. <br />Consumer Web apps have raised the bar.<br />Aesthetics and usability count. <br />Word of mouth and peer-to-peer feedback is more accessible than ever before. <br />Design is happening, whether or not you have “designers.”<br />Design is a skill set. <br />
  17. 17. Lightning Introduction to UCD<br />“[U]ser-centered design (UCD)…is a design philosophy and a process in which the needs, wants, and limitations of end users of a product are given extensive attention at each stage of the design process…<br />…User-centered design tries to optimize the product around how users can, want, or need to use the product, rather than forcing the users to change their behavior to accommodate the product.”<br />Source: http://en.wikipedia.org/wiki/User-centered_design<br />(emphasis mine)<br />
  18. 18. Design Specializations<br />User research<br />Information architecture<br />UI Engineering<br />Final UI<br />Visual design<br />Interaction design<br />User Experience Design (UX)<br />
  19. 19. The UCD Cycle<br />Learn<br />Validate<br />Design<br />
  20. 20. Agile vs. UCD<br />
  21. 21. Improving collaboration by improving the process<br />
  22. 22. A typical sprint-planning session<br />well, option A will take 2 DAYS, but option B will take 3 WEEKS. which do we want?<br />okay, everyone ready to ESTIMATE?<br />it DEPENDS. i’d really like to explore options C, D, and possibly E. and what are the answers to these 20 questions?<br />um, not REALLY. <br />i don’t know. we haven’t done requirements yet. can’t we just ESTIMATE?<br />
  23. 23. An Hour Later…<br />we’re hungry, and we don’t really care anymore. here’s a <br />WILD GUESS.<br />???<br />
  24. 24. Tip: Get Design Ahead of Development<br />If design isn’t ahead:<br />Developers wait, OR<br />Developers go ahead and do it anyway<br />Design ahead = story prioritization and requirements ahead. <br />Design and development should participate in prioritization and requirements-gathering. <br />
  25. 25. Parallel Design and Development<br />-Integrate/ test for sprint 3<br />-Design for <br />sprint 4<br />-User input for sprint 5<br />Designers<br />-Design for sprint 2<br />- User input for sprint 3<br />-Design for sprint 3<br />-User input for sprint 4<br />Planning<br />Data gathering<br />High-level design<br />Implement high dev/ low UI features<br />Implement designs<br />Implement designs<br />Developers<br />Sprint 0<br />Sprint 1<br />Sprint 2<br />Sprint 3<br />
  26. 26. Tip: Use Pre-Work to Improve Estimation<br />Before sprint planning (preferably a sprint ahead): <br />Prioritize stories in backlog. <br />Perform initial analysis and requirements-gathering. <br />Note requirements and/or acceptance criteria in stories. <br />Create initial designs. <br />Review designs.<br />Revise designs (iteratively, if time permits). <br />Optional: pre-enter tasks and/or estimates. <br />
  27. 27. The Next Time…<br />okay, let’s walk through the detailed acceptance criteria we’ve entered.<br />you’ve all reviewed my MOCKUPS, but here they are on the projector again, just in case.<br />okay, everyone ready to ESTIMATE?<br />we all agree it will <br />take two weeks, and <br />we’ve already entered our tasks.<br />LUNCH TIME!!<br />
  28. 28. Exercise 2: Common Problems<br />For each symptom, brainstorm: <br />Why might this be happening? <br />What’s motivating the people involved? (Hint: think wants/fears)<br />Ideas for improving the situation<br />
  29. 29. Symptoms<br />The designers are busy designing, but most of their designs never get implemented. <br />Developers are resentful because they have to redo work multiple times. <br />Sprint planning meetings are tense, run way over and/or everyone leaves exhausted and demoralized. <br />The team has difficulty completing stories on time. <br />The team doesn’t have designers at all. <br />
  30. 30. Agile Collaboration Tools<br />
  31. 31. Agile Communication Tools<br />Look for the minimum required to communicate. <br />Sketching<br />Paper prototypes<br />Wireframes<br />Rapid prototyping tools<br />Prototyping in code<br />Collaborative implementation<br />Lightweight documentation<br />
  32. 32. Sketching<br />Whiteboard or pen and paper<br />Can include collaborative and/or participatory design<br />Can be easily turned into paper prototypes<br />Can be used as the basis for development (especially if team is short on time)<br />Does not require an art degree! <br />
  33. 33.
  34. 34. Paper Prototypes<br />
  35. 35. Wireframes<br />
  36. 36. Wireframes can get more elaborate…<br />
  37. 37. Wireframes can get more elaborate…<br />
  38. 38. Rapid Prototyping Tools<br />
  39. 39. Prototyping in Code<br />
  40. 40. Collaborative Implementation<br />Designer and developer work closely during implementation. <br />Developer focuses on functionality<br />Designer focuses on interactions and/or presentation. <br />Work together or pass back and forth files or snippets. <br />Designer reviews implementation on developer’s local machine as soon as it’s built. <br />
  41. 41. Lightweight Documentation<br />Email<br />IM<br />User stories/acceptance criteria<br />Wikis<br />All members of the team should contribute. <br />
  42. 42. Takeaways<br />To the person with a hammer, everything is a nail. <br />Build a toolbox<br />Pick the right tool for the project/team/situation. <br />Ask the team what tool fits. <br />These are by no means the only possible tools: <br />Design studio<br />Usability testing<br />Contextual inquiry<br />Affinity mapping<br />Etc…<br />
  43. 43. Tips & Techniques<br />
  44. 44. For Designers<br />Involve the developers early in the process. <br />Be familiar with the development frameworks the team is using.<br />Be able to help with implementation. <br />For Web apps, know HTML and CSS (and maybe JavaScript). <br />The more you know about implementation, the more likely your designs are to get built. <br />Choose your battles wisely, and focus on the core problem.<br />Encourage developer feedback on your designs. <br />
  45. 45. The Importance of Implementation<br />Design Quality<br />Team 1<br />Design Quality<br />Team 2<br />0%<br />100%<br />
  46. 46. The Importance of Implementation<br />Design Quality<br />Team 1<br />% Built<br />Design Quality<br />Team 2<br />% Built<br />0%<br />100%<br />
  47. 47. For Developers<br />Know how your dev technologies render the final interface. <br />Separate content/behavior/presentation.<br />Keep an open mind, listen for the underlying problem, and suggest easier-to-implement solutions. <br />Provide constructive design feedback. <br />Review the design deliverables thoroughly and ask questions before building. <br />Take notes.<br />Communicate deadlines. <br />
  48. 48. For Product Owners and Project Mgrs<br />Involve both designers and developers in strategy and requirements-gathering.<br />Drive towards solid requirements early in the process. <br />Make sure that developers have the appropriate context. <br />Provide prompt, detailed, and constructive feedback. <br />Help your team balance user needs and technical constraints.<br />Advocate for (and attend) user research and testing. <br />
  49. 49. For Scrummasters<br />Encourage (and model) an atmosphere of respect. <br />Facilitate pre-work for upcoming sprints. <br />Keep sprint planning and retrospectives moving. <br />Watch for design/dev conflicts brewing and help get the team back on track. <br />Help team members juggle multiple projects. <br />Encourage developers to participate in strategy, requirements-gathering, and usability testing. <br />
  50. 50. For Everyone<br />Everyone on the team is working towards the same goal, and all roles are important for a successful outcome. <br />Foster an atmosphere of respect and curiosity.<br />Some conflict is unavoidable. <br />Team members will—and should—advocate for their areas of specialization. <br />The goal is to disagree in a respectful and productive way. <br />Focus on identifying and solving the real problem. <br />Look for gaps to fill. <br />Respect your coworkers’ skills and training. <br />When all else fails, maintain a sense of humor. <br />
  51. 51. Language Matters<br />What you said: <br />What your designer hears: <br />apisproc call restful web service jboss user compile class object framework css presentation layer lunch<br />blah blahblahblah USER blah blah blah CSS blah blah LUNCH<br />
  52. 52. Language Matters<br />What you said: <br />What your developer hears: <br />mental models css class usability testing wireframe card sorting persona #eeeeee context switching metrics user experience fitt’s law<br />more work. <br />ugly code.<br />
  53. 53. The Art of Civil Disagreement<br />Listen. <br />Ask questions. <br />Avoid trench warfare.<br />Be willing to explain your assumptions and your thought process <br />Recognize the value of an outside opinion.<br />Acknowledge good points and good ideas. <br />Choose your battles. <br />Learn to lose gracefully. <br />
  54. 54. The Fine Art of Constructive Feedback<br />Source: http://theoatmeal.com/comics/design_hell <br />
  55. 55. The Fine Art of Constructive Feedback<br />Evaluate based on how well the design meets the agreed-upon goals, not upon personal opinion. <br />Begin and end with positive feedback.<br />Designers need to know what’s working to avoid “throwing out the baby with the bathwater.” <br />Sincere positive feedback makes criticism easier to digest. <br />Ask questions. <br />Have an opinion. <br />Be specific and concrete. <br />Resist the temptation to redesign.<br />
  56. 56. Where to Start?<br />Pick one design-heavy story that’s still a sprint or two out as a test case. <br />Do as much requirements-gathering and design as possible before sprint planning. <br />Put detailed acceptance criteria into your planning tool. <br />Use acceptance criteria and designs for estimation.<br />See what happens (and revise if/when necessary!)<br />
  57. 57. Exercise 3: Solve Each Other’s Problems<br />
  58. 58. Wrapup & Questions<br />In conclusion<br />Questions and comments? <br />Contact me: <br />Allison Corbett<br />allison.corbett@ca.com<br />
  59. 59. Recommended Reading - UX<br />