A conversation heard during a recent prototype usability testing session:
Facilitator: “Do you think you would like to use this app in your day-to-day work?”
User: “No, I don’t think I would. I would probably still print those sheets out.”
Wow.
On the surface this might sound like a disaster, but let me tell you why it’s actually a success:
By building a prototype and testing it with end users early on, we helped our client avoid committing to a multi-year, multi-million-dollar enterprise-level digital transformation project that was destined to fail – after just a month of discovery.
To their credit, our client was willing to listen to their employees and take the negative feedback seriously. The pain point – discovered during initial user research – was real, but the solution concept was flawed. It was time to go back to the drawing board to find a solution that met the needs of the business, management, and end users.
The moral of the story: Ideas are cheap. Finished products are not. If you’re going to fail, fail fast.
That’s why usability testing is a critical part of our design process at ConvergentIS. Not just user acceptance testing (by the time you get to UAT, it’s often too late), but early-on concept and prototype testing.
A whopping 70% of projects fail due to a lack of user acceptance. But what causes unsatisfied users?
Unhappy users might find that the new solution slows them down, decreases their job satisfaction, fails to address the underlying problems, or even introduces more issues. Somewhere along the line, the project team neglected to fully understand the users’ context and needs in relation to the solution. A failed project not only wastes resources but can also damage relationships and reputations.
If satisfied users are key to a successful project, how can you avoid these pitfalls and gain acceptance?
It’s simple: user involvement drives adoption. A little investment in user research and usability testing upfront pays dividends later.
A traditional software development approach goes something like this:
1. Have an idea
2. Build it over many months
3. Release it
4. Find out whether users like it or not
It’s a slow learning process, with a long lag time in between having the idea and getting feedback from users who can make or break it. And it’s risky – a lot of resources are spent on an untested idea that might not be successful.
For enterprise initiatives, there are often high stakes; you need to be confident in the direction before you devote significant time and money to it.
Design thinking allows us to shorten that feedback loop and validate or invalidate ideas in a short amount of time. Here’s how it works:
Because the design thinking approach is so lightweight – prototypes can be put together by a team of one or two in just a few days – it’s easy to iterate. A failure early on isn’t a disaster, it’s a natural part of the process – a low-risk opportunity to learn and improve.
The first step is to ideate: come up with as many ideas as possible. We complete brainstorming and sketching exercises that result in a wide variety of solutions. There are no bad ideas at this stage, and no pressure to produce anything pretty - the goal is to collect a large pool of rough concepts. Next we vote, using a simultaneous voting-dot process which allows every participant to feel heard, and avoids pressure to go in one direction or another.
Our prototypes are interactive and high-fidelity but only surface-level. We start by figuring out the surface – the user interface where users experience the product – then build the rest later.
Using the future state map that we created in the previous Discovery phase, we determine exactly what functionality is and isn’t needed in the prototype in order to answer the big questions. This process provides maximum impact with minimal effort. With a little explanation upfront, users can understand and overlook any rough edges while still giving useful feedback on the overall flow and design of the app. Unlike a completed software product, if the prototype fails the usability test, it’s no big deal to make major changes or even start over.
We have a tried-and-true method for usability testing at ConvergentIS that is guaranteed to generate focused, actionable feedback. Like all our design services, it can be done remotely or in person:
This method generates more thoughtful responses than the traditional approach of demoing a prototype and asking for open-ended feedback. Our usability testing is designed to get high-quality feedback by:
Allowing the app to stand on its own – in a real-life scenario, the developer or designer wouldn’t be standing over users’ shoulders, helping them through it.
Giving users hands-on experience, as well as time and space to think. Users are encouraged to think aloud and are free to draw their own conclusions.
Following the same procedure every time, allows us to compare results between users and iterations and to draw reliable conclusions.
Usability testing helps us gauge end users’ initial reactions to a proposed solution and therefore is an early indicator of project success. You may be surprised by what comes out of testing when your users speak candidly – there’s no more compelling evidence of future success or failure.
After a couple of rounds of positive usability tests, you can be confident in committing to your direction and starting development. We haven’t cracked time travel (yet), but we can glimpse into the future!
Software projects often fail at the last moment due to a lack of user acceptance. So, bring your users on board early – you’re in this together.
Design thinking offers a user-focused way to weed out bad ideas and polish up good ideas. Ideating, prototyping, and validating allow you to get accurate user feedback even before committing to execution, which minimizes risk and opportunity cost.
Sometimes the projects you don’t do are just as important as the projects you do. Let us help you discover, design, and deliver your best ideas.
This post on the discovery phase is the fourth in our Design Thinking in Practice series. Read the third here. Read the last here.