Quickly testing a hypothesis with a prototype

How do you help a large organisation make decisions faster?

Sage is really big. Clearleft is not. For this project we wanted to take advantage of both of these facts.

A large organisation like Sage has a lot of institutional knowledge. They know their business and they know their customers. There’s simply no way that Clearleft could possibly gain the same level of expertise in a short amount of time. That’s okay. We made sure to turn to Sage whenever we had questions about how their customers get things done.

On the other hand, it’s hard for an in-house team to move quickly. The larger the organisation, the slower the decision-making process. That’s where Clearleft comes in. We can design, build, and test at a rapid pace.

This project was a collaboration. By combining Sage’s knowledge with Clearleft’s speed we were able to tackle the central question: would customers be interested in having a single screen that gathered information from different Sage products into one place?

How do you know you’re testing at the right level of fidelity?

At Clearleft, we like building things that make life better for users. But on this project, we had to constantly remind ourselves that the main purpose wasn’t to build something in order to ship it; the main purpose was to decide whether there was an interest in this product even existing.

But in order to answer that question, we knew we had to build something. Just asking people whether they could imagine using a hypothetical service isn’t going to provide accurate results. To be confident about your product roadmap, you need to test with a prototype. It doesn’t have to be perfect, it just has to exist.

Three weeks in, I thought "how the hell are we going to do this?" But you've absolutely nailed the prototype!

Working on the prototype brought up the eternal question: where do you stop? On the one hand, you want the prototype to feel real and interactive so that the testing is realistic. But on the other hand, if you build in every possible eventuality, you might as well build the finished product.

In the end, we built something that was shallow, but believable. A prototype doesn’t need to be production-ready, but it needs to give the impression that it’s production-ready. This prototype was built with smoke and mirrors, but the smoke and mirrors were high-fidelity.

How do you demonstrate that this process can be repeated?

If Clearleft had to recruit test subjects for this prototype, we would have really struggled to find the right people. But fortunately, we didn’t have to. Sage knows their customers. They put together a perfect roster of representative users.

Because the prototype was built in code rather than simply being a mock-up, it was responsive, performant, and accessible. This meant that customers could test it using their own equipment. That added to the realism of the test, as well as ensuring that no one was excluded.

In the end, the testing showed that there was indeed an appetite for an overview screen. Sage can now move forward with a decent level of confidence. And if they need more confidence, they can iterate on the prototype and repeat the testing process. For that, they don’t need Clearleft any more. We’re very happy about that!

For this project, the combined team of Clearleft and Sage practitioners were acting almost like a research and development wing. For another project, Sage can repeat the process but this time without Clearleft practitioners.

The short-term goal of this project was validating a hypothesis for Sage’s product roadmap. But the longer-term effect is that Sage can apply the fast-paced design cycle they’ve picked up from Clearleft.