Controlling an Unpredictable Process - Iterations

Process flows are diagrams used to indicate the path a user must follow in order to complete a task in a website or application. A flow diagram is often an essential artifact for UX specialists (especially in the beginning of a project) because it helps solidify how users interact with a system and clarify where the system's complexities lie. Once a process flow is finalized, sitemaps and wireframes often follow. Most process flows presented here make use of a special symbology created specifically for information architecture and interaction design. Since many of the typical computer science-related flowchart symbols don't quite work for user experience specialists, a new set of symbols was created to better suit our needs. However, the basic tenets of flow chart creation still apply, and you don't need to be intimately familiar with UX-flavored flow charting to follow a process flow for user centered designs.

So how do we control project lifecycles in an unpredictable world? The most important, and still difficult part is to know accurately where we are, and where we want to be. Developers, Business Owners, and Designers need honest feedback and a mechanism which can accurately tell them what the situation is at frequent intervals.

The key to this feedback is iterative development. This is not a new idea, and many methodoligies proclaim to use this the best. Iterative development has been around for a while under many names: incremental, evolutionary, staged, spiral... lots of names. The key to iterative development is to frequently produce working models of the final system that have a subset of the required features with wireframes, workflows or working prototypes. These working models should accurately depict the layout and design of the final product. These representations of the final application should be carefully tested before the developers build the code and the users ultimately see it in the final delivery of the application.

The point of iterative documentation is that there is nothing like a tested, documented design for bringing a forceful dose of reality into any project. Extensive iterative documentation can reveal all sorts of flaws before you get into the development and workflow of the application. Untested designs can hide plenty of flaws. But when people actually sit in front of a working prototype and work with it, then flaws become truly apparent: both in terms of usability and in terms of misunderstood requirements and workflow.

Iterative development makes sense in predictable processes as well. But it is essential in adaptive processes because an adaptive process needs to be able to deal with changes in required features. This leads to a style of planning where long term plans are very fluid, and the only stable plans are short term plans that are made for a single iteration. Iterative development gives you a firm foundation in each iteration that you can base your later plans around.

A key question for this is how long an iteration should be. Different people give different answers. XP suggests iterations of one or two weeks. SCRUM suggests a length of a month. Crystal may stretch further. The tendency, however, is to make each iteration as short as you can get away with. This provides more frequent feedback, so you know where you are more often.