Loading ...
Sorry, an error occurred while loading the content.

7229Integrated Usability in Agile teams from the trenches :)

Expand Messages
  • Robin Dymond
    Feb 2, 2011
    • 0 Attachment
      I recently replied to someone on a Linkedin group who was having trouble integrating UX people into an Agile team. Below is my step by step reply on how to do UX in an Agile manner. I'd be interested in hearing your thoughts on this pattern.

      I was a technology Director in a large web design company 6 years ago, and they failed at adopting Agile for the reasons you mention. Primarily it was a case of not wanting reality to hinder the pretty designs they were making in photoshop or Illustrator. Of course there were huge issues when these artifacts met the reality of enterprise architectures on the development floor. This resulted in missed deadlines, high stress, low code quality, and 40% annual turnover in IT staff. Being at this company spurred my interest in UX and Agile, and I have since found basic solutions that work when people want to do Agile. However I would say that of all the disciplines in creating software and especially web sites, UX people are the slowest and most resistant to adopting Agile principles and practices.

      Here is the way I work with UI designers and Information architects who want to work Agile:
      1. Product backlog and its priorities drives all the work. So we work from business priorities not UI priorities.
      2. Sketch the highest level level UI for the site. no drill downs into buy flows, just top level.
      3. Look at the backlog and start thinking about what the team will need for UI 1/2 an iteration ahead.
      4. Make paper prototypes (sketches, paper menus, paper buttons) to support upcoming user stories for next sprint. Don't embellish with new features UX thinks would be cool. KISS. Include validation and other acceptance criteria for fields. Reference style guide as required. Reference page templates as required. I call this a 1 page design spec.
      5. Review prototypes with PO, QA and lead dev a few days before sprint planning, ensure they think it is good enough and it is testable. Keep notes regarding potential trade offs.
      5a. Check in design docs, version them.
      6. Participate in sprint planing with rest of team.
      7. Work with team on implementation, clarify details of design (dimensions, locations, behavior, etc.). Work with QA on test plans for new UI. Help build UI (HMTL/CSS/PHP/etc) in dev IDE, pair with dev as they wire it up. Pair with QA to run test cases and implement automated UI testing (Ruby/WATIR, etc).
      8. repeat for every sprint.

      Additional stuff I think is needed.
      - Create a style guide for the team and have them read it, listen to their feedback and improve it.
      - Create templates: every page is not a unique creation. Refer to those templates in prototypes and design spec.
      - Test your paper prototypes with users by asking them to do certain operations and then observing the resulting actions. Don't worry about big usability testing at end, do it often and informally with people who are easy to access and know enough about that business.
      - Break dependencies between UI/layout and business logic. agree on data/fields/controls at beginning so business logic can be rendered to a very simple layout free page.

      An unstable UI design is usually driven by a lack of knowledge about the customer requirements and technical limitations. The product backlog is probably not in very good shape so the UI person has to go find out a lot of detail to create the design. The UI designer is likely having to make up for lack knowledge in the PO.

      ...and avoid iRise and its ilk!!!

      I hope this helps,
      Robin Dymond. CST

    • Show all 10 messages in this topic