Presented at the Agile2011 conference.

1. Why Can’t We All Just Get Along? Improving Designer/Developer Collaboration Agile 2011 - August 2011 Allison Corbett Copyright © 2011 CA Technologies

2. Welcome

3. Overview Mythbusting Exercise 1 Improving collaboration by improving the process Exercise 2 Agile collaboration tools Tips & techniques Exercise 3 Wrapup and questions

4. Mythbusting

5. “Developers don’t care about the user experience.”

6. “Designers just make things look pretty”

7. “Developers are lazy”

8. “Designers don’t care how hard it is to implement”

9. “Design isn’t a real skill like programming”

10. “Developers aren’t creative”

11. “Developers are from Mars, designers are from Venus”

12. Exercise 1: In Their Shoes In Their Shoes

14. Designer

16. The Case for Design Design is becoming a major competitive advantage. Consumer Web apps have raised the bar. Aesthetics and usability count. Word of mouth and peer-to-peer feedback is more accessible than ever before. Design is happening, whether or not you have “designers.” Design is a skill set.

17. Lightning Introduction to UCD “[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… …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.” Source: http://en.wikipedia.org/wiki/User-centered_design (emphasis mine)

18. Design Specializations User research Information architecture UI Engineering Final UI Visual design Interaction design User Experience Design (UX)

19. The UCD Cycle Learn Validate Design

20. Agile vs. UCD

21. Improving collaboration by improving the process

22. A typical sprint-planning session well, option A will take 2 DAYS, but option B will take 3 WEEKS. which do we want? okay, everyone ready to ESTIMATE? it DEPENDS. i’d really like to explore options C, D, and possibly E. and what are the answers to these 20 questions? um, not REALLY. i don’t know. we haven’t done requirements yet. can’t we just ESTIMATE?

23. An Hour Later… we’re hungry, and we don’t really care anymore. here’s a WILD GUESS. ???

24. Tip: Get Design Ahead of Development If design isn’t ahead: Developers wait, OR Developers go ahead and do it anyway Design ahead = story prioritization and requirements ahead. Design and development should participate in prioritization and requirements-gathering.

25. Parallel Design and Development -Integrate/ test for sprint 3 -Design for sprint 4 -User input for sprint 5 Designers -Design for sprint 2 - User input for sprint 3 -Design for sprint 3 -User input for sprint 4 Planning Data gathering High-level design Implement high dev/ low UI features Implement designs Implement designs Developers Sprint 0 Sprint 1 Sprint 2 Sprint 3

26. Tip: Use Pre-Work to Improve Estimation Before sprint planning (preferably a sprint ahead): Prioritize stories in backlog. Perform initial analysis and requirements-gathering. Note requirements and/or acceptance criteria in stories. Create initial designs. Review designs. Revise designs (iteratively, if time permits). Optional: pre-enter tasks and/or estimates.

27. The Next Time… okay, let’s walk through the detailed acceptance criteria we’ve entered. you’ve all reviewed my MOCKUPS, but here they are on the projector again, just in case. okay, everyone ready to ESTIMATE? we all agree it will take two weeks, and we’ve already entered our tasks. LUNCH TIME!!

28. Exercise 2: Common Problems For each symptom, brainstorm: Why might this be happening? What’s motivating the people involved? (Hint: think wants/fears) Ideas for improving the situation

29. Symptoms The designers are busy designing, but most of their designs never get implemented. Developers are resentful because they have to redo work multiple times. Sprint planning meetings are tense, run way over and/or everyone leaves exhausted and demoralized. The team has difficulty completing stories on time. The team doesn’t have designers at all.

30. Agile Collaboration Tools

31. Agile Communication Tools Look for the minimum required to communicate. Sketching Paper prototypes Wireframes Rapid prototyping tools Prototyping in code Collaborative implementation Lightweight documentation

32. Sketching Whiteboard or pen and paper Can include collaborative and/or participatory design Can be easily turned into paper prototypes Can be used as the basis for development (especially if team is short on time) Does not require an art degree!

34. Paper Prototypes

35. Wireframes

36. Wireframes can get more elaborate…

37. Wireframes can get more elaborate…

38. Rapid Prototyping Tools

39. Prototyping in Code

40. Collaborative Implementation Designer and developer work closely during implementation. Developer focuses on functionality Designer focuses on interactions and/or presentation. Work together or pass back and forth files or snippets. Designer reviews implementation on developer’s local machine as soon as it’s built.

41. Lightweight Documentation Email IM User stories/acceptance criteria Wikis All members of the team should contribute.

42. Takeaways To the person with a hammer, everything is a nail. Build a toolbox Pick the right tool for the project/team/situation. Ask the team what tool fits. These are by no means the only possible tools: Design studio Usability testing Contextual inquiry Affinity mapping Etc…

43. Tips & Techniques

44. For Designers Involve the developers early in the process. Be familiar with the development frameworks the team is using. Be able to help with implementation. For Web apps, know HTML and CSS (and maybe JavaScript). The more you know about implementation, the more likely your designs are to get built. Choose your battles wisely, and focus on the core problem. Encourage developer feedback on your designs.

45. The Importance of Implementation Design Quality Team 1 Design Quality Team 2 0% 100%

46. The Importance of Implementation Design Quality Team 1 % Built Design Quality Team 2 % Built 0% 100%

47. For Developers Know how your dev technologies render the final interface. Separate content/behavior/presentation. Keep an open mind, listen for the underlying problem, and suggest easier-to-implement solutions. Provide constructive design feedback. Review the design deliverables thoroughly and ask questions before building. Take notes. Communicate deadlines.

48. For Product Owners and Project Mgrs Involve both designers and developers in strategy and requirements-gathering. Drive towards solid requirements early in the process. Make sure that developers have the appropriate context. Provide prompt, detailed, and constructive feedback. Help your team balance user needs and technical constraints. Advocate for (and attend) user research and testing.

49. For Scrummasters Encourage (and model) an atmosphere of respect. Facilitate pre-work for upcoming sprints. Keep sprint planning and retrospectives moving. Watch for design/dev conflicts brewing and help get the team back on track. Help team members juggle multiple projects. Encourage developers to participate in strategy, requirements-gathering, and usability testing.

50. For Everyone Everyone on the team is working towards the same goal, and all roles are important for a successful outcome. Foster an atmosphere of respect and curiosity. Some conflict is unavoidable. Team members will—and should—advocate for their areas of specialization. The goal is to disagree in a respectful and productive way. Focus on identifying and solving the real problem. Look for gaps to fill. Respect your coworkers’ skills and training. When all else fails, maintain a sense of humor.

51. Language Matters What you said: What your designer hears: apisproc call restful web service jboss user compile class object framework css presentation layer lunch blah blahblahblah USER blah blah blah CSS blah blah LUNCH

52. Language Matters What you said: What your developer hears: mental models css class usability testing wireframe card sorting persona #eeeeee context switching metrics user experience fitt’s law more work. ugly code.

53. The Art of Civil Disagreement Listen. Ask questions. Avoid trench warfare. Be willing to explain your assumptions and your thought process Recognize the value of an outside opinion. Acknowledge good points and good ideas. Choose your battles. Learn to lose gracefully.

54. The Fine Art of Constructive Feedback Source: http://theoatmeal.com/comics/design_hell

55. The Fine Art of Constructive Feedback Evaluate based on how well the design meets the agreed-upon goals, not upon personal opinion. Begin and end with positive feedback. Designers need to know what’s working to avoid “throwing out the baby with the bathwater.” Sincere positive feedback makes criticism easier to digest. Ask questions. Have an opinion. Be specific and concrete. Resist the temptation to redesign.

56. Where to Start? Pick one design-heavy story that’s still a sprint or two out as a test case. Do as much requirements-gathering and design as possible before sprint planning. Put detailed acceptance criteria into your planning tool. Use acceptance criteria and designs for estimation. See what happens (and revise if/when necessary!)

57. Exercise 3: Solve Each Other’s Problems

58. Wrapup & Questions In conclusion Questions and comments? Contact me: Allison Corbett allison.corbett@ca.com

59. Recommended Reading - UX