 I'm going to have a presentation on user experience and first of all, there are two things involved in user experience. It's usability and user experience. And there may be tests basically on everything. So on hardware, software, on every kind of product that you have. And in contrary to the standard examples in literature, I have decided to use my unicorn as a demonstration object. So I'm going to explain how this basically works on the unicorn. And then we will have some more details on software and other stuff. Usability and user experience are very important if you want to create a very good product. So one only works with the other. And this is why we're going to talk about it. But first of all, a little bit about myself. So my name is Hevi. I'm attending Keras events since the 26C3. I study computer science and I have some certifications on user experience and scrum. So I know a little bit of the stuff I'm talking about. I also do some of these things at my work. So first of all, we've talked about the player. But now let's talk about the rule of this game. There is one basic rule which you have to follow when it comes to user experience. And this is there is no such thing as a layer 8 issue when it comes to user experience and usability. This is a really important rule. So whenever you find that the user is not doing what you expected him to do, it's not an issue of the user, but it's an issue of the product, software, or whatever you are doing. This is really important to understand because only if you really follow this rule, you will be able to create a good user experience. And here the unicorn is asking, well, does it mean it's all the fault of the unicorn? In this case, obviously it is. So usability. For a trivial UX, we have to answer six questions to win our game. And we will go through these questions one by one in order to win the game. So first of all, there is one important question. Who is your user? The more precise you are about your user, the better will be your product because you can develop the product exactly for the user which you have in mind. You can create specific user profiles and you can check against these profiles later on. So is your user a child? Is your user the parent? Or is it just somebody who doesn't like to be in pictures? Discretion is really important. So for this case, I will use the person who doesn't like to be in pictures. And now let's think a little bit about the user. Might this user be interested in? Do you have any ideas? If not, I will tell what I have in mind. So a few things which I thought about is, for example, a person which travels a lot is interested in various things, architecture, sites, flowers, food, whatever. And somebody who wants to share these impressions. So the next point if we know a little bit about our user is, when is our user going to use the product? So in our case, there could be several things. For example, emotion capturing, a travel diary, sleeping aid could also be a possible use case, a debug unicorn or a travel companion. So there are several situations in which you can use a product. The more you know about those situations, the better you can adjust your product to these situations. Because how do you want to know what a user is going to do with a product if you don't know when he's going to use it? So next thing, we know the user, we know when he's going to use it. Now let's talk about some of the requirements. Do you have any idea what this user might have as a requirement? Anything? Anyone? Any idea? I've noted some of these things. So for example, the user does not want to carry the unicorn all the time while it is on the road trip. Maybe it needs a password because it travels a lot of cities or countries. It should be visible on a picture. So if you want to take a picture of a unicorn and your impressions during your road trip, it should be visible. In that case, our user also would like to collect events souvenirs and wants to show them to other people. And one important thing, if the unicorn is supposed to guide you for a long time or be with you for a long time, it should be washable. And you might think of the situations when this picture is going to be taken. If it is very windy, you don't want the unicorn to be blown away. Otherwise, you wouldn't have a unicorn anymore. And of course, to get somewhere, you need to transport it. But that's very unspecific requirements. So you need to translate those requirements into actual requirements that a product has. So if we think about user input, the user asks, for example, about sizes because they need to transport it and it has some impact on the size. But it should also be visible in the picture. And none of your users will tell you, hey, the unicorn has to be exactly 23.42 centimeters high. They will just tell you, well, it should not be too big. It should not be too small. Now you need to figure out what does the user want to tell you and make it more specific. Afterwards, you can test against the initial input that you received and also against those requirements. The next thing which we had on the slide before is the need to transport it. Well, if you don't have very flexible material, it will be hard to stuff it somewhere. So that might be one requirement coming out of this. And if it should not be blown away or fall off all the time, then it might be that you need a certain rate. And if you want it to carry events, so we need a place to touch them somewhere. So all that are requirements and then must be translated into specific requirements. And even if you have requirements which seem to be specific in a first place, like it should be washable, you still need to think about is this really what the user meant when he gave you this input and feedback. What this user might actually want to tell you is that it should be machine washable. So you need to understand what the user really said. And then we can try to test against this. The last point which we had on the slide before was the requirement that the user doesn't want to carry it all the time. That means also you need some kind of surface on the unicorn which allows you to transport it or stuff it somewhere or fixate it somewhere. So now we have the requirements. What's next? The next thing is the usability evaluation. So we have different categories of usability evaluations. We have two phases in which you can do your evaluation. That can be during the development phase or during the usage phase. During the development phase, you use formative evaluations. You can still shape the product. You can still work on it. You usually have something like a running prototype, 3D visualization, some mock-up or something like that, which you can use and try to adjust to the user's needs. During the usage phase, you usually do a summative evaluation. That means you ask a lot of users and you will not have so detailed feedback. You will ask, for example, with a scale and let the users wait what they think about it. The summative evaluation is, for example, pretty good to compare products with each other and could also be used as the input for the next product. So now you know at which time you want to do an evaluation. The next question is, what do you want to know? What kind of feedback would you like to get? So we have quality feedback and quality feedback, which we can get. Quality feedback could be something like, hey, the unicorn is quite often recognized as a dragon. So maybe recoloring would help. Could be an idea of a user. Or another thing is the unicorn doesn't always fit into the baggage, so it would be cool to put it somewhere else, like in a hoodie or something, other form of transportation. On the other hand, quantitative feedback is more like what we described before with the scales. So you can say, on a scale from 1 to 10, what do you think about the size of the unicorn? Then you will get a rating. This rating will not tell you as much about the qualities, but it lets you compare them. So for one product, you would get, for example, a rating of 7 for the other one, an average of 9. That means 9 is probably better. On the other hand, a qualitative feedback, which you can get. This will help you to understand your user much better because you can ask the user why. Why is it not the way you would like it? What would you need to get it the way you need to have it? And this is also why qualitative feedback is usually used during the formative part of the evaluation and quantitative feedback during the summative evaluation. So next question is, whom should you ask? Of course, there are several usability evaluations, which you can do. One, for example, is a cognitive walkthrough where you go through step by step what is the user supposed to know at a certain point in time? Does he find all the things? Does he have the knowledge? And so on. So for example, you're designing a web page and you want to know, does he find the button for the checkout? Well, first of all, does he already know that he needs to do the checkout now? And then is the creation where is the location? Is it in a good place? Is it following what the user would do right now? So you can go through it step by step and follow the task which the user would have in this moment. A second possibility are focus groups. So with focus groups, you can have a discussion with potential users. But for that, you always need a moderator. So you want to analyze certain questions during the focus group. And you have to pay a lot of attention that strong characters in your group do not interfere with the opinions of other people. So imagine you have five people in that group. One has a very strong opinion and you have two very shy characters in the group. It might be that those two persons will not bring forward their feedback or will follow the leader of the group. On the other hand, if you have interaction between the users, it might lead to interaction between the users, which can also increase the feedback from the users. So if you have a good moderator, this can be a very helpful thing. Then we have the classic usability test, usually also called think aloud, where a user performs a predefined task. You have a moderator which is asking open questions and wants the user to demonstrate what he is doing and speaking out why he is doing certain things. This kind of evaluation allows you to have questions on expectations, on reasons, and on certain choices. So let's say the user is supposed to find something on your web page. So you have a search pattern and you can ask why he is searching for a certain word. You might understand that the user thinks of different categories than you do. And if most of your users think of different categories, it might be worse to just your categories so that the user is able to find what he's looking for. And the last point, which I have here on the slides, is an expert review. So a usability expert or several of them could go through your system, through your web page, work on your product, and try to identify the most common issues that a product has. This can be done during very early phases of the development because your expert will find a lot of these things. But there are not actual users. They might have subjective opinions on certain things and you want to verify this later on with a result of an actual user. All right, that was one slide too much. So remember when we now go through and think a lot evaluation, there is one rule. There is no such thing as a layer 8 issue. So when our user is performing in usability tests, he cannot do anything wrong. You are going to set up tasks which the user is supposed to fulfill on your web page. Then you formulate open questions which you would like to be answered during the usability test, and then you choose some participants from your potential users. And it is good if you have a heterogeneous group. So if you ask 10 times the same kind of user, you will get similar input. If you ask different types of users for your product, you will get different input. And by the way, for usability, it doesn't matter how many users will have a problem with your software or your product. If there is one user having a problem, then there is a usability issue which you have to analyze. So now let's prepare our think a lot evaluation. We will have a user on the stage. And we will go through an introduction with the user. Your user should know that you are not examining him. You're examining a product. So the first thing you're going to do with an evaluation is telling the user what you are up to do. So it could be that you're saying, hey, I would like to know more about my fellow Greeny. He's designed to be a travel companion. Today my interest is in his capability to travel along with you. I would like to know from you, as a potential user, how would you transport him and why you choose to do so? To better understand your thoughts, I would like to encourage you to speak out your thoughts loudly, which will help me a lot. Don't be shy. I investigate Greeny. I do not investigate you. There is nothing you can do wrong. So this here is Greeny. We will do that. And then there is the task. We have a user here. Our user will get now this task. You will need this and Greeny. So you're traveling with HandLuggage to a nice country. You're looking forward to sharing nice impressions of this place with your friends. To do so, you want to take Greeny along. Of course, HandLuggage is limited, which is why I have a bag for you. It already contains some other stuff, which you want to take along. Please show me how you would take Greeny along. Remember to share your thoughts with me. So other user is saying she has a bag now, which she carries over the right shoulder. So she is adjusting the length so that it will be a bit lower on the right side. It's more comfortable for the user. So the bag is full. What is she going to do now? So the first possibility is to put the unicorn on top of the bag. It doesn't seem to be good. And why is it not good? So she says, if she is going through a crowd of people, it will get lost. It will fall off. So then what's your next step? Where would you put it then? So she is searching for something to attach the unicorn. Please speak out your thoughts. So she tries to stuff it below the bag. So it works somehow, but it does not look really good for her. And it's not good for the unicorn. It squeezes the unicorn too much. So next try. What are you going to do next? So she is watching for the unicorn's own attachment possibilities. So she tries to attach the wristband of the unicorn to the bag and then close in the bag. So she says, the unicorn looks all the time down, but at least it sees something from the world. And she said that it is probably secured. So are you satisfied with this version? You're satisfied right now. OK, then let's go through the next questions which we have. So how hard was it for you to store greeny in this bag? So it was very hard for her to attach the unicorn to the bag because the first solution did not work properly. And she really had to look hard to find some place to attach the unicorn. So what did help you to store greeny? So there is something on the unicorn itself which helps to store the unicorn. So that was helpful for the user. What made it difficult? OK. So the problem here is that the bag is a little bit too small to store both of the things because the bag is pretty crowded already. So what would be for you more the problem the bag or the unicorn in that case? The bag is too small and the unicorn too big. So we have very important feedback here. What would you change in order to take greeny along more often? So she would buy a larger bag for that. That's also valid feedback. What do you think of the size of greeny? So the unicorn seems to be a little bit too big for travels. And what do you think of the materials with regard to traveling? It will become dirty pretty quickly. OK. And if you could design a travel company and if you could design a travel companion from the scratch, how would your ideal travel companion look like? So from the beginning, a travel companion designed as how would the ideal advice look like? So here we have the feedback from the user. It would be much smaller so that it can be attached always on the body. All right. So here we have a lot of valid and interesting feedback from the user. So we learned something. We need a way to store the unicorn safely, which could be either in the bag or on the outside if we have something to store the unicorn. And this is how we can think now about the feedback. So we need to structure what we just heard. Thank you very much. And then if you have several users, for example, which have given their feedback, you can try to identify really things which were mentioned more often, for example. So it seems to be a usability issue for most of the people. And the very important question is how can you solve those issues? So here the user said, well, I need to attach it somewhere. It could be on the outside. I need to have a safe way. It could be a different bag. It could also be that my unicorn needs something to transport it in a different way. And once you have collected the feedback, you should prioritize. So like with other software development, it's not good to change everything at once. So if you have 100 points as a feedback and you change all 100 points at the same time, you might have regressions. The same can apply to usability. So it could be that you improve one point. But on the other hand, one other point gets worse. So with usability, you usually check some of the things at a time and not everything. Then usability is a continuous process. So it's not like you did an evaluation once at a time and then you're done. Evaluation can be incorporated into the development process. Running a big evaluation test might be too difficult sometimes. But what about talking to a colleague of yours, asking them, hey, what do you think about this stuff? Where would you search for something and so on? Get them to give you feedback on the software. Maybe also try to get feedback if you're allowed to do so from other people which are not like developers, which are working with you on the same project to get different views on it. And after you've done some improvements, compare the results. Did it really improve? If yes, good job. If not, then you might want to think about a different solution. And once you're satisfied with the usability, you can go over to the next step, which is user experience. Now let me explain the difference. Usability is usually considered the ability of the user to use the thing to carry out the task successfully, which we have seen here. Whereas user experience takes a broader view. Looking at the individual's entire interaction as well as the thoughts, feelings, and perception that result from the interaction. So we have here a much broader view on this topic. Usability is one part of user experience. If you have a nice, funny, shiny product, but the usability is awful, new users are not going to like the product. On the other hand, if you have a pretty solid product, but it does not really look like, it depends a little bit on whether your users are going to use it or not. Maybe not everyone. But it could still be that some people are using it. For example, think of a terminal. Some of the hackers might want to use it, whereas the normal user would hate it because he cannot use it properly. And to explain a little bit more about user experience, I have another example. You can see four unicorns on here. They are pretty similar regarding the user experience, not user experience, usability. So they have similar features, similar sizes, and so on. Which one would you prefer? Lift your hands if it is the leftmost unicorn. Lift your hands if it is the second from the left. There's at least some hands. If it is the orange one, some other hands here, and for the white one, there are also some users here. So you can see, even though those unicorns are pretty similar, you have different preferences here. This has nothing to do with usability. It has to do something with user experience. Something similar you can realize in the floor downstairs. Has anyone of you seen the dysers on the floor there? The decoration part of this event? Nobody? Hands up if you've seen them. OK. So do they do anything for the usability? I don't really think so. But they were definitely doing something for the user experience. They were trying to create an atmosphere. They are purely decorative, but nevertheless, you like to see the motor somewhere. There's a difference with those signs, for example, which we have here. They are supposed to give you orientation, so they have some usability aspect as well. And now, I talked a lot about my unicorn, but now let's also talk about the web. During my preparation for this talk, I was visiting the web page from the MRMCD, which is quite nice when it comes to the way it is written. Who would be potential users for this web page? All of you probably. So we have the attendees here. We have speakers. We also have organizers, and we have some volunteers. Now, we can think about ways to analyze this web page as well. So please say, found it once you realized where to click for the call of participation. Yeah, it has some feedback. It is very small. But even though it is a little bit highlighted, it's not really easy to find, because it's hidden in the text somewhere. And even if you have clicked on it before, you have to read the whole text again to find it. What would be possible ways to improve this? First of all, you could have a link on the top as well, or you could mark it somewhere, like with a little figure in front of it to realize it in the text again. Then regarding wording. User experience also has a lot to do with wording. Last week, I accidentally disabled my numpad on the computer. Happens. And I wanted to search for a user ID. And the response of the system made me smile a little bit. So I wanted to share it as well. So thanks to SelfNet for the example. Which way do you prefer? An error occurred. Please try again. Please fill in all required fields. One required field is missing. No results found. Or in the case of SelfNet, it was, sorry, I'm unable to find what you're looking for if you do not fill in anything. Try to enter something in the field. So I even hear some of the people here smiling a little bit in the room. So that has something to do with user experience. You do not just tell the user what to do, but you make him smile about it. And he will feel better with the system. So one question. Does my unicorn have the perfect UI? Maybe not for everyone. But as it is one of a kind, I am the only user to use it. So my unicorn can relax a little bit. And now I want to say thank you to everyone of you for your attention. And if you have questions, there should be two microphones in the room.