 All right, we're 1046, so I'd like to get started. Welcome to this session on U-Centerfire, which I decided to name it. So, short introduction, technology, technology, technology. There you go, okay. I'm Jacob, I'm one of the founders of Node1, which is also known as... Wundegrod, yeah, yeah, good, good, all right, do it with me, okay. I've worked with UX for a long time. I studied cognitive science, probably where my interest in usability and human-computer interaction actually began at one point. And I created this session because I felt that even today, in 2012, we need to make a case for UX. So hopefully today, you'll be able to leave this room with a few more arguments and ammunition to use when you face someone who doesn't believe. Sorry, I hope the dinner's not too creepy. All right, yeah, just some Node1 stuff you probably recognize. So before we made the captain group all thing, we've done some other fun stuff. This thing is not covering right now. The card game, how many have played the card game? Oh, just Rasmus then, okay. All right, we actually made a video about the DrupalCon traveling to Paris. Five episodes. All of the owners get into a motor home. We drove from Stockholm down to Paris. We stopped in Copenhagen, Cologne, Antwerp and Paris, and we shot an episode in each location. And essentially it was about the DrupalCon and this mission from Dries. We made rock bands, the killing killers, here playing live in Copenhagen. We have the air fresheners. The first batch didn't smell so good, that was a problem. So we had to make a second batch. And of course, those are not available at both. These are old slides, sorry. They're all sold out. You know, if you have one, you should be lucky. Essentially we are full service agency. And there's something interfering with my clicker here. Right. So I felt a good starting point for this topic would be to talk about the myths. The things that you should hear from people that say like, oh, this Yuke stuff in your quote here or whatever it is. What is it? It's just paint. It's just eye candy. So I'd like to address some of those myths and the reality. The first one you often hear is that UX is essentially eye candy. Like the real value comes from the code you write and the functionality that brings, you know? But to understand why UX is not just, it's not about eye candy. We need to understand why UX was created in the first place. So before there was UX, or UX as a lot of these professions come as a response from something. How many people bought tickets using Ryanair's website? Anyone? Have you seen this? So essentially they want you to buy travel insurance but saying no is not that simple. You actually have to scroll down that list. And this is black hat used to belt. This is basically tricking people to buying stuff they don't really want. So you have the plain evil UX, anti UX, anti patterns. And then you actually had just stuff just sloppy. Like this elevator in Spain I'm gonna show you in a bit. This one. I mean everyone here can count in Spanish know that this is, this makes no sense. So I mean we can forgive a small hotel somewhere in Spain. I found this one in a blog called badusable.com. I have tons of these, a lot of these fun examples. I went to Subway sometime this spring and I saw this menu. And I looked at these menus like, what are my options? And then without seeing the other four menus I had no idea. I was like, yeah I can either get a sub, I can get soda or I can get chips or cookie. But it turns out they're all in the same menu. It's just there are three different menus. But you see the spacing here, the wish of spacing makes it seem like each thing is its own menu. And anyone who has a familiar with Gestalt psychology know that there's something, there's sort of patterns to human perception. If certain things are aligned, you believe they're grouped. They have something to do with each other. If they're grouped like they're more, the proximity to certain items is sort of higher than others like this sort of visual group. You also deduce that they have something to do with each other. Anyone had known the Gestalt principles of perception would have known this is bad design. So my colleague had explained to me, yeah you gotta look to the right to see what's included in each menu. So that happens even in print. The thing with bad disability is that it's expensive. That's why I also, in the reason why we need to do expectationers. And that's a great argument, because no one, well, some people would argue with money, but most people they don't ever argue about money. Money is like, money is the argument that trumps them all. So this example is from, I can't remember it's from, but it's a pretty good example. Basically see that, take an e-commerce site with a conversion flow. A lot of people started and not a lot of people make it through. It's like a leaky pipe. You know, you lose pressure at every joint, every poorly designed joint. And Jakob Nielsen, they used to build the Danish as a built-in guru. He, that's a pretty good quote. And the fact is that usually you should even more than a hundred percent. So if your customers are in e-commerce, bad you would cost them money. It cost them tons of potential revenue. I'm gonna show an example here, which is how to make the hair in your neck stand. It's so unbelievable. All right, so I found this example from XKCD. I thought it was kind of funny. That's true. Yeah. It's hard. Even universities, universities they supposedly teach UX. So the fact of the knowledge seldom reaches the IT department. All right, so if UX is just eye candy, can we really resolve all these things using eye candy? If all we did as UX practitioners was making things look pretty, could we really solve these problems using just eye candy? No, we can't, because we do more than just eye candy, because we solve these problems. So UX stands for user experience. There you go. It consists of understanding the needs and goals of users, translating those into features and requirements, designing the interactive flow, the interaction the user has with the website and its functions, and evaluate how the world works and do iterative improvements. You can view the UX profession as an umbrella. It's an umbrella term. And in my view, and I've thought a lot about this, like some people say usability, some people say UX, and in recent years, usability is sort of, less less people say usability, and more say they work with UX user experience. And user experience is supposedly the bigger term. So in my understanding, this is how it works, in my mind. That UX is a profession, and the practitioners of UX, they know interaction design, user-built engineering, interaction design, information architecture, and experience design, and graphic design. So we'll get a bit more detailed with what each of these professions do in everything. But in your role as a new UX professional, you do at least two of these, I expect. But like I said, there's a lot of disagreement here with what UX really is. So I Googled to see what, you know, for Venn diagrams. Venn diagrams are like, I love them. They're funny, they are easy to understand. So this blog here, this guy, Patrick Marseille or something. This is how he views, I'm gonna move on right now. This is how he views UX. And as you can see here, there's a lot of technology tied in here. This is a very coder-centric UX profession. This one from informationarchitects.jp is way more focused on structure and like, of course, information architecture, and even business analysis. I wanted one that's a bit less structured, is this one? Where apparently the user interface designer is a subset of the user experience designer, which also has a, it's also works as an identity designer. Apparently doing branding, which I would expect like a marketing agency to do, an ad agency. Finally, he's also a customer service manager. And again here, you see, this one even ties in sound design in the profession. So there's a lot of confusion here. So I wanted to define what is user experience, what does it do, and why is it important? So let's define this. These are activities. Information design, taxonomy, content structure, what we do in group, I mean, creating content types, creating taxonomies, looking at how fields and entities relate to each other. That's information architecture. Usability engineering. Usability, what the difference I think between usability and a lot of user experience as a whole, usability is very sort of empirical. It's very measurable. It's user research. You make two versions, you can do AB testing as a way to do usability engineering, but you all can also do like, you can also observe the user. Do an observation test, ask the user to perform certain tasks and see how well they do, and tweak, and redo, and tweak, and redo. Bars a lot of its methodology barred from academics, from science. Interaction design. Now this is sort of the fluffy stuff about what we do. When you use a website, you look at something, interact with it. What happens between, what we're designing, what happens between you and the screen. You can't touch it, and it happens in the moment. And we design the actual interaction. It has a bit to do with how you perceive things. It has a bit to do with the copy that's used on the site. It has a bit to do with the buttons to sign, the impression, the look and feel, and everything. But all they're taking together will affect how you interact with the system. Information architecture. Oh yeah, information design. I think that sort of overlap a lot. But information design is more to, I think it's more to do with the, it makes it more a structural approach. Information design is more to how you present information in a way that makes sense to the user. Experience design. When you focus more on the feeling that a system communicates, usability, usability, make sure the system is useful, helps you solve a problem. Experience design is really important, computer games, for example. Or maybe an e-commerce site, where you want to commute a certain mood or something. Because feelings are what's self. People buy using feelings, not their brain, actually. And the graphic design. Making it feel like there's gonna be some effort into it. You like the way it looks. All right, so how do they relate? Let's see here. So user experience and usability, they are their qualities. A system can have great user experience and great usability. It can have poor usability and great user experience. Actually, there are cases of that. But let's look at how they relate to us a whole. So what I did, I mapped these in a circle. In the center, you have the use of built-in goals. And there are essential things like efficient to use, easy to remember how to use, easy to learn, and so on. And by fulfilling those, you can create a great user experience. A system easy to use will automatically be enjoyable to use. That's how they tie in. And even things that are hard to use can actually be enjoyable to use. Games, for example. Like, if you play a game, you want to challenge, you want to master. If the game is too easy, then it's no fun. The best games, they actually adjust the difficulty to your level, so it never gets too hard or too easy. You're always like, you reach that moment of flow. Or you just have the perfect ride of, the perfect amount of resistance. So this is our toolbox. This is a toolbox we have, which helps us create great disability, which results in great user experience. And here's another way to look at it. This is about how great companies achieve great design. Most companies, they don't make it further than achieving things that are convenient. Some companies, they actually create things that are meaningful to their users. And as you all know, one way you can do this is by great design. Great design as in the great design as in your MacBook, for example, is seen now using. And a lot of people, they would quote design as the reasons why they have Mac. Okay. Right. So do we implement solutions? Well, some of us do. Some of us work in small companies where we need to be broad and generic. Some of us have very specialized roles. I think it's very much up to what you do, but if you know how to implement things, I think it helps you in your profession. It helps you understand the limitations of the solutions and it helps you relate to the program as to the people that are gonna implement it. Okay. Mist number two, regarding the shovel. The shovel is a shovel regardless of its color. The thing here, UX is not about how it looks. It's about how it works. So I brought out an example here, a Google Analytics. And I'm sure a lot of you, I think they may have redesigned it by now. This is probably an old version of Google Analytics. But it's still useful for trying to explain how these professions tie in with each other. So starting with the information design, the graph here over the number of visitors to your site is a perfect example of that. You wanna make this information, we would generally just be a table of information accessible and be able to take it in at a glance. How many of you have seen Hans Rosling on TED? His talk. Right. So Hans Rosling is his researcher in Karolinska in Sweden. And he, well, he's full of swords among things. But one of the things he did was that he started working with all this data the UN has on the development level of different countries. Stuff like infant mortality rates, life expectancy, literacy, all these factors. And the UN, they collect this data consistently. But they have them as massive tables. You can make sense of it. So he started working with, I think it's on and on and on to build this company. And they designed this flash app, which visualized the data in a way that made sense. He could basically compare the development stages of different countries at a glance. And his presentation, which I really recommend, he shows how this works. But going from those tables, he applied information design to make the data accessible and available to a lot more people. And the really amazing thing is he really changed as people perceive many countries of Africa in terms of where they stand in development compared to the rest of the world. So information design can have political impact. All right, experience design. The quality of user experience. It has to do with the overall look and everything. This is very much a meta subject of it. But I think it could be how everything ties in and balance. Information architecture, the navigation system. Which subjects go under what subjects? Like where does, for example, where do my reports go? Or if I wanna see how many visit my phone list, for example, or where they go, for example. Information architects often work with the designing menus for websites which reflect the content structure in terms of taxonomies or categories and subcategories. They also design, yeah, you see both menus. They're both top menu and the left menu. Can everyone hear me by the way? Because they keep hearing, like when I turn around, the microphone doesn't capture my voice. All right, usability engineering. What phones do we have? How do we achieve visibility, for example? What colors should we use? Contrast ratios. Trying out different designs, different users, and see how well they achieve their goals with one type of menu and another type of menu, for example. Not the menu structure per se, but the more the aspects of it. The visual aspects of it, how it works, and so forth. Interaction design. You let someone play with these tools. You let someone change the graph and see how it changes shape and everything. You maybe wanna work with a month perspective, or maybe just wanna work with customers from Europe, for example. Make sure that that makes sense to the user. Make sure that that interaction, that the whole sense-making aspect of this. What we in general think. When I click here, I want to do what I expect it to do. And finally, graphic design. Colors, gradient, look and feel. Make sure that the graphic designer supports the user. So, like I said, bad usability, bad UX can really cost a lot of money, but really great usability can really generate a lot of business value, too, conversely. And as practitioners, we have the tools to understand the goals. We have the tools to identify what users need and to design the solutions. We have it in our toolbox, like I showed you. And according to some, this is, I mean, the numbers here are different, but some say that up to 82% of project are considered unsuccessful. The Spanish group, I think, found like 75%. Other research found 85%. Some say 60%. Doesn't matter. The majority of IT projects are considered unsuccessful. And if we subdivide those 80% into what actually happened, we can see that 33% of those edit, 33% of the projects are actually canceled before completion. 25% that deliver on time and budget, but the results are not what the customer expected. Hence, they're not successful. And 25% that deliver what the customer expected, but they blow the budget. This is a problem. I mean, how many projects have you done where you feel like you actually got all expectations right? You got everything on budget. Everyone's happy. There was no stress. Has it ever happened? You see? And we live with this consistently. It's like, it's the status quo. It's like, yeah, that's the way it's supposed to be in our field, in our line of work. So some of the causes of death are lack of user input involvement. Like we never talked to the end users. Requirements are unclear. The buyer doesn't know the requirements. You're not familiar with the requirements. There's a lot of uncertainty comes from there, which will prevent expectations from being synchronized. And of course, expectations are unrealistic to begin with. So I'd like to talk about a tool here called effect mapping. And I talked about it in previous conferences. How many of you are familiar with this idea? All right, some of you. I see my Scandinavian friends here recognizing it. So this exists in many shapes and forms. What we're using is a methodology that developed by a company called Inuse, which is based in Sweden. When you see this, you're gonna think it's kind of obvious. Sadly enough, it's not obvious enough because not a lot of people think this way. But the basic ideas of effect mapping is that every website, every internet, whatever you do is built for a reason. There's a business goal. There's a rationale behind it. Secondly, that rationale, that gain, will never come to fruition unless you're engaged in end users, unless someone uses the site. So your goals will be to understand the business rationale and figure out who needs to use the site in order for that rationale to come to, actually to lead to something concrete. And the result of this work is an artifact called the effect map. And I'm gonna walk through briefly now how it works to design an effect map. So what you should start with is the walk of why. The customer comes to you and say, hey, we need a better website. Are you like, why? Well, it's real hard to find who we are and there's no way to post comments and feel involved. Why? I'm being sure of your customers who want to feel involved. We're getting out of something here. Okay, why? We need to reach those customers to know where to send more sales to our site. Really, there's a business reason here. Better website translates to more sales. It's kind of a contrived, but as you can see, you can actually help your customers come to the conclusion of where they need to go. Okay, this is good, because this means that they can actually set a projection and a goal, which means that you can actually see, you can actually budget the website. The budget of the website is in relation to the actual gain. If they wanna increase sales by a certain factor, they also know how much more money they're gonna make their way and then they can also see how long time they want to write off that investment. So what you need to do is to reach those customers in order to send more sales to our site. So what to do next is we formulate as an effect, the effect of building the site. The effect should be concise, no more than a sentence. It should be measurable and this is really important. A lot of improvements in business come from actually, from setting an action, doing an action setting something in the motion and measure it and iteratively measure, evaluate, and refine. And as you all know, KPIs, key performance indicators are hard to define and hard to design, but try to come up with something you can agree with the customer on. And this also puts a bit of pressure on you, because they can really see that whether you failed or not, it's a kind of hard term, but whether you actually reach the goal, it becomes very concrete. So the good thing is that you can actually agree on something. The good thing is that both parties need to actually take responsibility for the result. You can't just ship off the site and say, no, we're done here. So how do we design a measurement? Well, there are many different ways. I recommend that you try to go with the quantifiable measurements much possible, concrete numbers, looking at percentage of visitors that engage in contacting your site, comment, and share it, and so forth. How many users that you funnel through to actually buy stuff? The conversion rate? And the kinds of users to come back and interact more. These things are very hard, very concrete hard facts that you can measure. You can use forums or questionnaires and so forth. Yeah, questionnaires. You can use questionnaires. We have to remember the quality data you get. That's subjective data and it's valuable, but the problem is that you can interpret the results. So that will lead to discussion. But just consider the implications of what kind of data you collect and how you use it. So in the center of the map I showed you before, there's the effect. Now, this example is from an internet. So it's not the specific example, but the theory is the same. So we put the effect in the center of the map. That's where everything stems from. Then we put the measurements for determining whether we achieve the effect. And then all the measurements also have a timeframe, three, six months or something. So in six months, we want to see that 70% of our staff are logging into the internet on a daily basis. So, okay, so we asked our, we talked about our users, but who are our users? That we can find out thanks to our toolbox here. Using in usable engineering, we can learn things like who are the users, what goals do they need to achieve, what tasks do they need to carry out, and what are the needs and requirements. Usability offers a bunch of techniques and methods for interviewing users, collecting that data, and making sense of it. All right, so we know how the users are. And talking to the customer, they can tell us which users are most important, which ones do they need to engage the most in order to return the goal. So we put them on the map, branching out to the right from the, next step, how do they conceptualize the information they need? So for these users to be able to help, to this user to engage with the site, use it so the customer, so because your customer actually gets the result they want, they have their own goals. You also have a reason for going to the website. What's in it for you? Like why do you go to Amazon? Why do you want to buy books? It's more complex than that. Like your reasons are probably many more. But by figuring out your users reason for going to site and designing by that, you can engage them. Sounds kind of obvious, but a lot of people skip this step. And in this case, if your website is heavily informational, it could be the structure of the content. What kind of content do you expect? If you go to a government agency, you want to find out the tax regulations in a certain case, like you're running your own business, you want to know how much tax am I supposed to pay? The agency should spend work figuring out where are you coming from? What is your own knowledge level? And what kind of menu structure would you expect? What category would you look under? What keywords would you use for searching? So what content is created and used? All the facts that come in here is expired, for example. Like making sure that the content is up to date and make sure that's clearly marked also. How it's related, how it's structured, tagged, and classified, and how everything is labeled for you to be able to find with me. And like I said, you also want to know what the user goals are, the goals and behaviors. When you come to the site, what's in it for you? And here we can apply a series of tools. Experience design. What do you expect from a website? What do you need? How do you want the website to feel and behave in order for you to trust it, in order for you to want to carry out the task for reaching your goals? How do you need to interact with it? And how do you need to look? And the only way to do this is actually talking to users. So I say, if you went to a book site or you used to come by the internal internet, what would motivate you to use it more? Someone say, well, I wish I could download, I could apply for my vacation on the internet. Oh, I could see the phone numbers for my colleagues. I was like, okay, how do you want your phone number directly to look for me? So I want to be able to search, I want to be able to find out, I want to be able to sort easily and everything. So immediately show another features. A lot of requirements would just pop out like that. So knowing a bit more about the users and how they get engaged in the website, we also need a part of goals here. Because again, we want to see how well we help the users achieve their goals. Because if we can't achieve the goals, we won't get the results we want. The effect will never come, will never be realized. And likewise, we make them as critical as possible, we make them measurable. So we also map these onto the effect map. In this case, the administration staff wanted to replace all the paper forms with online forms. They wanted to avoid getting a lot of phone calls because it gets really annoying getting calls every time today. And they won't be able to answer questions directly on the internet. So and that in turn translates to actions. Be able to create forms and be able to let people to do the sign forms. And as you can see, we put the measurable, the goal above there by the green flag. The beautiful thing about this is that these can then come out the user stories, go into the backlog. The customer can then using the effect map prioritize them. And you have a really great starting point to help the site actually deliver a lot more value for the customer. So you sort of bridge the gap between business requirements and implementation by capturing the needs of users. And by converting business value using a user's research and design into requirement specifications. And that's where it all lies. But it's not always easy to explain why it's important to kind of change it. You can cheat with that. And I'm gonna introduce a chart here, a way of visualizing it from UX Mac. I didn't write this article. I'm just retelling it here. I'm gonna put the link to the original article here if you wanna read it. But I'm gonna summarize it. This is called the UX value proposition. And it's a chart. So when you're working on a project and you want to tell, you wanna explain what kind of improvements you can make using UX. And you wanna decide where to put your efforts. This becomes like a strategic overview of what tasks would necessary, how much effort you expect and the results that would come out of it. So first of all, you start looking at all the, all the high level functionality of the site. Stuff like, stuff like with this website. For example, this is a, for this example, it's an e-commerce site. So this customer, they have a brick and mortar store and they want to call it an e-commerce site. They have a number of high level goals, of course. They wanna migrate users from using, from come to the store to buying online. They want to increase conversion rates. They want to increase awareness of what these are the high level business goals. Then you break those down in terms of usability. These are your tools. How can you use your tools to improve, to actually assist in achieving these goals? Stuff like usability, appeal, accessibility and performance. All right. So first thing is a belter looking at these goals. You can see, well, we need to, the website needs to offer you a belter equivalent of better than brick and mortar. It needs appeal to audience that's currently not using online shopping and offer accessibility for people with disabilities, for example. So in order to achieve the goal of convincing people to go online, to go to the store, these are the things, are your toolbox that you need to do. Then you look at the current store. Is it hard to find your stuff? How's it shelving everything? And how could it look on a website? What is the potential? What is the potential improvement? This could go from, a weakness of this tool is that, is that if you do it subjectively, it's very much, it's very much, I think you would have to argue pretty intensely for it. But if you can base it on factor research, it gets a pretty convincing tool. This way you can show the gain, the potential and you can show the tasks and the effort you should try to achieve those. And it helps to show which tasks actually generate the most gain for the least effort and so forth. And you go through and do this for all the business goals and you break them down into usability, use built-in tools in your toolbox where you can actually make a difference. All right, here's a link if you want to, if you want to, I think you can just Google for the title if you want to find it. All right. In the beginning I said that one case where usability really, really can make a difference is in e-commerce. And I found this story last year. It was written by Jared Spool, who as you may know, spoke at Robocon in Chicago. And it's about how changing a form on an e-commerce website includes revenue of $300 million per year. So this is what their shopping cart page looked like. You brought the site, you had a product to share your cart and you clicked. I want to go, I want to go, I want to see the cart. And you had two options. Or you had two options, you could either log in or you could register. And they did some research. Oh, actually, when they designed this. So this is great, you know, like, like repeat visitors, they can just, they can just repeat customers because they don't need to fill in the shipping details. You know, it's a win for everyone. And no users, they just need to go through the registration process. However, in reality, users got really annoyed. They're like, honestly, I just want to buy stuff. I don't want to get involved in a relationship. And why do you need my shipping details? Are you going to spam me? You know, that was the really, the whole perception from the guys in the science system was not really at all in sync with what the users were thinking. So, so, so they're sort of looking at into this whole rationale that users actually save time and everything. So when they started talking to users, the certain people who use the site, there was a lot of users forgot their passwords and they tried again and tried again. Sometimes they didn't remember the email address they used for their account at first place. So the password reset email, they didn't even write up the current email account. They may have migrated email account. They may have sort of given up Hotmail for Gmail two years back. But even when they got the password reset emails, 75% of those links were never clicked. So 75% of potential buyers were lost right away at this point. Right at this point, they just dropped out. And they just waited for the email and they just forgot about it. And they later analyzed the database. It turns out a lot of users had tons of accounts from the fact that they had been, they had been coming back to the site to buy, didn't forget the details and they re-registered. And that made that database pretty much worthless from a business point of view in order of keeping customer information. Because there was so much duplicates and so much incorrect data, so much, so many other details that were out of date. And many users just forget about it. Like, I got better things to do. I don't want to struggle with this. I can go to the competitor instead. So they thought a bit and like, okay, let's make a simple change. Instead of having a login form, let people just continue. Make a button which allows you to just check out and just pay right now. You can register later if you want, but that's optional. You can just continue right now and you don't need to worry about passwords or anything. And the results came almost right away. 45% increase in revenue, which translated to 300 million dollars. And that's from removing one simple button in it. But arriving there was the fact of realizing that yes, there was a problem here. But they didn't catch it with analytics because this step actually happened after they looked at many people that actually picked the shopping cart. And there was no problem with the conversion there. But everything that happened after the shopping cart was out of their analytics chain. So they couldn't see that. So thanks to the fact that Jared Spool and his team could come in and look at how the site worked. You could see that we have a fundamental problem here. And using tools like user built testing, using tools like user experience and analyzing user behaviors, they can find a solution that saved them a lot of money and made them a lot of money. So to summarize, Ux provides a lot of tools that we need to understand actually users and sign for them. And using the effect map, you can visualize the relationships between the high level business goals, the users you need to involve and engage to achieve those goals and what goals they need to have fulfilled in order to use your site. And the Viper Position Diagram helps you visualize, help you show the high level business objectives and what role Ux plays in achieving those objectives in a very visual, good overview. And there are at least 300 million reasons why user built this. Ux is important. It helps customers and it helps your customers increase revenue. Thank you for listening. All right, we have about 20 minutes for questions. So, yes? Yeah. You can talk, maybe you can talk to Mike here. When it comes to the Riner site, I mean, it's ugly, I mean, the options you showed. They also had this big capture that is really hard to read. I mean, captures today are getting higher and higher level. And if that kind of a site meets their business goals in this process, so they, if it meets their goals, it's still okay in that case for Riner. I mean, Riner became successful with their kind of a fitly business model. I mean, I would call it like an anti-pattern, sort of like evil Ux. It's when they use the principle of Ux, reverse them in order to get like, it's like in a casino where they don't have any, they don't have any clocks on the walls, for example. So you lose your sense of time. You design an environment when there were a certain behavior to happen. So, yeah, it helps the business goals, but I don't think it's, I think it's a very short-sighted way. Yeah, I can agree on that one, yeah, I guess. Yeah, so of course, good Ux doesn't always drive sales in the short run, but personally, and I think maybe it's more of a moral or a principle thing, about a principle for me, I believe in long-term, good Ux experience actually helps you make more money in long run for customers. Riner is actually, if your sales are declining, so maybe Norwegian and other actors are kind of having, so maybe that's correct. Well, they generally don't like their customers either, because they, well, they, complaints, they ignore complaints. They don't even bother about them, and they're really rude also about it. So, yeah. Thank you. Yeah. What can you say if you're trying, do you mean like training users? I don't exactly train the users, but I mean like, if you change it with the way you say it works, so that you will follow certain patterns or standards, but at the same time, maybe there's different ways of doing it, and you just can get used to the way the other side works, like the more they're used to it. Maybe the first time they said they are, it's actually been pretty complicated on the staff, but after a time they're used to it. I think you can look at software, like we have a lot of conventions. When you start using a computer like Windows, for example, you have to get used to all these conventions. What a dropdown looks like, how it works, its behavior, and so forth. And then we have a lot of, we have a lot of these design patterns in software. Then it comes like software that's very extreme, like for example, like 3D animation software. And they used to need to expand on those metaphors. And I've been looking at those, really fascinated how they, because you don't want to use them to read the manual to figure out the things work. Some applications like Photoshop, which I detest for its poor usability. You need, there's a tiny arrow here, and there's like all the options available. There's no clue at all that it's there. Some are done poorly, and some are actually able to explain how the software works through the user interface. There's a book called The Semiotic Engineering of Human Computer of User Interface, I think it's called. And it's by, I think it's Brazilian, Brazilian youth researcher. And her idea is that, when you design a user interface, you communicate to the user how the application works. It may not be actually how it works technically, but in the message of the user interface, you can explain how things make sense. If you can take that perspective and design a website, like I said, like ordering things logically, putting things in sequence, I think that's how you can achieve better results in terms of user, user's grasping, how to use the site more quickly. I don't know if I answered your question. Yeah, I mean, it's a bit of a funny question, because I tried to see how much actually a user can adapt to you, or the first moment I said, oh, I don't know, we can get the site, but at that time, they rather adapt to it and see the value of what you did to the user. Now, if you can't avoid it, try to provide information or help, but make it as streamlined as possible. Maybe use any videos or something like, click here for 10 second videos to see how you do this, so they never have to stop or go looking somewhere else. If you really have to have a complicated process, if there's really no way, if you can't go by conventions. So sometimes if you do user testing, that you can actually have a big button there that actually says it's good for you to walk, but you can't find it, what's wrong with that? What's wrong with that? Well, you know, I put a button that says, don't click me, you know? Just type, don't click me on it. Now, I would try and figure out when the user comes to the screen, what are they supposed to do? I mean, something that really made me laugh was when we looked at the reduced build testing on Drupal 6 and we just set up Drupal and you basically create a story or a page. Have you seen the video of the eye tracking? And you see the subject sort of looking like, and the eyes go up and down, up and down, up and down. They can't figure out the difference, up and up and down. So that could be one way. You could, that would be one case where you could actually apply eye tracking to see where is their attention going. Lacking the money to rent or buy eye tracking, you could also ask them to think out loud. Because think out loud. Basically, just speak out their thoughts. Right, I'm here on this page, now I'm gonna do this, I see this, okay, that makes me think, oh, why is that? Where do I need to go? Because I think the problem is that when you see the page, you have a perception of what the user wants or does. And that is not ground on what the user actually thinks. And I think as user scientists, we often design based on assumptions rather than empirical information. I should try to find the actual case here, like figure out what the user wants, actually wants. So talk to more users, do tests, and ask them to think out loud. Because maybe something fundamentally you haven't sort of grasped about them. Yeah. You have a different contract, you meet the goals of the client, meet them. Because you can say, wow, I want a 100% increase of sales. But what if you only achieve 50%? Well, you have the head, it has to be realistic. And I don't think it should be a blame game setup. The beauty of it is that the customer realize you need both to work together. They need to be clear about where they want to go. They need to be clear in providing clear requirements. They need to provide all the knowledge they have regarding their target groups and their needs and so forth. All the market data they have. So you can do your job. It's not a way for you to be the one to take the blame if things don't work out. Because you just do one part of the solution. As I said, a lot of you lies in copy. And things that you should not on your table. Copy could be how they market their site, to who they market, to who they market to. They may be market to a whole different target group than the one you designed for. And you can't really, I mean, if they're not, if you guys are not working and you know, if you're not working synchronized and like working as a whole, it doesn't help. It doesn't help how much, how great your work is. I mean, if you go to a website, I mean, by making people sign up, like if you were designing a new website or something. Of course, I think systems that are appeal to users are perceived. The thing is, you can have a perfectly beautiful written piece of code, but the user interface is poor. People can assume that the quality, the surface reflects the quality, or the interaction, what they see. Because the understanding of system work comes from how they perceive, how they work with it. No, I'd say it's not all just marketing. But I've been talking a lot of revenue things here because that's usually something that makes your customers listen. It's hard, it's called hard cash. It's like, they can't argue with it. And then, so if you can show that to them, then you can avoid a lot of annoying long discussions before it can get to your work, get to do what you like to do. So I say you can apply these principles regardless if it's an existing care customer or you're building a new website. Or someone over there had a question? Yeah. I was, when I was in Amsterdam, Lisa Rex had a session on how did you use build testing at Acquia. And she mentioned the number of different tools they can use for, you can basically upload your site. And they have, basically it's like, it's crowdsourcing, crowdsourcing user testing tools. But a lot of people think that you needed to have the perfect target group. We need to talk to actually end users. You can learn a lot of things just by grabbing your colleague or grabbing your mom or your friend or someone and put them in a room and see what they do. We will discover probably 80% of all the problems and all the serious problems will be discovered that way. But if you want a bigger pool, then I suggest you look at some of those tools. I don't remember them exactly, but you can probably find a session on the website or you can email her, Lisa.Rex.Acquia.com. And she'd probably be happy to point you to those. Yeah. I agree. And it's gonna weigh in on your results. And a lot of things you do in research that you take one group and take a control, they don't need to take all the factors into account. And the same thing here. And if you can motivate people, not with money, but with something maybe like getting them a voucher for a meal or a movie ticket or something, and not for it to be substantial, but not be cash, I think it's a much better way to incend them, sort of create the incentive to take part. And the best thing is probably if you can ask friends or family, someone who want to help you, not necessarily feel like it's complete the task to get their money. Yeah, right. That's a good point. All right. The right one first. I would create a prototype and put a user in front of a computer. You can do a very simple use to build the test. There's a really good book called Rocket Surgery Made Easy or Made Simple. Made Easy, I think it's called. And it's about the guy who wrote Don't Make Me Think. And it was a very simple way of use to build testing. You basically take two rooms. Could be a conference room. You put a computer with Skype. You do like video, like shared screen. And you put a computer outside the room. And you have an instructor in the room and you have someone who's doing the use to build testing. And you show the prototype and you give them a task. And then the other people in the room can watch and observe and see what the person's doing. If your developers were to watch someone use the prototype to form the task, it would probably be better to relate to the user. Another trick is also to work with personas. Like when you design, you don't design for anyone. You actually create a set of people that you relate to. Age, interest, background, everything. You can almost imagine the person standing in front of you thinking, what would he or she think? How would they respond to this? What background do they have? So my suggestion is you write out personas and you tape them to the wall. So they're always there with you. This is the person I'm designing for. These people I'm helping. It becomes much less abstract then. I don't think you should ask the user to design. You should ask the user what they want to do. And your job or your design's job should be to find a solution which helps the user do the job. In the 80s, a lot of talk was with PD, participatory design. It was really popular. And it sounds good, but it's much trickier. Because users don't really understand their needs. They think they understand their needs, but in reality they don't. It's like, this is a really great video with Alan Cooper who's, you've probably heard of him. He's a known UX guy. He's been doing this for maybe 34 years. And they ask him about involving users. He said, yeah, that would be like letting the kids in the kindergarten run the kindergarten. If they say, I want ice cream, you don't give them ice cream, you know? You say, you give them broccoli. And he said, if you eat the broccoli, you'll have your ice cream. So I said, he wrote a book called The Inmates Are Running the Asylum on this topic, like, yeah. So try to design for the users. Be their best friend. But realize that your profession is to decide a tool so they can achieve their goals and do the job they want to do and have to do. And in prototypes and try to involve your developers with the end users as much as possible. That's bring the developers close to the team. I heard of some companies where the project managers like the proxy between developers and the customer or the end users, and that's horrible. Avoid that at all costs. So you have a lot of tools in your toolbox. And which one would give you the most bang for the buck? Which one would generate the most value for the customer early on? And I would probably do wireframing and I would do information architecture in that kind of site. And I would try and squeeze in some time to talk to some end users, figure out how they would relate to the content. I worked with a customer and they had, there was a union in Sweden, they had so much content. And they brought in this agency that works with analytics. And they suggested they would have a four level, navigation menu. I'm like, yeah, yeah. Imagine that four levels. And they even said there's certain many items would lead they would have, there would be several many items that were the same and led to the same page. And that's the problem with the navigation menu because navigation menu reflects the ontology, your understanding of how different content relates to that in terms like subcategories and so forth. The problem is your understanding of the content relates it's much different from how your users perceive it. Especially when it comes to things like labor unions because they have people that are professionals in labor law and they've end users that are amateurs. They have a whole different perception of what is what and what you call it. And in case we have a content intense site I would try and get a better understanding of the card sorting task for example. You can use online tools. There's something called optimumworkshop.com. They have a series of tools. They have tools for tree testing, testing out menus. They have tools for testing card sorting. It kind of pricey. But if you can get, if it's something you can apply for several projects or put it on the customer's belt, fine. It's, that would be a way to actually to do it in a faster way than having to bring people to your office. You can ask the customer to send a link to some of the members. Some of their customers may be nasty and like, would you please help us and then you can maybe can get 10 participants. That would be enough to get a better idea. Yeah, but what are you testing for? Like they're, yeah, yeah. But that's something that, it's certainly tested by using a wireframe for example. The best time to test what kind of, what kind of artifacts you need to produce. Like you may not need to have a ready design to test something like that. What I think is tricky is when you do work agile because you want to do, that case you want to do testing and every spring to the problems you discover can be added to the backlog. So the best thing is if you can test the site of it once you get a release, you have the help to demo for each user story but you also have a user built a requirement for each user story so you can actually validate each user story that it actually works with its post within users. I would, what we've been using mostly is Mockingbird. It's web based, doesn't look that nice. And it's kind of a pain to work with but the fact that we can share all the, share all the wireframes within the company easily, it's a big plus. There's also one, let's see here. Can't remember its name, but there's another one which is much better for creating the clickable prototypes. I know, it takes a lot of time. So I would say the old way you did it was that you had lo-fi, you piece of paper and you say I click there and you shuffle them around. Maybe you just draw the interface as you test with a user. That's also another version. But prototypes are never a sympathy sound. With that in a few cases, when the customers had the budget, but half the budget was designed, half the budget was developed. In that case, it was worthwhile because they thought it was important. No, I haven't worked with that, no. Yeah, I haven't used it but I can see how it provides valuable information. There's a jQuery library called Hover Intent. Which captures, if you hover your mouse for a few seconds over an item, it can capture that. So that's the way to maybe, it gives some indication of how the user is thinking. No, it's not the same, but I'd like to say that eye-tracking, I think, I hear a lot of cases these days when people say one of the users built this thing. Oh, but I can't afford eye-tracking. I say you don't need eye-tracking. You don't need eye-tracking to use the ability. It's nice to have in certain cases, but it's far from required. I guess everyone's, it's really hungry by now, so you can, if you have more questions, you can just send an email or something and I'll ask it by email instead. All right, thank you so much for coming. All right.