Your SlideShare is downloading. ×
Why Can't We All Just Get Along? Improving Designer/Developer Collaboration
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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


Published on

Presented at the Agile2011 conference.

Presented at the Agile2011 conference.

Published in: Technology, Business

1 Comment
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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
    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
  • 13. Exercise 1: In Their Shoes
    What do they want?
    What are they afraid of?
    What pressures are they under?
  • Lightning Introduction to User-Centered Design
  • 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.”
    (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
  • 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
  • 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
    -Design for sprint 2
    - User input for sprint 3
    -Design for sprint 3
    -User input for sprint 4
    Data gathering
    High-level design
    Implement high dev/ low UI features
    Implement designs
    Implement designs
    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.
  • 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.
    Paper prototypes
    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!
  • 33.
  • 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
    User stories/acceptance criteria
    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
  • 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
  • 46. The Importance of Implementation
    Design Quality
    Team 1
    % Built
    Design Quality
    Team 2
    % Built
  • 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
    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
  • 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
  • 59. Recommended Reading - UX