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)
No comments:
Post a Comment