The ability to test and experiment in design, it is everything.
The only way to really dig down and resolve
a design, is to build a prototype and put it to its merits.
Yeah. So when we're testing a product,
we want to actually approach it in a couple of different ways.
The first is finding the things that we want to test on the product itself.
The biggest thing that I see that people make a mistake
of early on and doing prototyping and testing,
is they don't enter into it with a research script.
A thing that it really just shows like,
hey, here's what I'm trying to get out of this research.
Defining that ahead of time will make sure that you don't get off topic.
In addition to that though, you want to make sure that
you're targeting the right demographic.
If you're targeting just some random subset of users without
identifying the ones that are actually having the problem that you're trying to address,
then you're not going to get the feedback that you really need.
So working with those two things hand-in-hand,
is critical to making sure that your feedback is
correct and it really is something that's going to be valuable for you moving forward.
The primary step for testing a product, is number one,
understanding which metrics are you measuring in the first place.
So, the metrics that you measure can really
impact the way that you design something and it's really
important that we work closely with our PMs to understand that
we're measuring the right metric to get to the right solution.
Set number two, once we're confident that we're looking at the right metric,
that's when we start to think about, "Well,
how can we move that metric in a way that's good for us?"
and that will inform the design decisions that we make,
and it kind of acts as a goal for us to understand are we succeeding in the project.
One of the things that we're really keen on improving is,
how quick is it for a help seeker that's come to the portal to go
from landing on the page to raising a request and getting in contact with the people,
with the agents on the website.
So, that informs our design to
think how can we make it quicker for them to search through stuff?
How can we better surface our request-type?
How can we make it easier for them to find the right request-types,
so that they know that they're asking for help from the right person?
And all of these questions that we ask are based around that metric of
how fast can we make it for a user to go from landing to raising a request.
For me, testing is really about adopting this Agile culture.
It's about a constant improvement process.
If I'm looking at an e-commerce website and the client comes
to us with a problem that the page isn't performing how they want it to,
we would start by looking at how, what it's doing,
what are the customers doing, where they're going,
what are they clicking on, are they
starting to buy a product from where are they falling out?
We'll develop a range of different things that we think might
help change that then we go about executing each of them.
And once we launch it, we then monitor how that actually performs,
and if it doesn't perform what we thought it was
going to then we would go back to the drawing board and start again.
It's it's absolutely imperative that designers are prepared to
break their products and to push them as hard as they can,
to put them in front of as many people as they can,
to put them in as many unlikely scenarios
as they can and really try to iron-out any potential issues.