[MUSIC] Tasks are goals that users set out to accomplish when they're using a system. Analyzing the usability of a system requires a set of tasks because usability of a system as a whole is a concept that's too abstract to be understood. Instead, we want to come up with specific goals that users what to accomplish and then analyse the usability of those goals or tasks. This gives us an insight into what the system is good at and where it needs work. Tasks should be specific things that an average user would set out to do. And some of them will be more important than others. It's important to consider that ranking when you're putting tasks together. So you should have a set of. Most important task, and less important tasks, to give you a set of what can be done in the system. Before we get into any of the specifics of creating a list of tasks, let's look at the Google website as an example. What are the tasks that one might accomplish on the Google site? First, they might conduct a web search. And the site is set up well for that, because the main thing you see on the homepage is this search box that searches the web. What are other things the user might want to do on this site? Well they might be interested in doing a different kind of search, and so if we scan the site. We clearly see an image search up at the time and another box here. Which gives us access to different Google services. We can also log in, and not only is the log in clearly available. It's set up in a way that it's not distracting to people who just want to search because they're clearly drawn to the box in the middle. But also the log in is placed up in the upper right hand corner which is a common place for log in spaces to be. Thus, it's relying on things users already know about a website. We may also want to look at information about advertising or terms of service. And that can, again, easily be found here at the bottom of the screen. If someone's looking for it, there's not a lot of clutter on the page, and so it's easy to find. But it's unobtrusive, so it's not in the way of something other users would be doing. Settings are also located on the bottom which give users access to other features. Like doing an advanced search, looking at their history or getting help. All in all the usability of the website is very high because the most important tasks are the most obvious thing on the page. The secondary tasks are placed in obvious places based on what users are used to in other sites. And if we made a full list of tasks, it's likely that we would find a way to accomplish all of those. Quite easily on the main page, even though nothing is in the way of users accomplishing a basic task like a search. Tasks themselves are goals that users set out to accomplish in a system. And it's important to put your head in the mind of the user, and think about the kinds of things they want to do. As you're creating a list of tasks for your system. Here are some example tasks. One is log in to Facebook. This is something that a user will intentionally set out to do. They'll go to the Facebook website with the intention of logging in. There's a lot of things that they might do after that, but logging in is a small and concrete task that they might set out to accomplish. Another example is to check your credit card statement and this is a higher level task in one sense in that it has many sub parts. The user will need to go to the credit card website, log in and potentially click on a few links in order to get to the statement itself. So even though there are some parts of this task, we want to think about what the user's goal is. And though the user may understand those subparts their ultimate goal is to check the statement and so that becomes our task. In a further lecture we'll look at how we want to break tasks down into subparts. And how that relates to users, abilities, and the way they think about systems. But for now, understanding and identifying this general goal of checking the statement is the right level to be at. A final example is to read the headlines. A user can pick any news website to do this and they may have to do some subtasks. Some websites may require them to log in, others may require them to click some links but ultimately the goal of reading the headlines. Is something the user will set out to do. And they may figure out the steps they need to do in order to accomplish that. When we measure the usability of a particular task, we rely on the five factors that we discussed in a previous lecture. We look at measuring speed, efficiency, learnability, memorability, and user preference. We discussed how to measure these in the previous lecture but let's revisit one example. Recall our task of authenticating in to use the iPhone and that can be done either with the thumb print authentication or by entering the four digit code. Those are two methods of accomplishing the same task. And so we can analyze the usability of those methods by applying the five factors that we previously discussed to how to use your carries out. Each method to authenticate. So recall that we start off by holding the phone. It takes about one second to authenticate with the thumb print, and it took about four seconds to authenticate using the four-second code entry. Since there were no mistakes made, efficiency is equivalent between the two system, but speed is faster with the thumb print. Thus, there's higher usability for this task. There are common errors that beginners often make when they're creating a list of tasks for their website or their system. One is that their tasks can be too leading or too descriptive. For example, you might create a task that says something like, click on the username box at the upper right of the screen and enter your username. Then click the password box underneath it and enter your password and click submit. Essentially, this is a list of instructions for the user, but the user doesn't set out with the goal in mind of doing each of these things. They set out with a higher-level goal of logging in, and they may come up with this set of steps along the way. If you're creating a system, since you won't be giving users this set of instructions, as they use it, you don't want that to be your task. Think about the goal the user has in mind. Which is simply logging in, and that should be the task, it shouldn't have the extra detail. Another common error, is asking specific questions, for example, what's the third headline on cnn.com. While a user certainly might read the third headline on cnn.com. They don't generally go to the website specifically looking for what the third headline is. Thus, this is far too specific. Users may go to read the headlines, and in fact, they might even go to read the first headline only. But the third is a very specific and unusual thing that doesn't have any meaning on its own. And when people are starting off, they sometimes come up with really specific tasks like this. But this isn't a reasonable goal that a user would have, and so we don't want to stick to that as a task. And one final common error is that people who create systems often put in information. That isn't something that users are necessarily going to seek out. But they'll create tasks to point users to that information. For example, you may ask as a task, what are the names of the members of the website security team. But in most instances, people aren't visiting websites or using systems to find out the members of a security team. They're going there to check their balance, if it's a website for a bank. To read the headlines if it's a, news website, or to see what their friends have been up to if it's social media. While there may be an occasional user who wants to know the members of the security team, it's a very rare task. And often is something that the developers put in because they care about it, not because the user's care about it. So be careful in creating task that you're not simply directing people to information that you want them to look at. It should be something that users intentionally want to see. One thing that we can do is to compare tasks between systems. So we have the same tasks for a user to accomplish but a couple ways of doing it. Here, let's look in an example tasks of giving people right access to a file. In this case, we're talking about people broadly, so we want everyone have right access to a file. And we're going to look at two ways of doing this. One on the command line and one in a graphical user interface. The command line is quite fast if you know what you're doing. But if you don't know units commands you have to look them up, scroll through the documentation and hope to find what you're looking for. It's not an easy process and not an easy way to learn. So this is a system that's very good for experts. But if you're not an expert reading and learning is extremely difficult. And it will take you quite a long time to figure out how to do the task. Thus, the use ability is high for experts but low for beginners. On the other hand the graphical user interface is extremely simple. You can click on an option, select read access, and you're done. What if we change that task just slightly? To have us give everyone execute permission instead of read permission. This task is similarly reasonable and it's something that you would do just as often. But we actually see big differences. In which system is more usable and more effective for this variant of the task. In this case the command line is equally complicated. There's the same command issue with a slight tweak and it achieves the goal of adding execute access. However, the command line doesn't have an option to add Execute Access. So even though it's simple, it's not able to achieve the task we care about here. So to wrap up, tasks are goals that users have when interacting with the system. To evaluate the usability of a system, we can create a representative list of tasks. And evaluate the usability of those tasks according to the factors that we discussed previously.
