paper & pencil

Integrating UX & Agile

Last week I attended a panel on integrating user experience into Agile development, put on by the Western NY Human Factors and Ergonomics Society (WNYHFES). The panel was interesting in that I learned more and more companies are embracing Agile in some way. However, there was not nearly enough time spent on how to integrate user experience methods into the process. Maybe there can be a part two.

What I'd like to see in a part two is more on cycle 0 and the UX processes that need to occur outside of and before Agile development begins. And more on how  to *design* in a more agile fashion. Rick Cecil's article for UXMatters addresses some of these topics. Lastly, a question from the audience on how to use Agile within fixed price projects could use further exploration as these are a fact of life for many agencies.

Here are my notes:

• Development is broken into shorter, smaller chunks: Analysis > Design > Coding > Testing
• Testing phases are informal, more like unit testing
• No clear answer on doing end-to-end testing
• Addresses the challenge of not knowing everything up front
• Add features as you determine need with users
• Mostly used with smaller teams
• Constant communication with developers, testers, stakeholders, etc.
• Can solve problems faster as they come up
• Agile assumes 1) everything is not known early; 2) discovery throughout
• Focus on delivering working code to customers at frequent intervals
• Constant collaboration to deal with new discoveries and to move forward
• Can be done (and is) with remote teams
• UX/UCD works 1 cycle ahead of development

Best part of the presentation was the following diagram from Desirée Sy's paper Adapting Usability Investigations for Agile User-centered Design.

---

Image above is from The Journal of Usability Studies, Vol. 2, Issue 3, May 2007, pp. 118 and reuse is subject to the following:

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 2006, ACM.

Notes from UX London

Luke Wroblewski posted his notes from UX London:

• e-service, Eric Reiss
• Designing from the Inside Out: Behavior as the Engine of Product Design, Dan Saffer
• What Makes a Design Seem Intuitive, Jared Spool
• Designing Our Way Through Data, Jeff Veen
• In Favour of Complexity, Don Norman
• Parti & The Design Sandwich, Luke Wroblewski
  • live tweet notes from Leisa Reichelt

Some great bits & pieces:

Service is 100% about user experience. User experience is not 100% about service.

Behavior can be a major product differentiator and can be a defense against feature-itis.

Features are a poor long -term strategy as they will be built by competitors. Its easy to replicate features but hard to replicate how features behave.

Start from the behavior, and then figure out what should control it. The physical form, UI elements on the screen, or even gestures in a space.
Behavior drives the form and mechanics.

An entire system’s complexity is unchanged. You just can move complexity around. By making it easier for the programmer me make things harder for the user.

When a new consumer good is released to the world, reviewers get a hold of it. Reviewers, salespeople, and feature-minded marketing are the reason for needless complexity.

The distinction for me between best practices and patterns is nuanced –a pattern is a way you can do things in a specific context. A best practice is the way you SHOULD do things in a specific context.

When is it “Useable Enough?”

Notes from the UIE Brain Sparks podcast: Userability #9 - When is it "Useable Enough?"

• Establish metrics for what is considered usable enough, e.g. 80% task completion, 90% satisfaction
• Check out Measuring the User Experience
• "Get to point of least astonishment", no more surprises during usability testing
• Getting new results with each user, keep testing
• Incomplete tasks - is the reason expected or a surprise
• Tasks can be completed as expected = usable enough for beta release
• Problem areas are not deemed large enough to hold off releasing in beta
• Surprises after release, unexpected responses = didn't do enough work and testing (think anytime Facebook releases anything new or changed)
• "Most people, most of the time"

Designers do it in groups

Robert Hoekman, Jr. says better solutions come from designing in groups. I absolutely agree.

Design is a group activity. The small team beats the lone genius every time. No one individual will have all the best answers. The best answers come from groups. The best ideas are the result of collaboration.

All of my designs have been improved after reviewing and collaborating with developers, business stakeholders, testers, etc. Software is complex and requires insight from all sides - business, technical, design, users.

Although, collaboration almost sounds too nice of a word, as if we're all holding hands and singing while marking up a wireframe. Maybe negotiation is more accurate? The best solutions I've been a part of have always come out of heated discussions, wrestling against multiple constraints.

The Lifecycle of a Wireframe

Nick Finck posted slides from his Puget Sound SIGCHI lecture on The Lifecycle of a Wireframe. Some slides are repeated and it's not clear why without hearing the presentation but it contains a great summary of key concepts and questions an IA should always be aware of.

The Life Cycle of a Wireframe

View more Microsoft Word documents from Nick Finck.

My overall strategy for IA is 3 step process; understanding the problem (note: not merely identifying the problem but really understanding it), find a solution (there may be more than one solution, but there is often only one right solution), and present the solution (a large part of your job as a IA is presenting your work so the client can understand the results).