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.

  • David Fairbrother

    Definitely agree with this approach. It means there are far fewer unkowns for the clients/stakeholders as the project progresses.

    This works for us for mid-size projects. The only thing we add to the process is a good ol’ static mock-up halfway through. Because the content-out, mobile-first and in-browser wireframe approach has been taken everyone has a good handle on layout and content hierarchy. The mock-up works just to summarise and clarify the aesthetic direction and “style” before continuing development.

  • I too agree with this approach. Very informative reading, thanks for sharing

  • GregRobson

    This sounds very similar to a “spike”. I only found out about spikes this year. It’s an agile story that is more research/investigation orientated.

    Spikes are still estimated like any other bug/issue/story (they are still “work to be done”), but their outcome isn’t immediately user-focused. It helps inform the estimation of the work to be done.

    E.g. The developers would like to A/B test two possible designs to make sure that the future work is estimated appropriately.

    Over time the occasional spikes will avoid estimates for the main work being inaccurate because designs were not well accepted.

    There’s more you can find out here: http://scaledagileframework.com/spikes/

  • Bob Salmon

    I agree – agile is excellent, but if used correctly. A good slogan to help with this is “you can’t incrementally walk to the moon”.

    If there are discrete functional areas, it makes sense to break them up into small chunks and iterate through them to minimise the risk of getting them wrong.

    However, where there are things that cut across functional areas, like the front-end things you mention above, but also back-end things like security, internationalisation / localisation etc, then you need to spend some thought and time up front agreeing the basics of your rocket before iterating over the parts of it.

  • James Richardson

    First post that I have read (on agile) that chimes with my conclusions of developing sites. In my case our developers are external to the company – so it means we work with specifications/requirement/principles/IA that get turned into lo-fi / hi-fi prototypes – this allows to test and work out if what we are creating is right for the various audiences/users etc without incurring development cost. I have never been quite able to see how to split a project down (certainly not a mid-large build) without knowing the overall requirements and page elements and how they can work together to create a holistic experience – money needs to be spent well – so we can’t afford to iterate (development wise) as we go.

  • Tom

    I agree with you in 100%. Very good article. BTW. Nice blog layout :)