WEBVTT

00:00:00.000 --> 00:00:32.920
This is a very typical project lifecycle in high-level terms.
Generally start off with *requirements* – finding out what's needed,
and we go off and talk to stakeholders.
And one of the problems we have with *user requirements*, in particular,
is that often analysts and requirements researchers in the IT world
tend to go off and want to ask *users* what they want.

00:00:32.920 --> 00:01:02.227
They don't really understand that users don't quite know what they want,
that you actually need to do user research, and that is
one of the biggest issues that we face in user experience:
is the lack of understanding of user research and the whole field of user experience.
From requirements, we might expect to be doing surveys
to find out – particularly if we have an existing offering of some kind –
we might find out what's good about it, what's not so good about it,

00:01:02.227 --> 00:01:31.348
what people would like to do with it.
And surveys might be helpful in those particular areas.
Now, bear in mind that generally when we're talking about surveys, we already need to have
some idea of the questions and the kinds of answers people are going to give us.
It is really a very bad plan to launch a large survey
without doing some early research on that,
doing some qualitative research on how people think about these questions and these topics

00:01:31.348 --> 00:02:00.076
and trying to understand it a little bit better before we launch a major  initiative in terms of survey research.
We can also use surveys in *analysis and design*
perhaps to ask people which kinds of things might work better for their particular needs and behaviors.
We also can start to employ *early-design testing*, even in the analysis and design phase
so that we've got perhaps some wireframes that we're thinking about on the *design* side,

00:02:00.076 --> 00:02:30.638
and we can start to *test* them – start to try to find out:
"Will people understand this? Will they be able to perform the most important tasks from perspective?"
I have been involved in user testing
of new product ideas where users had *no idea* what the service being offered was about
because it was just presented *so confusingly*;
there was no clear message; there was no clear understanding of the concepts behind the message
because it wasn't very clear to start with, and so on.

00:02:30.638 --> 00:03:00.395
So, early-design testing really has an important role to play there.
*Implementation* and *testing* – that's when we can start doing a lot more
in terms of evaluating what's going on with our products.
There we would employ *usability evaluations*.
And the things that I've called "early-design testing", by the way,
can be done later on too. It's just they don't really involve the finished product.
So, they're perhaps not quite as relevant.
But if we've got questions about how the navigation might be changed,

00:03:00.395 --> 00:03:32.059
then we might fall back to the tree testing
where we're just showing people the navigation hierarchy rather than the whole site
and asking them to perform tasks and
just tweak the navigation as required to improve that.
And one of my big complaints with our whole industry
– still, after all these decades! –
is that we do tend only to be allowed to do usability evaluations,
and we do tend to wait until implementation has taken place

00:03:32.059 --> 00:04:02.842
and the product is being tested before we start to try to involve real users,
which really is far too late in the whole process.
If you want to be able to be confident in the
concepts and the terminology that your interactive solution is providing to your users and customers,
then that needs to start way back at the beginning of the project cycle.
And then, finally, once we've got live solutions available,

00:04:02.842 --> 00:04:30.158
we can use *analytics* for websites and apps
and we can also use A/B and multivariate testing
to make sure that our designs are optimal.
If we find problems, we might set up an A/B experiment
to see whether this particular alternative would be a better solution
or we could go down the multivariate route
where we provide permutations of a *number* of different design elements
on a particular page and see which  of those elements proved to be the most effective.

00:04:30.158 --> 00:05:00.035
The fact that if you're doing project development,  software development in an iterative environment
– like agile, for example – then you might be doing  a little bit of this in every single iteration;
so, there might be a little bit of work on the  requirements at the front
and there might be a little bit of design and analysis.
Having said that, there is usually some upfront requirements
and analysis and design that has to go on
so that you know what *shape* your project is

00:05:00.035 --> 00:05:30.556
– what *shape and size* I think is perhaps a better or more complete description –
because in order for you to be able to even guess
at how long this is going to take you, you need to have *scoped* it.
And to scope it means to set the boundaries,  and to set the boundaries means to understand the requirements
and to understand what kind of solutions would be acceptable;
so, there will be some of this done always up front.
Anybody who sets on a major project
*without* doing upfront requirements analysis and design of some sort

00:05:30.556 --> 00:05:34.075
is – I'm afraid – probably asking for trouble.