(A follow-up to Part I: Why Agile?)

Agile Philosophy

The guiding principles of any Agile methodology are to focus on a small sprint’s worth of work at a time, to engage team members early, and to communicate frequently. In practical terms, this means producing artifacts rapidly so that feedback can be collected, details can be refined, and schedules can be adjusted as needed.

The process of artifact refinement occurs via team planning sessions, with the goal being to produce ever more tightly scoped documents that contain “just enough” detail. These frequent collaboration exercises seek to avoid the common pitfall of having individual team members over-engineer complex problems in isolation. As with any specification process, an Agile team must iterate on artifact refinement until a mutually agreed upon point of clarity is reached. The major benefit of Agile, however, is that by engaging the whole team early during the refinement process, the overall design literacy is increased, and decision points can typically be reached more quickly.

Agile Development

In Agile software development we use User Stories to capture the “who”, “what”, and “why” of a given feature. The “how” is not fleshed out until a given User Story has gone through several iterations of decomposition and prioritization by the team. This approach is designed to save time during a project’s planning stages by keeping the team members focused on users’ needs and forcing them to justify and rank new features in terms of business value. Only when a User Story reaches maturity should tasks be created and packaged for development.

Agile UX

This Agile software development process is facilitated quite well by several popular software solutions ( as I mentioned in Part I, we use Rally ), but when designing end-user software there is still a big piece of the puzzle missing: In addition to capturing a hierarchy of user stories, tasks, and acceptance criteria, we also need a way to construct the architecture and interaction models that will define the user’s experience (UX), and in turn much of the actual implementation.

Using a tool like ProtoShare, we can apply the same Agile principles that we apply to our development process to a parallel UX specification process. This “Agile UX” process should aim for providing project stakeholders with models that find the right balance between scope, details, and fidelity. Additionally, just as with User Stories in Agile software development, an emphasis should be placed on rapid refinement, feedback, and collaboration.

In its early stages a UX prototype should serve as a vehicle for collaboration. As feedback is collected and ideas are evolved, specific interactions should begin to take shape. Once a prototype reaches maturity there should be a clear confirmation of the user stories it encompasses. When it has been approved by the team, the structure and interactions modeled within it will serve as the specification from which Agile development tasks can be generated.

In Practice

Our team at Site9 has found that ProtoShare works very effectively in this scenario. Using the built-in visual discussion tools allows us to quickly evolve an idea with the entire team engaged. Using states, we can model interactions in a lightweight fashion and link them to specific discussion topics for further refinement. The ability to store several distinct Design variations for a single “location” within an interface architecture provides us with an easy way to experiment and evolve ideas, without any fear of losing decisions made along the way.

Once we have evolved a prototype to a point where the entire team is satisfied, we can then link it back to a User Story in our Agile management system. We can create tasks to implement specific UI elements and we can even create acceptance tests that reference specific interaction states within an individual wireframe. This is easy to do because ProtoShare’s review URLs support full bookmarking and are state specific. This means that you can copy the URL of any page, design, annotation or discussion topic in review and link directly to it from within any application that supports hyperlinks.

Guidelines

Having these two agile processes running simultaneously presents its own management challenges, so it is good to have some guidelines going in. First off, it is important that everyone on your team understands that UX design is an explicit part of your overall development process, and a pre-requisite for most implementations. It is also important to realize that a key aspect of Agile is that refinement and iteration can occur at any time, as needed, and will require complete team participation to succeed. Being flexible and adjusting quickly is standard protocol.

While there are no rules that dictate when you should do things, we have found it helpful to have some overlap between our UX and development sprints. This ensures that our engineers always have something actionable in their task pipeline, and our UX team is not going too far downfield without understanding the engineering implications of a given design.

Additional Benefits

We have also found that engaging in collaborative prototyping sessions as a precursor to creating development artifacts can help to clarify, and even discover, additional user needs. Engaging in these brainstorming style prototyping sessions can often result in fewer/quicker development iterations and an accelerated consensus among the team.

Lastly, we often use ProtoShare’s “Live View” capability to collaboratively discuss a production website or application. Whether we are refactoring a legacy implementation, or providing quick post-sprint feedback, it has proven highly valuable to have a single place where we can discuss and catalog the evolution of an implementation over time. Team members can discuss problems with an implementation and experiment with new ideas side-by-side, without losing the context of the current production UX.