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.
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.
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)
You can use things like standard screen layouts, Fitts Law, Gestalt principles or any of the many articles on screen design and layout.
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!