A different way to build your prototype using agile

Prototyping website redesigns is a smart move on many levels. But I am not convinced traditional agile is always up to the task.

Like many I favour prototyping new websites rather than writing long specification documents. I believe in building an alpha that we test and iterate over time.

Building an alpha rather than writing specifications takes the guess work out of the design process. It allows you to test your ideas and ensure everybody has the same perception of what we are building.

But my approach to these prototypes differs from the norm. Many favour the agile method. Although I like to work in sprints I don’t take a traditional agile approach.

A traditional agile approach

One of the core principles of agile is that you work in a series of sprints. At the end of each sprint you deliver final code. Code that we can test for bugs and resiliency.

For example if you were designing a charity website one use case might be:

I am concerned about the education of girls in India and wish to donate to your charity so I can contribute to a child’s education.

This would lead an agile team to build a donation system in a sprint. By the end of the sprint there would be a working donation system that we can test both for performance and usability.

This makes a lot of sense from a software perspective but sucks from a user experience standpoint. A system might appear to be great from a usability standpoint when tested. But when you then add a new system (such as volunteer applications) you can undermine the usability of donations.

Working in this series of functional silos is tricky for designers and content people too. People who want to look at the entire site, not just parts in isolation.

That is why I favour a different approach.

Sprinting through fidelity

I don’t orientate each sprint around delivering a single use case to final deliverable standard. Instead each sprint looks at the site holistically and increases in the amount of fidelity.

Example sprint one

For example, our first sprint may consist of nothing more than installing a content management system. That and populating it with some basic pages and associated information architecture. Pages could have little more than what user questions or tasks that page will answer. For example, this page will allow users to make a donation and answer donation related questions.

Immediately that is enough to test with. It enables users to click around the site. This shows us whether they understand how the information architecture works.

Example sprint two

In the second sprint the designer might start adding some typographic styling. That and explore basic layout for mobile devices.

Meanwhile the content creators will be fleshing out pages across the site with some bullet points of what the page will cover.

This gives us something more to test with. Now we can see if we have addressed all the questions users might have. Maybe we missed something when we collected use cases.

Example sprint three

Next, the designer can start adding more complex layout. The content people can start writing initial copy. Copy that isn’t checked for grammar, typos or accuracy. The emphasis is just getting the copy in place.

Now we can test whether users can find the answers they want on a page. Is the copy appropriate? Do the design cues we have introduced work?

Example sprint four

Only after that can sprints start to address quality. The designer can start to refine the design with colour and styling. Copy gets edited and checked for accuracy, grammar and tone.

But we haven’t had to wait until the end of the alpha build to see the shape of the site. It has been visible from day one and has become more refined over time.

Not right for every situation

It is important to stress I am not suggesting this approach is right in every situation. This only works for alpha prototypes. Once you move into building the final site a traditional agile approach makes more sense. By this point you know the shape of the site from the alpha. The testing you do at this stage is about specific use cases, not holistically.

This approach is also more appropriate for content heavy websites rather than web applications. Most of the sites I work on are large and complex content heavy sites. They are sites whether navigation and signposting are key. We need to be able to solve those problems as early as possible.

Finally I don’t believe this approach suits evolving existing sites. It isn't right unless you are making big changes to information architecture, content and design. If you are evolving parts of a site then you will see quicker results with a use case centric agile stack.

In short this approach is best suited when you are trying to accommodate a large number of use cases into a site at the same time.

I am sure some of you are screaming that you should avoid doing this. I would agree. But the reality is many organisations have neglected their websites. Often starting from scratch is the only option.

Boagworks Boagworld