Rodrigo: Hello everybody. Welcome this usability webinar. My name is Rodrigo, and I am currently a product manager for OutSystems. You'll notice that the name of this presentation is a bit different from what you got there on your email. This is design user interfaces for designing impaired engineers. I don't want you to get offended. I've been an engineer myself. I've been at R&D for more than ten years, before moving to product marketing. The fact of the matter is that I had to design a lot of applications and a lot of user interfaces.
Along the way, I learned these rules that I'm going to share with you that actually help build better applications. These rules are for you as engineers to use when you design your interfaces. When we show an application to an end user, the first reaction, usually, isn't that good. The reason for that, is that engineers are trained to deal with a lot of complexity. Something that makes a lot of sense to an engineer, many times, doesn't make any sense to an end user.
We are trying to deal with this, but our end users are not. If users are screaming at their computers, what can we do about it? This is where usability comes in. This is why we need to invest in usability. When we talk about investing in usability, there are usually two reactions. The first one is that people assume they don't need usability. I don't think this is true. The main reason for this is that; first, if you have a better usability, you have a better user adoption.
What this means is that, the investments you make in building the application will be spread across more users. This, in fact, increases your return on investment on the time you spent building the application and on the budget you spent building the application. The other reason, is that it takes a lot less cost in training if the application is usable. Right now, we are all using the latest software from Apple on the iPhone, and everything. We don't need training to use them. It's much easier for you to get started with an application if you don't have to read a 500 page manual.
The other important point is that it actually increases productivity. If you do the math and you get an increase in productivity from the employees of an organization by five seconds every five minutes, if you optimize in terms of usability a task so that it takes less five seconds, in just a month, if you add up all this, if you have an organization with 100 employees, you get more than 200 hours of spare time per month. You can get a lot of benefit from usability.
The other argument against usability is that there is no budget for it. Actually, you can do usability on the lean and cheep side. This is something we'll see during this presentation. We'll learn about that in just a moment. Okay. Let's look at the agenda. The first thing we'll talk about, is about the starting with the story part. How can we collect and prioritize the user stories.
Next, we'll see how much does it cost for the user to follow those stories. We'll then talk a little bit about prototyping and the benefits it brings. We'll do a parallel between agile and usability and we'll see usability fits with agile methodologies. We'll be talking a little bit about testing and usability testing.
Finally, after our application is usable, we'll talk a little bit on how you can make it a big picture, because design is also important for user adoption. Let's get started. Let's start by user stories. A user story is one or more sentences in business language. You need to focus on this being the user language. It captures what the user wants to achieve. Let's look at an example.
For instance, this user story is as a team manager, Johnny Boss needs to see a calendar with all the team member's vacations so he can understand if there are important overlaps before he approves vacations. The thing about user stories, is that they have a very well-defined structure. If you look at this, the sentence is as a, and you put in the role of the person, so in this case, as a team manager. You can also add a, what we call, a persona.
In this case, instead of putting just the role, we actually personalize the role with a persona. If you're wondering what the persona is, it's a personification of a given role. You take the characteristics that are typical from a given role. You assign a name to it. This name should be a funny name, an easy to remember name. You give it a few characteristics like: What's his usual tasks? What does he like to do? Better yet, pick a photo for him. Is this a guy wearing a suit and a tie, or is this a guy that wears jeans, and so on.
Okay. This is a persona. As a, and you can put the role and the persona, I want to, so in this case, Johnny Boss wants to see a calendar with all the team member's vacations. That's the goal. That's the desire he has.
Finally, you put the benefit. Why does he need to do that task? So that he can understand if there are overlaps. This last bit is optional and sometimes people tend to not put it there, but you can see that, on the other hand, it can contain very useful information. If you have the motivation, in particular in this case, we want to see if there are overlaps on the vacations, you can make much better design decisions in the future. Having the motivation is very important.
Another thing to notice about this story, is that it's a read operation story. You have two types of operations. You have the write operations. For instance, I want to submit my vacations. You have the read stories. My manager wants to see my vacations. They are both very important. People tend to forget about the read operations. Don't forget about your read user stories. When people start thinking about user stories, one of the challenges is knowing how many to do, where to stop, and so on. I have a few numbers to get you started.
What you should do, is get two or three personas, so two or three roles. From those roles get about 20 user stories. You need to prioritize this list of user stories. Have a simple prioritization rule like, high, medium, and low. No point in making it too complicated. You can start from there. Prioritization, we'll see, is very important for later so that you can optimize your application.
Actually it's a hard bit, because there are a lot of stakeholders for the application. For some, one story will be more important. For the others there's another story. You'll need to do a bit of juggling here, but it can be done and it's very important. It's fundamental for good design. The other thing I would want you guys to notice is that your mileage my vary. You can choose to have less stories. You can choose to have more stories. This is just to get you started.
Going back to the priorities. The priorities are really important, because the most common your user the cheaper should be your UI path. What is the UI path and why does it cost? Basically, a UI path is what the user needs to do in an application to get a task completed or to get the user story done. This includes all the navigation, clicking buttons, and filling inputs. You can actually have a good sense of how much does it cost to perform a user story.
For that, you need to measure, essentially, three types of UI path costs. The first one is location costs. Location costs is how hard is it to find the information, or the link, or the button, I'm looking for in a given webpage. For instance, if you're looking for a movie in a list, it's the time it takes you to get to the movie you want. The next type of cost is the wait costs. This is, essentially, the time you spend looking at the application. If you click a button, and the server takes three times to process your request, that's the wait cost.
Finally, we have input costs. This is the time that users spend at typing in input, clicking buttons, selecting drop-downs, and so on. We'll take a closer look at each type cost. One thing to keep in mind, is that the importance of the cost depends on the user. For instance, a first-time user will have a lot more problems locating information.
For first-time user, a location spots are more important. An advanced user, on the other hand, knows where everything is. He'll go straight at the link he wants, but input costs might be a problem. If you need to type in the same inputs over and over again, it's going to be a nuisance to him. When designing the application, the focus should be always on the user and we need to be careful with the different personas and different profiles.
Let's take a closer look at each of these costs. Let's start with location costs. Whenever the user needs to find something on the screen, there is a cost associated with it. Some studies have been made with eye-tracking technology. One interesting thing we see is that the eye hops around, so when it's looking for information. It's usually this pattern that you can see in these images. It starts from top to bottom and it goes from left to right. Of course, I'm talking western countries. If you go to countries where you type from right to left, the logic is inverse, obviously.
What this means, is that you need to sort the information in order to put the most important information on top and on the left. An example of this is a list. If you have a list of elements, it's very important that you sort it properly. It doesn't matter if the user can sort it as he wants. By default, you should make sure that the list is sorted for the most common use case. The same applies to other UI elements like buttons, links, and so forth. If you look at the image on the right. It's pretty obvious that there are some blobs there. You can see that the eye focuses on certain sections. This is very visible on this image. This happens because of something we call attractors and clusters.
Let me explain what that is. Whenever there is something different on the screen, the eye tends to focus on that different thing. You can do it by having a different style like having a heading, for instance, prompts on forms usually do this work to. Links are also very good attractors. The idea here, is that when you are looking at the page, you are hopping from attractor to attractor. You start on the top-left and you go from attractor to attractor looking for the information you want.
Another cool thing about attractors is that they define, what we call, clusters. You can see here in this page that we have three clusters. We have the top cluster there. That's very well defined by a group. Then you have one in the middle and one in the bottom. You can use this particularity of attractors to define areas and to separate information to make it easier to find and easier to consult and to skip.
Two important things. The first thing is that it seems that the eye is jumping from attractor to attractor. The information that you put there is very important. Taking the principle that a link is an attractor, what we see on this page, you should put the most important information on that link. Let me give you an example. If you have a list of contacts, for instance, you could have the name and phone, and then a link called more details. Usually, when you are looking at a list of contacts, what you want to do is jump from name to name.
A better way to do it is, instead of having a more details link, you could place the link on the name of the person. You are defining an attractor and you are it easier for the user to do the most common operation. The other thing to notice is that, even though you can use attractors to cluster information and to separate information, the best way to make a screen to navigate and information easy to find is to have the least information you possibly can. When we are talking about location costs, less is definitely more.
Let's take a look at a real example. Here we have an example user story. We have an account manager Anna Man, again we use the persona, needs to find the status of a hot opportunity. Another thing to notice is that we are using the users language. This is sales talk. For an account manager, which is someone responsible for selling to a particular customer, we need to find how the status, and the status of an opportunity is something like, it's just started, it's almost closed, it's half way through, and so on. It's usually a percentage from 0% to 100%.
Then you have a hot opportunity. A hot opportunity for a sales guy is something that has a big value, so lots of money involved and something that is almost closed. Here our account manager, Anna Man, wants to find the status of a hot opportunity. This screen that you see now is actually an example of a sales application that was built with the OutSystems Agile Platform, that's our product. We have this application ready for anyone to use and to try. We made a lot of effort to make it as usable as possible.
Let's see how Anna Man would go through to find a given opportunity. It starts on the top-left. Let's assume western countries. Because we have those headings and those underlines and so on, they define areas. The eye moves from left to right. It would move to largest opportunities over there. Some of you, the first time you looked at this screen, you might have noticed that your eye, instead of going to the right, went to the bottom, because there is that drawing there with the pipeline with all the colors and so on. There is a bit of intuition here. You can argue that there is an extra step in terms of location cost.
Let's move on with this. The other thing to notice is that we call this largest opportunities. In the user story, we talked about hot opportunities. This would be a good place to improve this application. There is always room to improve an application in terms of usability. We could look at stories again and we could determine that hot opportunities is a more adequate way for this section instead of largest opportunities.
Let's move on. Anna Man has found this cluster. What usually happens is that the eye goes blind for whatever else is on the screen and she's going to focus on this bit only. Now, she will go from top to bottom. That's the pattern. It will start on the chairs, desks, and tables. It will go looking for the opportunities until she finds the opportunity she is looking for. In this case it's an office chairs and desks opportunity at a given company.
Next, we got another cluster defined here, which is defined by this row. Once she finds this row, she can very quickly find the status of the opportunity, which is 70%. When a bit of intuition, you can go through the steps and determine exactly what the location costs are for a particular element and for a particular story in your screen.
Another important thing to notice here is that from the beginning, all the data that you saw made sense. I don't have here opportunity #1, opportunity #2. I don't have company 1, company 2. If you make an effort to have proper sample data, it's much easier, both for you to test the application, and for you to show the application to your users. If you show opportunity 1, opportunity 2, company 1, company 2, or XPTO, or whatever, they will not understand what the application does.
Remember, the information that appears on the attractors will be dummy information, so it will make no sense for a sales person. You need to put real data so that the users can actually get in the application and test the application and feel how it works. If you don't do that, your users will not understand how it works. That's a very important bit.
Some rules of thumb for location costs. The first one, and most important, is less is more. You need to be careful selecting the information you put on a given screen. The next one is, you should cluster related data. Make it close together. Use attractors to define clusters. Put related data close together. Make sure you have the most important things on top and on the left, of course. If you have attractors, for instance, in a list, they should be above and towards the left.
Going back to the contacts example, they should have a list of contacts. The attractor is the name of the contact. You should place it on the left. Not in the middle. Not on the right. It should be there on the left. Be sure to speak business language when you build these attractors. This is important even in demos. Make sure you have good sample data. Those are the main rules of thumb for location. It's always a balance. Don't forget that you need to make sure what are the most important user stories and those are the ones that you need to invest more to make the location costs as cheap as possible.
Let's move to another type of costs, which are the wait costs. This is the time the user spends looking at the screen while nothing happens. For instance, if you're loading a new page, if you're navigating a web application from page to page, that usually takes a bit of time. On the other hand, if you use pop-ups, the time will be shorter. Actually, sometimes a pop-up is also a page load, but they're usually smaller pages. Because there is that animation of the pop-up for the user, it looks like less time. They have, also, because of that, less wait cost.
Finally, we have rich internet application with AJAX patterns that are very fast and they have the least wait cost. This is, actually, why we made it so easy in the platform to have this pattern so the OutSystems Agile Platform supports this so that you don't have to worry too much about implementation details and you can decrease these wait costs. If you'll look at this, there are two ideas to decrease dramatically the wait cost of an application. The first one is to move everything to AJAX. AJAX increases the cost of both developing and understanding the application. You always need a balance between what you are investing as a developer and what the user will get.
The other great idea to minimize wait cost is to have everything on the home page. If the user doesn't need to navigate, there are no wait costs. I bet you can see the problem there. In the previous slide I said less is more. If you put everything in the home page, suddenly the location costs will be maddening and the user won't be able to find anything. Always focus on the balance and focus on the main stories.
Let's move to input costs. I bet you are familiar with this. Each time you go to a magazine article and you need to fill in a 20 field form, you get input cost. You have to type in everything. You have to select a bunch of drop-downs, you have to submit. Those are the input costs. You get a cost each time the user needs to input a character or a letter or whatever. You get a cost each time the user has to click on something like a drop-down, or select and element from drop-down.
Finally, you have the cost of focusing. Imagine yourself with you hands on the keyboard and you have to move your hands from the keyboard to the mouse so that you can select the input on the side. That has an even higher cost than typing. There are actually two tips here. One of them is, if you are building an application and the page the user is going to is a form, focus on the first input. Have the cursor there so that the user can start typing immediately. The other one, is obviously, make sure that the tab key works properly. Make sure you define the tab key in the right way so that the user doesn't need to move the hands from the keyboard to the mouse.
Let's take a look at an example of input costs. What you're seeing here is our old style guide. This was a style guide that we use in our old applications. The new versions of the platform have a better style guide. This is an example of a form to input a new contact in a directory application, for instance. There are some problems here. I'm going to focus on a few of them. There are a bunch of problems here.
Let's focus on a few. The first one is here. The company. The problem here is that, to put in the name of the company, you need to click once to drop it to open the drop box. If you are in a system that has a lot of companies it will take a high location cost and you have to scroll over and over to find the company that you want. It gets even worse if the company does not exist.
If this is the first time that you need to input this company. The problem is that, what you need to do is get out of this form, click on the new company, type in the name of the company, click the button to save the company, go back to this form and fill out everything, and then go through the same process of clicking on the drop-down, finding the right company, selecting it, and so on. This is definitely something that needs improvement on this form.
Another detail is that we have two buttons here, the save and cancel. They have, basically, the same location cost and they look the same. They are on the left. They are the same size, and so on. How could we improve this? Over here you have a screen shot, now over our new fall guide. We have the same type of form. This time it was optimized to be more usable.
The first thing that you probably notice is that we don't ask for so much information. We removed the mobile and the secondary email. What you have to do is see how often these fields are introduced and remove the ones that usually don't get filled. You might have a details form for those. We actually moved the mandatory inputs on top. Following the rules of having the most important things on top-left. We moved the mandatory to the top. They are the most important.
Finally, we have this special input to put in the company. This is an input that we created and that we share with our style guide. Everyone can use it. It's basically and auto-complete. The cool thing about this is that you start typing, if it exists, you can pick one that exists, but if it doesn't exists it will get created. You don't have to move to a different screen. Loose all the work that you've done, and so on, just to put in a company that does not exist.
We also changed a bit the look of the buttons. The cancel, since it's not used that often, is now a link. It attracts less attention. It works as less of an attractor. Usually people type in more than one contact in one go, in this application. You need to understand the application and the use cases and the user stories. We added a save as new button. With just a few changes we dramatically optimized the usability of this particular form. Going back to that company input there, I would like to highlight that your choice of input depends a lot on what type of data you are looking for or that you want your users to find or fill. The best input depends a lot on the domain of the data.
Let me explain what I mean. Drop-downs or combo boxes are usually used for very small domains or sets of information. One example is the status of a sale. Like you have there, closing this quarter, of the status of an issue you're tracking on your bug tracking system. It can be new, open, closed, and so on. Usually, if you have sets of around seven elements, the drop-down is good for you. There are exceptions.
For instance, sometimes you see drop-downs of countries and there are 100-and-something countries. The difference there is that they're easy to find, if they are organized alphabetically. Never group the countries by region, because then you have 130-something entries that you cannot find. If they are alphabetically they are easy to find. That can apply to those kinds of inputs.
You have something, which is the auto-complete. Auto-complete is good for very large domains. Good examples of this are company names, like the example we showed in the CRM system where there usually hundreds of companies. Email addresses are also a good example. If you email client and you want to send an email like Gmail does, you want to have the auto-complete if you already typed it in. If you never typed it, you want it work anyways. Auto-complete's are good for those.
Finally, you have the input for domains that are infinite, or practically infinite and that are very distributed like the name of a person. Input rules of thumb. Make sure that you sort your inputs properly in your form. Put the mandatory ones on top. Try to order them by frequency of filling the ones on the bottom. If they are very rarely filled, you might as well remove them and put them in a details page, or something like that. Try to minimize both the typing and the effort the user needs to make when he switches from keyboard to mouse. Switching between typing and clicking is also very expensive. Whenever you can, and it makes sense, focus the input automatically. Make sure you make good use of the tab key so that it makes it the order the tab goes.
Finally, try to use defaults as much as possible. One example I like to give for this, because it's something that bothers me a bit, is the country. You usually can spot the country the person is in without any violation or anything, just by doing a simple query on their IP address you can find where they're from. Why not fill in the country automatically for that person instead of having the drop-down with 135 elements, or something like that. That's a good example. How can we cut the costs for a common use story.
We saw some examples of decreasing input cost, but let's look at this in the scope of the whole user story. The user story that we have here is that, again, our Anna Man, as an account manager, she needs to see the opportunities that she thinks are going to close this quarter. This is written in sales language.
The reason why Anna needs to do this, is because sales have a very tight portrait. They need to close those sales, because the money they make depends on the sales they make. The idea here is that Anna want to go for those that have a higher chance of being closed this quarter. What I'm going to show here, is our old go at this problem using our old style guide and this a standard CRUD. CRUD is usually what you do on top of the database table. You have delete with the filters and so on, and the edit screens.
The problem is, let's see what does Anna have to do to reach her goal. First, she has to click on the opportunities when she gets in the application, so that's one click. Next, she's going to have to click on the filter so that she can open the drop box and select herself, because she wants her accounts that are closing this quarter. Then she has to click the other filter, the all opportunities, and select only the opportunities that are closing this quarter. A couple more clicks.
Then she has to click on the calendar on the date input field, which will open a calendar. She will have to navigate to the date that represents the end of the quarter. Then she will have to click the OK button to fill in this.
Finally, she clicks the search button. She has the results. As you can see, this is a rather costly operation. Because this is such an important user story for an account manager, we really should optimize it. She has to do a bunch of clicks. There's a page load and it's very hard to locate the end of the quarter. This is easy, is 31st of December, I think, but locating that on a calendar is not that easy.
Let's make this a bit faster for Anna. What you see here, again, used the sample application that you guys can try out on our website. It's a huge difference. Since we know what Anna wants to do, because we collected the user story, we know that the common use case is for the account manager is to see her opportunities. We immediately filter by her opportunities. We also know that usually she is interested in this particular quarter. What we do is we have a smart default for the filter and we filter immediately by closing this quarter. We have a different organization on the list.
The most important stuff is on the left side and you actually have the link acting as an attractor for the name of the opportunity. We actually sorted this so that default opportunities are on top. Everything is sorted so that it's top and left. Remember the F pattern. The same user story with two different designs. On the other one you have nine clicks and a bunch of other stuff. Over here you have one click and one page load. It's a world of difference.
You might think, what about the other opportunities? The other opportunities aren't such a common use case. We can hide that use case on the right. Put it on the least seen area of the screen. When someone really needs to see all the opportunities, because they're looking for something, it's still there for them to look for. Another example. Again, Anna Man, we're focusing on an account manager, needs to log some information after talking to a contact. This is what usually sales people do when they go to a customer and they talk to them, or when they have a phone call. They type in the result of that phone call.
Let's see how we can solve this problem. I'm going to use the example of the old-style guide, so the old way that we had to do things, and then I'll compare it to the new. The first thing you should note here is that, how can I put a note? Where do I have to click to put a note? That's because it's very well hidden. You have to scan the whole screen and you have to look for this. Following our rule that on the left should be the most important thing, you have on the left the export to excel functionality, which is actually not that used, and the new note is hidden.
The first thing is, it's hard to find. Then you have to click it. It will show a screen. You'll have to click on the input. You'll have to type the message. You'll have to click on the button to save it. That will generate a refresh. You have a bunch of operations that happen just for you to submit a note. Here's how we redesigned it. We make it much easier to find. It's an easy location. It's center-staged, because it's the most common use case on this screen.
The only thing you have to do is click on the input, type in the information, and click add to this note. We could have actually optimized and focused the note for you. The thing is, you need to keep in mind when you focus an input, if it's below the fold, so if it's not visible on the browser, the browser will scroll to that input. You need to be careful when automatically focusing inputs that are not at the top of the page. This is also a good note.
Let's make this a bit more complicated. Now, instead of our account manager, Anna Man, we have our sales manager Sandy Boss. After talking with Sandy Boss, we came up with the four most important user stories for her. I'll just talk about the first one. You can quickly read the other ones. The real important story for Sandy Boss, is that she needs to monitor how the team is going. This is sales talk. For sales people, what happens is that they have a quota. They have to have a given volume of sales on a quarter. This is for an account manager. An account manager needs to sell that much. The sales manager is responsible for all the account managers. She also has a quota, that's the sum of the quotas of the account managers. That's what she wants to keep an eye on.
That's the most important user story for her. Then you have the other stories, which are also very important. The question is, how do we implement these stories that are so important for Sandy Boss? The answer is put them on the home page. This is the first page that Sandy will look at when she logs into the system. This page, this home page, this dashboard, has all the most important information that she needs to see. That number that she really needs to keep an eye on, the quota, is right over here, big on the screen. It's very easy for her to log in and have the most important information right there in front of her.
Notice that then, this is on the top-left, because it's the most important. Then around you have the other use cases and the other user stories that were described earlier on. You have how each account manager is performing regarding to their quota, what's the status of their pipeline, what's the forecast, and so on. The most important one is top-left. The most important use cases, whenever possible should be on the home page. Notice that for Sandy, the most important stories are all about reading information. They're not about imputing information into the system. You cannot forget this type of scenarios.
Another thing is because the goals of different users differ, their user stories are different, you might need to do different home pages, depending on the profile. Going back to Anna Man what she wants to see is the largest opportunities or the hot opportunities. You can see there on the right you have the largest opportunities. She wants to see her status on the quarter, so that's the information on the left.
Then, on the bottom of the home page that's for the sales manager. You have all the aggregate information for all the account managers, and the trick here is actually to look at both what are the key performance indicators for this person. The thing that she really needs to do for the company, the things that will affect her bonus at the end of the year, that's the thing that should be on the home page along with the most common user stories.
We have our stories. We prioritized them. We know how to decrease the UI cost following this rule. The next thing is: how do we implement it? And before you actually implement, really our advice is to prototype it and notice that you don't need to prototype everything. But, at least, the top user stories, you should make an effort to do a prototype, and especially the home page is definitely a place you'll want to do that.
The thing about the prototype is that you can and you should do a low fidelity prototype. For instance, this prototypes over here where I am using Balsamiq, which is a software used to design prototypes, but pen and paper are also very good. One trick that you can use is print a frame of a web browser on a page and start drawing right there
This allows you to not be restricted by the technology. You don't have a problem with CSS or with whatever. You can just draw it at will. And the fact that this is low fidelity, so it's a rough drawing, it is an advantage because when you are discussing with your stakeholder, your customer, you are not focusing on the color of the button or if that should be underlined or in red or whatever. You are just focusing on the functionality, so that is definitely an advantage.
The other good thing is that you need to make sure these are cheap and fun to do because these don't want to create any emotional attachments to these prototypes. If there's no hard work here, you'll have a lot less problems throwing it away, and that's the goal of prototypes is to be thrown away so that you can improve and improve and improve.
And finally, an important rule about prototyping is BHL, get feedback early. I know this can be scary, and sometimes you really want to improve the prototype because you want to show something that looks really good, and that's easy to understand and that everybody is going to praise you for it. But don't be afraid of early setbacks, again, because of the emotional attachment and because, if you're getting to a point when you're getting nervous about getting feedback, it's probably the right time to go and get it.
It's the right time to go to your stake holder or your colleagues and get feedback on your prototype. The other thing is: how does usability fit with Agile? I'm going to assume you guys are all familiar with Agile methodology.
I will now explain this chart, but in a nutshell Agile stands on the idea of small and fast iterations. This is a particular case of an Agile methodology which is Scrum, where you basically start by doing a plan of what you're going to do on the next print which is usually two weeks. And then after two weeks, you deliver something that is ready to use, and you demo it to your customer or stake holder.
The place where usability goes in is first, when you are planning the next thing you're going to do, the next user story you are going to implement, this is a great place to start prototyping and to show the work you have done, in terms of paper or Balsamiq or whatever you choose to do for prototyping.
The other idea that's very important is here. It's when you have something ready to ship because this is when you will do the usability testing, and one great thing about Agile is that you can actually test with the real software because you're delivering something that is working. It's not an idea. It's working software, so you can test on the actual thing.
The ultimate test, the ultimate usability test is for you when you are doing the demo for your stake holder to have the stake holder perform the demo. If you can do that, you're way ahead in terms of usability. Now, obviously it depends a lot on the relation you have with your client, so usually it's not possible. For that situation, there are other types of tests which bring this to the fifth point which is test, test, test.
The book you see on the screen is actually a great book on usability testing because it's very pragmatic. It's full of great ideas for you to do tests on the cheap. It gives you all the steps you test. It has a check list. It has the script you need to form a test from beginning to end without spending a bunch of money. I definitely advise you to take a look at this book, especially the check list, and what they do to make sure that the tests are easy.
To give you a very rough idea of what you can do here, there are essentially two types of tests. The first one is the hallway test. Now, in the hallway test what you do is you grab an innocent colleague that's going by calmly in the hallway and you ask him for 50 minutes to test your application. You sit there next to him, and you start by introducing the test. It's very important that you tell him that it's the application that's being tested. It's not him that's being tested, it's the application, okay?
You ask him to tell you what are you thinking about while using the application? What are you looking at and stuff like that? Try to get in his mind and his thought process and try to get as much information about that as you can. You will be basically the shrink of the guy. You'll try to get the whys. Why is he looking there, why is he clicking and so on?
Two other important things is that you shouldn't help him. Even if he gets frustrated, try to see how he gets out of the situation, and you shouldn't apologize. It's nobody's fault. It's the application, again, that's being tested. That's the goal.
The other type of tests are cheap live tests, and here are the ideas, that you actually get someone from the outside and you apply the same rules as you did on the hallway test. You introduce the test. You try to get what they're thinking and so on. Here, you usually have the person testing the application, and then you have a moderator that will try to get the most information as possible and so on.
This is something that you can do on the cheap, so you can do this one morning a month of usability testing, and obviously it depends on the persona but usually you can get people to test by giving them vouchers for major stores and so on. This is something you can give them. It's not that expensive. And then, what you do is -- this is just one half of the test.
The other half of the test is having your team looking at what's going on during the test, and one thing you need to be sure is that the team that's looking at the usability test is far from the guy that's testing the application because they are going to scream and they are going to make noise. Because when they're watching the guy trying to perform the user story, it's like watching a football game. Everybody is screaming, "Don't touch that button. Can't you see that the information is right there in front of you? So, this gets very, very emotional.
This is just like watching football or soccer of whatever, but the fact of the matter is that this is the best way for people to learn about usability, seeing users that have different thought processes, that never saw the application before, use the application. This is a great tool to learn about usability.
Now, at the end of the day what you end up with is the three top things that you want to prove in the application. After the test is done and they all stop screaming, you get everybody together, and you decide what were the three main problems that you saw in the user testings. And those are the ones that you are going to fix. You're not going to fix everything because that's impossible. Focus on the three top ones. You solve those, you can next month repeat the test. You can see this fits pretty well with the methodology.
We've talked about how to make the application usable, but how can you make it pretty because as it's becoming obvious, the design is also very important in terms of end user adoption. A good looking application will always have a better end user adoption than a not so good looking one.
There's this great book, The Non-Designers Design Book, which focuses on something that they call the "CRAP" design rules which is a funny name for a design rule, but what it means, what it stands for is actually contrast, repetition, alignment and proximity. These are the rules you need to follow in terms of design, when designing an interface. If you follow these rules, your applications, trust me, will look much better than most applications that I've seen in my experience in R&D. They're actually easy to apply, but you need to train your eyes to spot the problems.
Let's look at what is this? What are these rules? The first one, contrast. The rule about contrast and this is very much related with our notion of attractors and of clusters. The idea of contrast is that there should be a big difference between elements, not a subtle difference.
For instance, if you have sections and headers, you should make them obvious, make them bigger, make them bold. Don't just increase the font size to pixels or so on. No, exaggerate a bit. Have a big contrast.
The other principle which is repetition is basically about being consistent. Don't use four different types of fonts on the same screen. Don't use underlines in one situation and bold in another, not bold and so on. Be sure to get consistent across the size of the fonts and so on. This is repetition. This is obviously being made easier by stuff like CSS, but we still see a lot of applications that have too many different types of visual language for the same thing. Be sure to be consistent and use repetition.
The other principle is alignment, and alignment is important because just look at an application that you just have made. It starts on the top left on the logo. Try to draw a line along that black border and if everything is standing on that line, you've got good alignment. You need to be careful because usually there's small steps to the right, small steps to the left and so on, and as you can see in this example, everything looks in balance because of that. You need to be careful properly aligning stuff.
One rule of thumb here is: unless you're really, really know what you are doing, go for left alignment. Don't center align stuff because that's usually much harder to get it right. Align things on the left. That's the best way to go.
The final one, the final principle, is proximity. If you have related elements, they should be close together. The fact that you're changing the way that they show on the screen, you associate together things that are close to each other. Make sure that you get your proximity right. Again, it goes very much into the notion of clusters. You want to properly define your clusters and make sure that it's easy for the user to find the information and that he can parse the information really quick when he looks at the screen.
Things to remember of this enormous amount of content that we've gone through in the last 50 minutes.
First, focus on the most common and most important user story. Make sure those have the cheapest UI path possible, in terms of location, in terms of lable and in terms of input.
Be sure to carefully select what you put on labels because it makes a world of difference if you use the business language instead of your language. It makes a world of difference if in your demos you show sample data that makes sense to the user as opposed to company one and company two.
Remember the sort order; the default sort order is very important. So, the most important thing should be on top. Use smart defaults for your input. If you can fill it up, make sure you have smart defaults. This is particularly valid as we saw in the examples of filtering.
Finally, be sure to use the top use cases for the home page. Think KTIs, think most common user story.
Prototype and prototype early and show our prototype early to your users because they'll help you back for sure and do use usability testing. This can be done on the cheap, both with the hallway test and even getting people in your office to do this test. It can be done cheaply, and it makes a world of difference. Your application will benefit tremendously from usability testing.
Finally, follow the design rules of "CRAP", contrast, repetition, alignment and proximity. Just by following these guidelines your applications will look much better for sure.
That's it. That's what I've got for you today. Thank you very much for listening. The URL you have there are actually applications that we built using the ALT Systems Agile Platform.
My homework for you guys, like I said, applications can always be improved, so go there. You can try them for free on our website. Just click the "try it now" button, and I would love to get your feedback on things that can be improved on those applications in terms of usability, what you think about them, what could be improved and so on. That would be great.
I know we're a little bit over the hour, but Miguel Melo has been here with me watching the chat window, and I know there are a few questions so I'm going to ask Miguel to sit right next to me. Unfortunately, we don't have the time to go through many of them, but I'll go through the top three questions. So, Miguel, what are they?
Miguel: Okay, I've got one here which is: who should facilitate the user test? Who should actually push for the user test? Do we hire an external company?
Rodrigo: Facilitating the user test. You are right. That is a very important role. The person that moderates the user test has a big responsibility because he needs to make sure he doesn't influence the user, that he puts the user comfortable and so on. One good thing is to get someone that's not part of the project because there's always a bit of bias, even involuntary from someone that's in the project.
But, actually, I would say that the best way to get started in user testing is for you guys that are attending this webinar to push the test and to be the facilitators. You obviously have an interest in this area. This is a topic that is important for you, so you're the best candidates to do the first user testing.
And then, you can try and find someone, I don't know, that has software skills or is external to the project without bias and so on, but I would say you guys listening to this webinar are the first candidates for being the facilitator for the tests.
Miguel: Okay, okay. There's another one here. We were talking about usability. What's the relationship with having a designer? Should we hire a designer to help with the application design?
Rodrigo: The goal of this webinar is to give you guys the tools to design better apps and more usable apps, but it assumes that either because you don't have the budget or because of political constraints you won't be able to hire a usability or a design firm. If there are no such constraints, by all means I definitely recommend that you bet on hiring either a designer or a usability expert. Usually, that's not the case and being a bit more pragmatic and assuming you only have a bit of budget, you can definitely get the help of a designer to make sure your application looks better.
One thing we've done in the past is actually ask for a designer to take a look at our applications, and we found patterns in those applications like building blocks, and we asked the designer to give us a solution for those building blocks and build us sample screens that use those building blocks.
And then, we used them on every application that we created. So, we had a one-time designer that designed this project for us, and then we used that to make sure we built good looking apps. That's one way to get started if you have a low budget for design.
Miguel: Okay. There's another worry that's basically with this Agile pattern that ALT System advocates. How does usability fit with the Agile because things tend to sort of evolve as they go along? And in particular, the question was: there's a worry about it in terms of usability, in terms of tests. How does that get married with the Agile approach?
Rodrigo: I'm going to focus on the Scrum methodology. That's the one I'm most experienced on where you have, like I showed you on the graph earlier, you have pre-planning session. Then, you have the actual Scrum work done, and finally at the end there's achievable product that's more of less how Scrum should work. So, during this pre-planning session you should start with a low level prototype. Do the low level prototypes to discuss: what is the user story? How is it going to work, and what's the most important scenarios and so on? That's the area where you usually do the low fidelity prototyping.
Then, during the iteration itself, so while you're developing you should apply what was shown here on this webinar. So, we use these principles in terms of location, cost and so on, in terms of the "CRAP" rule. With that, you can start building a usable and good looking application.
Another thing you can do during the iteration is do the hallway test. Just grab a colleague that's going by and have him do the story that you're working on, and I'll bet that in 50 minutes you'll have good feedback on things that can be improved, and you'll get great insight on the work you are doing.
Finally, when the iteration is done, you have something ready to be used. That's one of the tenets of Agile, that at the end of iteration there's something ready to be used. And that's the point where you can do the cheap usability tests. Again, like I said, the end result of this test will be the three major things that need to be improved on the application. So, you should put this back on the backlog, and you should discuss it and consider it between the next iteration.
And so, the work goes on. You do a prototype and so on. So, this is it
Miguel: Okay. Just one final question. I actually got this from several people in this web cast. Are the slides going to be made available at some stage?
Rodrigo: There will be a recording made of the web cast, and that will be made available. We will send an email to all participants with the location of the web cast. I'm still not sure about the slides, but I hope so.
Rodrigo: We're over the hour. Sorry about that. Feel free to contact me if you have any doubts, and we'll see you again later. Thank you very much.
Miguel: Thank you.