Wednesday, April 9, 2014

3 things you should always do when you design

The UX methodology is based on three main pillars. These are research, design and testing. Doing these three things in any shape or form will help you make better designs. These steps can be simple and very easy when used in a project, as I will show you in this article.
The Usability Professionals Association has created a poster with a complete UX process but most of this is only really needed when you plan to design an entire application, not for a single screen. Higher complexity projects do require a lot more complex UX methods but for the example below we used super simple methods because it only has one screen and the tasks are actually very simple. A small project is a good way to start using this process because you can get a lot of benefit from very few simple tasks.
While you don’t need to follow the 35 steps shown in this poster, the three basic steps outlined in this article are necessary. They help to surface very basic problems in the thinking around the user tasks and the resulting screen. If you perform these three steps, you will have your bases covered. You will have some basic things right because you used a methodology that made you contemplate the user and their interaction with the functionality on your screens.

Step 1: Research

Document the main tasks and subtasks

The first step is to do is a Task Analysis. Document the user tasks and do not worry about the screens as yet! If you don’t know what tasks users have to complete you need to take a step back and create some scenarios that you can use to identify the main tasks. Here is an example of a documented task analysis from one of our recent projects:

Contemplate the steps shown in your analysis and decide if they are optimal. This is an opportunity to weed out any unnecessary steps to make the task flow as simple as possible. When you design the screen you will want to be sure you understand all the tasks users need to accomplish and in which order they need to be completed.

Find out who the users are

In every UX process the research step includes some research on user profiles, called personas. These are not system roles but more like types of people. A persona also describes the flow of someone’s day, their skills, attitudes, environment and goals. It answers critical questions that a job description or task list doesn't, such as:
1.     Skills: What IT skills do the users have? Do they use computers outside of work (phones, tablets, PC’s)? How long have they been performing this task?
2.     Environment: Where do users perform these tasks? Do users focus on one thing at a time, carrying it through to completion, or are there a lot of interruptions?
3.     Motivation: Why are they using this product in the first place? What motivated them to select this product?
You may not have the time to visit your users but that does not mean you cannot include them when you design. You may have met users, like those you expect to use your screen, before and remember what kind of people they are. Try and get a feel for these people and imagine a persona that embodies their main characteristics. This will be a stereotypical person and may not be true reflection of all of our real users.
Keep that persona in mind when you design and test, as it will represent the real users. This may not seem to be useful right now but it will be useful when you design and test as it serves to remind you when you have to make decisions regarding your design.
Except for them being bulk buyers, we do not know much about the users of the UI for the electricity project. We will need to assume the worst conditions for working with this screen. We will assume that users are not IT literate at all and the environment is very noisy and busy. This means there will be plenty of disturbances and the task will need to be super simple to complete.
If we had time and money, we would do a large
 ethnographic study on the users to figure out who these users actually are and where they actually work. However, there is no time or money for this and we will just have to assume.

Step 2: Design

Come up with a some options regarding the flow

Now is the time to start making some interfaces. The page containing the electricity order form is a support structure that serves to support the user while they complete their main task, namely ordering electricity. So, we start by making the order form, getting that right and then considering the historical purchases table as it is the secondary user task. Only thereafter will we consider all of those elements the page needs to support the user while they complete these tasks. Such supporting elements include everything that is not directly needed to complete these tasks. 
Draw your ideas up by hand on paper or a whiteboard. This is cheap and quick. Take a picture to make a neater drawing once you are happy with your concept.
For our electricity project, the client gave us this concept which we used as a starting point for our discussions.
The concept was described as follows:
  • Users navigate to this screen
  • Back button top left corner
  • Create button in the middle of the screen
  • Hidden: A form where they can enter the amount and submit (shown when users click “Create”)
  • Hidden: The result of the order (this information replaces the order form after it is submitted)
  • A table with historical purchases and links to download related invoices

Contemplate the options and select the best workflow

This is where you will need to contemplate the tasks from your analysis as well as the persona you have created. Think about how that persona will interact with your concept.
We contemplated some questions
  • Where should the “back” navigation be on screen?
  • Where should the order form be?
  • Where should the history table be?
  • How does the user complete the workflow most efficiently?
For the electricity project, our main question is how the user will interact with the order form as that represents the main task. We discussed a few options in this context. We went back to the task analysis and compared it to the proposed workflow. The main task is to order electricity and the reason for the “create” button in the proposed concept is rather mysterious. It seems to serve no obvious purpose and adds an extra step to the user’s workflow. It seems rather inefficient and not obviously necessary.
We decided that the “create” button needs to go and that we would just show the user the order form when they land on this page. The workflow now seems optimal as there are no more unnecessary steps. In the end, our users should perform only the steps we outlined in the task analysis.
The historical items table should be below because downloading the invoice for previous purchases is not the main action but a secondary one.
The navigation on browsers to go back is the top left of the screen as this is a web standard. Users will probably be able to find the back button there because this is commonly where they look for a way to go back.
We drew up a screen to illustrate the flow without “create”. Here the users can create an order straight away and without having to perform any further actions. Users will probably be happy because they can do what they came to this screen to do without delay.

Make wireframes to communicate your design or just to document it

Screens are visual things and when we talk about visual things using words, we will translate them into pictures in our heads. Each person commonly imagines a different picture and it is hence useful to draw up a picture you may have in your head to communicate it more effectively. Here is a great book on communicating your thoughts visually.
In this step, details matter - a lot - and there are a number of rules you can use to get this right. In this process, contemplate
  • Page hierarchy and basic layout (title, call to action, workspace)
  • Terminology (text, titles, buttons); use user terms
  • Visual language (size, colour and style of items to bring them to the front or keep them back)
  • Main task execution workflow (steps the user will perform)
A wireframe is only created to communicate a concept. You should try to do this in the quickest and cheapest way possible. By the time you get to this step, you should have some paper drawings at the very least. If those are already enough, then you may not need to perform this step at all. For larger projects, it is not uncommon to create a series of wireframes for one screen with each one showing a screen transition or user interaction.
Tools you can use
  • Paper or whiteboard (cheap and easy to change)
  • Wireframing tools (less cheap and harder to change)
  • Graphic design tools (such as Photoshop, Gimp; expensive and hard to change)
For our electricity project, we used the paper designs to explain to each other what we mean. We did not need anything more complex. We then created neat wireframes to communicate the concept to the stakeholders and development team.

Step 3: Test
The proof is in the pudding. Everything we did up to now has been pure speculation. We assumed we understood the tasks and subtasks well, we created – what we think – is a good workflow and translated that workflow into an interface. We debated and discussed the screen and optimised it, but we have no proof as yet that our assumptions were correct. So, we need to verify our assumptions by performing some simple tests. You do not need to test with many people to get a lot of benefit out of testing.

There is a formula to calculate the return on your test participants. It shows that as few as three users will find about 70% of all usability issues. Any more than five people for one test and you are starting to waste your time. This chart highlights that any kind of testing is thus much better than no testing at all! Even just one user will reveal a quarter of your usability problems to you. Start with one user to get an idea of the task, its’ return and the benefit of a better UI.
What to test and how to do it
In order to test your concept you can just chat to a colleague and show your design to them. You show it to them, but don't explain it at all. If you need to, you can explain the tasks to them but nothing on the UI.
Then ask them to perform the main and the subtasks using the UI and see if they understand the screen and know what they need to do on it. Hand them the wireframe and ask them to identify and explain all elements on the screen. See if they understand why something is there and how it would be used. If you have to explain a term or button on that screen, you probably have not got the right terminology yet.
Compare the user you are testing to the persona. The more differences there are, the less accurate your test result is likely to be. You do not need to have a prototype to find out if there is something wrong with the basics of your UI. You can perform user testing with paper drawings only.
Test
  • Page hierarchy (title, call to action, workspace)
  • Terminology (text, titles, buttons)
  • Main task execution workflow
  • What users expect to happen when they interact with the page elements
We reviewed the design for our electricity project when it was done, revisiting the user tasks one more time and decided that there is not much else of importance to consider. We think we are done for now.
The next step is to build the screen and then to test it. We could do a prototype, but the screen elements are easy to move around and so we will just build it now and just test the completed screen. This project is not worth any more effort right now.

Conclusions
Design is inevitable. You cannot skip design. The alternative to good design is bad design, not no design at all. Since you will design, it makes sense to use methods that will improve your ability to do so.
UX methods are flexible and can be moulded to the needs and constraints of specific projects. There is lots of benefit in using UX methods on projects. Doing any of the UX activities described in this article in any shape of form is better than doing none of them.
So, start using any or, better still, all of these methods to improve your designs today!

Happy designing…

Tuesday, January 15, 2013

Search Engines and the default operator AND

There are many features that make Google useful. One important reason is that the results match the request… intuitively. 

Imagine this scenario …

I want to find out what Google knows about my trance music...

I search for Franz … just Franz is too wide and I get lots of stuff about other Franz’es, so I add a term...


Franz Rodenacker - that's better, but there are still too many search results to consider, let me narrow it further


Franz Rodenacker Trance - there we go, everything related to me and my trance music. If we go to the last page we can see that there are no search results for Franz or Rodenacker or Trance, but only Franz AND Rodenacker AND Trance. 


Imagine the results if the default operator was an OR

Franz OR Rodenacker OR Trance

My search results will not get narrower when I add terms if I get an OR by default. I will then widen my search results with every word I add to the search, which is deeply counter intuitive. When I add another term to the search, I am saying "This term also applies" and I am not saying "this term is interchangeable with the other terms".  I hence want:

Franz AND Rodenacker AND Trance

So what? What does this mean? 

Searches engines should implement an AND as the default operator to be intuitive -
unless they represent an exception and have a very good reason not to.

Franz