[MUSIC] Hello. In the previous part of this lecture, we briefly discussed the informal process of deriving usability goals. In this part, I would like to illustrate this process with the following example. I will take the same old parking app which I worked on together with my former student Sophie. We discussed some features of the app's context of use in the first week. Meet Ann, an assistant to the chief accountant in a printing office. Ann is a primary persona of this app. Ann got her driving license a year ago, but she drives quite well because she does it every day. Ann gets to her office which is outside the center of Moscow by car. But sometimes, Ann meets her friends at the centre. It usually happens at night, after work. So she gets there by her car too, and considers it safe. She is very careful regarding traffic regulations and parks only where it is allowed, and always pays for parking being in the city centre. The fact is that it doesn't happen often, about once in two weeks. Ann considers the price of parking as high, and she tries to save money by parking a bit away from her destination point, but within the parking area, with a lower price. That is why she always checks out prices of parking before the ride. She tops up her parking account right before parking with the amount needed for the current parking session and not a penny more. So here is her typical scenario of meeting friends at the centre of Moscow. Before going to her office, Ann checks out prices of the parking near the place where she and her friends agreed to meet. She often uses navigation app to get directions to a particular parking lot because she doesn't know the city well enough yet. Once she gets there, Ann tops up the parking account and starts a new parking session. I would like to discuss usability goals before we start in the parking session task. To do this, you need to imagine you are Ann performing these tasks. So she just parked her car not where she expected. There weren't free parking lots. Ann turned off her car's engine and got form in order to start a parking session. Note that Ann is meeting with friends, so she is not in a hurry, but she's afraid to choose the wrong place of parking in the app because fines for improper parking are too high for her. Besides, one of Ann's goals is to park carefully without breaking traffic regulations. So, we can formulate these aspects of the interaction in terms of number of mistakenly chosen places of parking, and our goal as designers is to lower the number down. The second usability measure is, in fact, the flip side of the same coin. It's crucial not only to lower down the number of errors, but also to make Ann feel confident about her choice. This measure is backed by additional data, the inefficiency that Sophie discovered during her research. As you remember, one of the reasons why the users of the original Moscow Parking App used the map to choose a particular parking lot is that they don't trust the automatic identification of the number of a parking area. The third usability measure is not equal to the second. Imagining being Ann, it becomes clear that the whole situation is stressful for her. She has been worried from the moment she parked. Ann knows that the control of violation of rules of paid parking is carried out by special cars which move along certain routes, and by means of video camera, capture numbers of parked cars. Then, they automatically check payments for them. What if one of these special car drives by and she'll get a fine? Our goal is to minimize this stress. I'd like to bring your attention to the wording of usability measures. Ideally, your goal is to make them free from specific design solutions, like in this example. The measure labeled as don't implies that there should be an automatic identification of the number of a parking area in the final design. It's not good because it may distract you when you design an interaction. You may focus on these particular solution and won't be able to suggest a better one. It's not always possible to get rid of all design solutions reflected in usability measures, but you should try to do that. All right. What about other usage contexts? Is this usability goal available for all of them? No, it isn't. And here is another example. I hope you remember Max, your secondary persona on the same app that we discussed in the first week. Max differs from Ann in many ways. For example, he uses his car to get to meetings with clients. He has an income that allows him to easily pay for parking every day. It's much more important for him to feel comfortable during the trips. Max prefers to park his car as close as possible to the entrance, which helps him to save time. As a result, the usability goal of the same task for Max is different. Despite the fact that Max worries about time more than money, the first two usability measures are the same. No one wants to lose money because of a mistake. Max pays won't make the mistake. But in opposite to Ann, he is almost always in a hurry. One of Max's goals is to be at the movies on time. That is why there is a third measure concerned with this performance. How do Ann and Max usability goals get along? If you have several usability goals related to one part of the user activity, the only way to make them work together is to set priorities. Assessing alternative solutions while designing, you need to decide which usability measure is more important. You can do this with [INAUDIBLE] of some quantitative characteristics of the usage context, like the sizes of user groups or frequencies these groups perform this activity. This work can be done in the of requirements from stakeholders. For example, a primary persona is more important than others, from a business perspective. And you may decide to give preferences to each usability goal. I'll show application of these usability goals later this week. My goal here Is to explain how to derive those. More rigorous processes like these two include the additional step of choosing one or several usability matrix for each usability measure. But since we're talking about the application of usability goals to solve the design direction instead of using the usability benchmark task, you don't need to spend time on this. If you're uninterested in the rigorous processes, you can find full references in your recommended readings for this week. The last thing I would like to mention, when you apply the informal process to different parts of the activity, you start noticing the similarities among usability goals. It's possible to come up with high level usability goals that cover huge chunks of the user activity by generalizing usability measures. For example, your measure errors in the choice of the place of parking can be generalized to just error related performance. I highly recommend that you use this bottom-up approach instead of the top-down one where you start from deriving high level goals because it will give you a more precise tool for choosing among alternative design solutions. Thank you. See you in the next lecture. [MUSIC]