Design Considerations
Requirements Gathering
Envisionment Methods
Evaluation
Other
Users of this site also found these sites useful
Think Aloud Protocol
What is Think Aloud?
During the course of a usability test, the test users are asked to verbalize
their thoughts, feelings, and opinions while interacting with the system.
It is very useful in capturing a wide range of cognitive activities. Two
variations of thinking-aloud protocol technique are:
- Critical response - This requires the user to be vocal only during the
execution of certain predetermined subtasks.
- Periodic report - This is used when the task is complex and makes it
difficult for users to think aloud while performing the task at the same
time. The user, therefore, verbalizes at predetermined intervals of time
and describes what he/she is currently trying to achieve. The length of
the interval depends upon the complexity of the task. This technique is
very time consuming, so it is recommended for subdivisions of a task.
Why Use it?
Thinking aloud allows testers to understand how the user approaches the
interface and what considerations the user keeps in mind when using the
interface. If the user expresses that the sequence of steps dictated by
the product to accomplish their task goal is different from what they expected,
perhaps the interface is convoluted.
The terminology the user uses to express an idea or function should be
incorporated into the product design or at least its documentation.
Participants Needed
Experts
One usability expert is required for the exercise.
Users
A minimum of 4 users should be observed - the more users that can be observed,
the better the results. Different Users will have different problems. After
6 users, the cost-benefit ratio is reversed.
Task List
- Describe the interface being presented
- Give users informed
consent form (.doc) / informed
consent form (.rtf)
- Explain goals of the session
- Explicitly mention in-room observers and/or videotaping
- Explain that you are testing the interface not them
- Reassure users about what will happen if they encounter difficulties
- Explain that the design will evolve from the current version
- Explain that you will record their suggestions but don’t promise
to implement them
- Explain how to interact with the prototype
- Discuss thinking aloud and asking questions
- Confirm ending time and reassure them that they can take a break at
any time
- Clarify tasks if confusing
- Have user sign informed
consent form (.doc) / informed
consent form (.rtf)
For every task complete the following list:
- Task number & name - Give each task a brief descriptive
name and number.
- Goal/Output - What will users have accomplished when
they have finished the task? How will they know the task is complete?
- Inputs - List all the information or resources a
user might need (tangible or intangible) to complete the task. Examples
include valid login, business policies, text book, credit card, file names
etc. All these need to be available to the user during the usability test.
- Assumptions - Conditions and prerequisites that are
in place at the start of the task. Example – a database with a built
in error to see how the user handles it.
- Steps - Write down the steps you expect the user to
go through, while completing the task. Example – Open order form.
Fill out form. Submit form. Be sure to include choices. Example –
Search OR Navigate
- Time for Expert - Ignore time taken by system to process.
Focus on time spent entering data and clicking buttons. Some tasks require
time for creative effort so allow time for that. Use this estimate to
help you decide how many tasks will fill your allocated time. Multiply
by a factor of at least 3.
- Instructions for User - May be basic or complex depending
on task.
- Notes - Why you created the task. How you’ll
conduct it. Specific things to watch for. Questions to ask users after
task is complete.
Conditions required
- Stay for the entire test - The goal is to make the
users forget that anyone else is in the room. While you are observing
the test you are not available for any interruption short of an emergency.
Turn off mobile phones!!
- Remain silent while the users are working - You may
notice a problem so surprising that you are tempted to laugh or exclaim
out loud. This is not unusual. Unfortunately the users will think you
are laughing at them. Please do your best to keep quiet. There will be
opportunities to ask questions after each task and at the end of the test.
- Be conscious of your body language - Sit quietly without
fidgeting. Keep busy taking notes. If you feel you understand the issue,
have the user end the task and begin the next.
- Don’t reveal how many tasks you have - It is
often more useful to explore an area of difficulty, rather than trying
to get through all the tasks. Users may rush one task if they feel they
are spending too much time on others.
- No helping - Instead try to understand why the user
got stuck or went down the wrong path.
- Avoid ‘design’ questions - These can take
up a lot of time and provide limited results. Focus on trying to understand
the problem. Come up with solution later with your design team.
- Respect participants and the confidentiality of their data
- Use the assigned participant number when referring to a particular user.
Don’t include names on reports or emails. Do not make negative comments
on people. There is always a chance that a derogatory comment may be overheard
or otherwise make its way back to the user.
Limitations Of method
Reading