Showing posts with label patton. Show all posts
Showing posts with label patton. Show all posts

Friday, February 12, 2010

Real World Agile User Experience Design - Jeff Patton (Part III)

I covered the first six patterns Jeff Patton says user experience designers picked up from Agile in Part II. Here we'll cover the last seven.

7. Schedule continuous user research in a separate track from development. You can picture this as an intersection of a few of the previous patterns: cultivating your user pool, chunking the design, and use parallel track development. The goal is to smooth out the design process so that it is stable and flowing into and out of development without being dependent on stages or waiting for a piece of functionality to complete. If developers decide, or their schedule dictates, when user research occurs, the natural breakpoints create a stop/start feel to design that interrupts the agile velocity (pacing) all groups should experience.

8. Leverage time with users for multiple activities - avoid thrashing your users by scheduling distinct meetings for distinct activities regardless of the time involved. Again, aim for creating a sense of continuous pace by having multiple goals for users to consider, including looking forward and backward as well as working within the current iteration.

9. Use RITE to iterate the UI (design) before development. Rapid Iterative Testing and Evaluation evaluates testing at the end of each day or after each participant, making changes to the interface almost immediately (if you need more information about RITE, this is a good slide show).

10. Design and prototype at the lowest fidelity possible. we've talked about the ease of use and portability of whiteboards before. Low fidelity means doing your design on a whiteboard as well, or some other easily portable, easily modifiable medium. Don't get carried away with using the latest tool, only to be trapped spending excessive time converting. From the tool to Visio. From Visio to Powerpoint. From Powerpoint to the wiki. Ad naseum. We've all done it. Instead, start simple and take a picture. Avoid formatting as an occupational time sink.

11. Treat the prototype as the specification. If you think you have a hard time with this, I suggest spending some time in my group at work (migration) and you'll realize there's a group more antithetical to this viewpoint than your own. But even within my group, we see places where this approach makes a certain amount of sense. Some of our projects are particularly heavy on design and proof of concept, and the POC drives subsequent development. It's not that simple, and invariably we find ourselves tracking backward to recreate the necessary documents and fit within the approved process flow - part of the tax of a large company - but the POC or prototype is still the heart of the project, and when we revisit requirements and design, it's that prototype we reexamine to determine the outflow.

12. Designer-developers iterate visual design outside the development timebox. Don't feel constrained to always finish up all cycles in all spaces simultaneously. After all, slavish devotion to aligning deadlines, despite the actual temp of productivity, is more characteristic of waterfall than Agile. Visual design is necessarily going to overlap development iterations as it captures the results of refactoring and attempts to anticipate new UI direction based on refinement of personas, interviews with customers, and reaction to new functionality (and customer feedback on that functionality).

13. Become a design facilitator. Patton's baker's dozen is rounded out with a bit of advice that applies to the previous twelve points. Learn some of the core skills of Agile: socialize, share, collaborate. Learn to communicate and increase communication touchpoints so that interactions are driving the betterment of your project. Patton offered some sayings/quotes to remember to keep that collaborative focus:
  • "Design is not an artifact. It is a process."
  • "Design is something that is done. It is not a role."
  • and my favorite... "Design by community is not design by committee." (Leisa Reichert)

Thursday, February 04, 2010

Real World Agile User Experience Design - Jeff Patton (Part II)

So what are User Experience designers learning from Agile now that the methodology has left its impact? Patton identifies thirteen patterns:

  1. Drive: usability practitioners as part of the product team or as product owners. This is a good thing, but be careful about backseat driving.
  2. Research modeling and design up front - this should happen, but only just enough. As (Alan) Cooper stated, there almost needs to be a Sprint Zero (0) or Iteration Zero (0) where product discovery can happen.
  3. Chunk your design work - design work should, when possible, be handled in manageable chunks. We've all heard of sprints to investigate and dig into unknown (un-estimateable) pieces of functionality, but some digs can be too big to achieve in an iteration, particularly without an evolved basis for design decisions (understanding your decisions provides a context for future decisions...makes sense). It's important to know, Patton says, what's a napkin and what's higher level when it comes to design. To ensure these decisions can be evaluated accurately and chunked appropriately, some work can be done in advance (here we start to cross paths with Alan Cooper once again): a.) pragmatic personas can be developed, evolving from lightweight personas, usability sketches, and provisional personas; b.) backlogs can evolve into story maps and task analysis grids. Patton recommends The New Backlog is a Map as an evolutionary step; c.) start your usability investigations for Agile-centered design early, using tools like Sketchbook Pro (product). To give this point some relevance, think of internal projects, even Agile ones, that seemed to lose their way architecturally for a time. A lot of drift is expected in Agile, but it should be controlled drift, not the kind that comes from a loss of vision leading to meeting bloat and a feeling like the rudder has slipped the hand. A solid design should allow informed decision making and course correction rather than directionless floating in some Sargasso Sea.
  4. Use parallel track development to work ahead and follow behind. What the product owner team is working on should apply to the previous, current, and upcoming iterations. Design and coded features should be passing back and forth between them and the development team.
  5. Buy design time with complex engineering stories. Play a balancing game. Look in the story map and determine which stories are heavy on design and which are heavy on development. try to level by pushing lightweight design with heavy development to the front of an iteration (or even the whole project) to give developers something to do while they heavy design stories are researched. this plays hand-in-hand with chunking your design work so you know how the chunks fit on either side of your fulcrum.
  6. Cultivate a pool of users for continuous user validation. Having to find new users each time a piece of functionality is considered can be a drain on a project and can delay design decisions. Identifying responsive users, ensuring a pool large enough to cover gaps (vacations, et al), and building a relationship and sense of pace with them results in more nimble design decisions.