WEBVTT 00:00:07.691 --> 00:00:12.393 This is a very typical project lifecycle in high-level terms. 00:00:12.393 --> 00:00:16.088 Generally start off with *requirements* – finding out what's needed, 00:00:16.088 --> 00:00:19.254 and we go off and talk to stakeholders. 00:00:19.254 --> 00:00:22.897 And one of the problems we have with *user requirements*, in particular, 00:00:22.897 --> 00:00:28.703 is that often analysts and requirements researchers in the IT world 00:00:28.703 --> 00:00:32.920 tend to go off and want to ask *users* what they want. 00:00:32.920 --> 00:00:36.411 They don't really understand that users don't quite know what they want, 00:00:36.411 --> 00:00:39.573 that you actually need to do user research, and that is 00:00:39.573 --> 00:00:44.251 one of the biggest issues that we face in user experience: 00:00:44.251 --> 00:00:49.043 is the lack of understanding of user research and the whole field of user experience. 00:00:49.043 --> 00:00:53.802 From requirements, we might expect to be doing surveys 00:00:53.802 --> 00:00:57.797 to find out – particularly if we have an existing offering of some kind – 00:00:57.797 --> 00:01:02.227 we might find out what's good about it, what's not so good about it, 00:01:02.227 --> 00:01:04.811 what people would like to do with it. 00:01:04.811 --> 00:01:08.745 And surveys might be helpful in those particular areas. 00:01:08.745 --> 00:01:13.254 Now, bear in mind that generally when we're talking about surveys, we already need to have 00:01:13.254 --> 00:01:18.688 some idea of the questions and the kinds of answers people are going to give us. 00:01:18.688 --> 00:01:23.304 It is really a very bad plan to launch a large survey 00:01:23.304 --> 00:01:26.071 without doing some early research on that, 00:01:26.071 --> 00:01:31.348 doing some qualitative research on how people think about these questions and these topics 00:01:31.348 --> 00:01:38.520 and trying to understand it a little bit better before we launch a major  initiative in terms of survey research. 00:01:38.520 --> 00:01:41.931 We can also use surveys in *analysis and design* 00:01:41.931 --> 00:01:49.082 perhaps to ask people which kinds of things might work better for their particular needs and behaviors. 00:01:49.082 --> 00:01:55.783 We also can start to employ *early-design testing*, even in the analysis and design phase 00:01:55.783 --> 00:02:00.076 so that we've got perhaps some wireframes that we're thinking about on the *design* side, 00:02:00.076 --> 00:02:03.385 and we can start to *test* them – start to try to find out: 00:02:03.385 --> 00:02:10.289 "Will people understand this? Will they be able to perform the most important tasks from perspective?" 00:02:10.289 --> 00:02:13.727 I have been involved in user testing 00:02:13.727 --> 00:02:19.758 of new product ideas where users had *no idea* what the service being offered was about 00:02:19.758 --> 00:02:23.070 because it was just presented *so confusingly*; 00:02:23.070 --> 00:02:28.060 there was no clear message; there was no clear understanding of the concepts behind the message 00:02:28.060 --> 00:02:30.638 because it wasn't very clear to start with, and so on. 00:02:30.638 --> 00:02:34.247 So, early-design testing really has an important role to play there. 00:02:34.247 --> 00:02:38.562 *Implementation* and *testing* – that's when we can start doing a lot more 00:02:38.562 --> 00:02:42.883 in terms of evaluating what's going on with our products. 00:02:42.883 --> 00:02:46.287 There we would employ *usability evaluations*. 00:02:46.287 --> 00:02:49.426 And the things that I've called "early-design testing", by the way, 00:02:49.426 --> 00:02:53.819 can be done later on too. It's just they don't really involve the finished product. 00:02:53.819 --> 00:02:56.250 So, they're perhaps not quite as relevant. 00:02:56.250 --> 00:03:00.395 But if we've got questions about how the navigation might be changed, 00:03:00.395 --> 00:03:04.378 then we might fall back to the tree testing 00:03:04.378 --> 00:03:08.593 where we're just showing people the navigation hierarchy rather than the whole site 00:03:08.593 --> 00:03:11.901 and asking them to perform tasks and 00:03:12.080 --> 00:03:15.387 just tweak the navigation as required to improve that. 00:03:15.387 --> 00:03:19.936 And one of my big complaints with our whole industry 00:03:19.936 --> 00:03:22.715 – still, after all these decades! – 00:03:22.715 --> 00:03:27.258 is that we do tend only to be allowed to do usability evaluations, 00:03:27.258 --> 00:03:32.059 and we do tend to wait until implementation has taken place 00:03:32.059 --> 00:03:37.097 and the product is being tested before we start to try to involve real users, 00:03:37.097 --> 00:03:40.703 which really is far too late in the whole process. 00:03:40.703 --> 00:03:45.958 If you want to be able to be confident in the 00:03:45.958 --> 00:03:53.688 concepts and the terminology that your interactive solution is providing to your users and customers, 00:03:53.688 --> 00:03:58.477 then that needs to start way back at the beginning of the project cycle. 00:03:58.477 --> 00:04:02.842 And then, finally, once we've got live solutions available, 00:04:02.842 --> 00:04:06.212 we can use *analytics* for websites and apps 00:04:06.212 --> 00:04:09.010 and we can also use A/B and multivariate testing 00:04:09.010 --> 00:04:11.867 to make sure that our designs are optimal. 00:04:11.867 --> 00:04:15.410 If we find problems, we might set up an A/B experiment 00:04:15.410 --> 00:04:19.524 to see whether this particular alternative would be a better solution 00:04:19.524 --> 00:04:22.325 or we could go down the multivariate route 00:04:22.325 --> 00:04:25.863 where we provide permutations of a *number* of different design elements 00:04:25.863 --> 00:04:30.158 on a particular page and see which  of those elements proved to be the most effective. 00:04:32.560 --> 00:04:38.560 The fact that if you're doing project development,  software development in an iterative environment 00:04:38.560 --> 00:04:44.240 – like agile, for example – then you might be doing  a little bit of this in every single iteration; 00:04:44.240 --> 00:04:47.311 so, there might be a little bit of work on the  requirements at the front 00:04:47.311 --> 00:04:50.363 and there might be a little bit of design and analysis. 00:04:50.363 --> 00:04:54.408 Having said that, there is usually some upfront requirements 00:04:54.408 --> 00:04:57.394 and analysis and design that has to go on 00:04:57.394 --> 00:05:00.035 so that you know what *shape* your project is 00:05:00.035 --> 00:05:03.826 – what *shape and size* I think is perhaps a better or more complete description – 00:05:03.826 --> 00:05:07.300 because in order for you to be able to even guess 00:05:07.300 --> 00:05:10.438 at how long this is going to take you, you need to have *scoped* it. 00:05:10.438 --> 00:05:15.750 And to scope it means to set the boundaries,  and to set the boundaries means to understand the requirements 00:05:15.750 --> 00:05:18.428 and to understand what kind of solutions would be acceptable; 00:05:18.428 --> 00:05:22.318 so, there will be some of this done always up front. 00:05:22.318 --> 00:05:25.699 Anybody who sets on a major project 00:05:25.699 --> 00:05:30.556 *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.