How putting users first leads to better product development - Part 4: Build, test, iterate

Image source: Melissa Ramos

Rather than continue to plough through your sprints until all the stories are complete and your product is built, you need to test what you’ve got, early. The diagram above neatly describes the process that you should be using.

Imagine you don’t test, and you work right through to launch, you ship your product to real customers, and suddenly your sales start decreasing, or your support team are inundated with support calls, and you don’t know which part of the new product has caused this. Without warning, you’re faced with high costs to fix or redevelop and your organisation’s reputation and pocket have been damaged.

When Virgin America used a test and iterate UX process they reported a 14% increase in conversion and a 20% decrease in support calls. Hubspot, who receive around 10 million visitors per month to their website, doubled their conversion rate by using an iterative UX process.

By testing batches of features and functions (stories) early, you get the chance to make any amends or iterations before it’s too late. Quite often you’ll realise you can refine something, cutting out reams of extra work, and hence save time and resources.

Why test early?

To see if what you’ve developed meets the requirements and understand how good your product actually is (you’re designing in the dark until real users see it!)

• To get insights into user behaviour that you can feed back into the design

• To measure user performance – are your designs measurably better?

• To prioritise features for future development

This isn’t just about seeing if something is broken, you’re measuring it against your initial objectives and evaluating whether it answers the stories, and hence customer needs. You’re gathering excellent ideas and feedback for future features, if not immediate refinement. And – importantly, you’re giving yourself the opportunity to refine the product scope and functionality, ensuring you only develop and deploy what is absolutely necessary.

How to test early and factor it into the work process

You should be factoring some element of testing into each sprint, or at least group of sprints.

The idea of a sprint is that you have a potentially shippable product at the end of the sprint – meaning that it could go live. You could test during the sprint, as stories are completed. You could test towards the end of the sprint, with a set of stories. Or, if you require a larger amount of functionality to be complete in order to make it testable, get a few sprints under your belt.

The type of testing you do depends on how you are building your product. Are you producing a low fidelity wireframe prototype or a designed and coded prototype that is essentially the real thing?

The first step is to test internally, which you should be doing as part of your sprint anyway. This is more of a ‘quality assurance’ process in that the team members and product owner will hold a review to check that it meets the requirements.

The next, and most crucial test is to put it out to potential real users – your customers or those very similar to your customer. They’re far more objective than you, and there is no better way to learn about usability than straight from the horse’s’ mouth.

I can’t reiterate enough the value of testing – you are not your user and can never possibly imagine some of the ways in which they will use your product. It’s fascinating what you can find out and it can revolutionise the end product.

“This is amazing but so frustrating to see. I was shouting at the screen: “Noooo, click there!” I haven’t finished watching it yet but the 10 minutes I have seen have opened my eyes.”
A client of ours, after watching some of their product’s test results.

There are two good methods you can employ for testing

• Test in person with specific customers. A format where you get in a room with your customer and watch them use your product.

• Test remotely with specific customers or a similar demographic. Here you would use third party software such as TryMyUI. People use your product, and their experience and feedback is recorded and sent back to you.

For both options you need to write a scenario and a few tasks to ensure the person can put themselves in the correct mindset for using your product, and that they have some actions and goals that will ensure they test the functionality properly.

We won’t go into the details of scenario and task-writing here, that’s another blog! What you write depends on your product – for low fidelity prototypes, you may have to lead the user more, and expect more general usability feedback. For hi-fidelity prototypes or final coded prototypes, leave your tasks far more open, because the experience is more real and hence better left open to the users’ interpretation.

Once you have compiled your feedback, look for patterns and anything clear that stands out, good or bad. Ultimately you want to focus on the ‘bad’ because now is your opportunity to improve something that isn’t quite right. Evaluate what needs to be done – looking at genuine usability issues versus subjective preference, and build the iteration work into the next sprint, or the current sprint if possible.

Where does hi-fidelity prototyping come into this?

Hi-fidelity prototyping is something we do with most of our clients. Essentially what it involves is combining the prototyping and design stage, to design directly in Axure.

It brings a huge benefit to the project because it simplifies the process and makes it far leaner in terms of time, cost and resource.

Hi-fidelity prototyping was perfect when working with our client HouseMark - they had a strong brand and clear set of design guidelines that we could use, and, most critically, we have a strong UX design capability. We have the experience and expertise to combine both the UX and design, meaning that one person from our team could create hi-fidelity designs that implement both the visual layer and strategic user experience.

By doing it this way we were able to:

• Enable HouseMark to show customers the prototype as we went, promoting new features and testing to get valuable feedback as we designed

• Iterate the design, interface and user experience in parallel, delivering high fidelity, functional designs quickly

• Give the development team a working model that looked like the real thing, which cut down the need for technical specs and long-winded design briefs

Hi-fidelity prototyping helped us to shortcut the project process and get the product to market quicker. We saved time and resources by removing a lengthy design stage. It made testing easier because it looked and worked like the ‘real thing’ and it gave HouseMark a fantastic marketing opportunity because it was good enough to be shared early with their customers.