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

7230Re: Integrated Usability in Agile teams from the trenches :)

Expand Messages
  • SvetlanaTsikoza
    Feb 3, 2011
      Thank you very much for sharing your experience. It is very useful. The comment about iRise made me smile :-) Let me shake your hand, comrade.

      --- In agile-usability@yahoogroups.com, Robin Dymond <robin.dymond@...> wrote:
      >
      > I recently replied to someone on linked in 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