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

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

on

  • 2,362 views

Presented at the Agile2011 conference.

Presented at the Agile2011 conference.

Statistics

Views

Total Views
2,362
Views on SlideShare
2,359
Embed Views
3

Actions

Likes
7
Downloads
0
Comments
1

2 Embeds 3

http://www.onlydoo.com 2
https://twimg0-a.akamaihd.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • Why Can’t We All Just Get Along?
      Improving Designer/Developer Collaboration
      Agile 2011 - August 2011
      Allison Corbett
      Copyright © 2011 CA Technologies
    • Welcome
    • Overview
      Mythbusting
      Exercise 1
      Improving collaboration by improving the process
      Exercise 2
      Agile collaboration tools
      Tips & techniques
      Exercise 3
      Wrapup and questions
    • Mythbusting
    • “Developers don’t care about the user experience.”
    • “Designers just make
      things look pretty”
    • “Developers are lazy”
    • “Designers don’t care how hard it is to implement”
    • “Design isn’t a real skill
      like programming”
    • “Developers aren’t creative”
    • “Developers are from Mars, designers are from Venus”
    • Exercise 1: In Their Shoes
      In Their Shoes
    • Exercise 1: In Their Shoes
      What do they want?
      What are they afraid of?
      What pressures are they under?
      • Developer
      • Designer
      • Product Owner
    • Lightning Introduction to User-Centered Design
    • 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.
    • 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)
    • Design Specializations
      User research
      Information architecture
      UI Engineering
      Final UI
      Visual design
      Interaction design
      User Experience Design (UX)
    • The UCD Cycle
      Learn
      Validate
      Design
    • Agile vs. UCD
    • Improving collaboration by improving the process
    • 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?
    • An Hour Later…
      we’re hungry, and we don’t really care anymore. here’s a
      WILD GUESS.
      ???
    • 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.
    • 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
    • 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.
    • 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!!
    • 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
    • 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.
    • Agile Collaboration Tools
    • Agile Communication Tools
      Look for the minimum required to communicate.
      Sketching
      Paper prototypes
      Wireframes
      Rapid prototyping tools
      Prototyping in code
      Collaborative implementation
      Lightweight documentation
    • 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!
    • Paper Prototypes
    • Wireframes
    • Wireframes can get more elaborate…
    • Wireframes can get more elaborate…
    • Rapid Prototyping Tools
    • Prototyping in Code
    • 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.
    • Lightweight Documentation
      Email
      IM
      User stories/acceptance criteria
      Wikis
      All members of the team should contribute.
    • 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…
    • Tips & Techniques
    • 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.
    • The Importance of Implementation
      Design Quality
      Team 1
      Design Quality
      Team 2
      0%
      100%
    • The Importance of Implementation
      Design Quality
      Team 1
      % Built
      Design Quality
      Team 2
      % Built
      0%
      100%
    • 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.
    • 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.
    • 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.
    • 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.
    • 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
    • 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.
    • 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.
    • The Fine Art of Constructive Feedback
      Source: http://theoatmeal.com/comics/design_hell
    • 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.
    • 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!)
    • Exercise 3: Solve Each Other’s Problems
    • Wrapup & Questions
      In conclusion
      Questions and comments?
      Contact me:
      Allison Corbett
      allison.corbett@ca.com
    • Recommended Reading - UX