ah teaches interface design (When We Fail lecture)
When We Fail
Lecture outline
Dealing with the reality of when we fail... because we will at some point fail. Lecture slides will be made available on the day of the lecture (July 10).
Critique prep
Please come and sign-up for a timeslot for critique. I will briefly cover alternative activities you can partake in during critique time at 9:45, after which we will reconvene for lecture at 11:30.
Please make sure to have materials ready for critique when your timeslot comes up.
Activities during critiques
Activities you may complete:
- Reading reflection #6 (if you have not yet completed three reflections)
- Teamwork reflection (part of your project grade)
- Work with your teammates on the project
A brief lecture
Going to give you some things to think about with testing interfaces (beyond usability) and dealing with failure.
Helping Users
Remember to consider:
- What is the first thing they may do?
- What do they need to figure out?
- Are things discoverable?
Planning testing
While we have covered the pieces of testing your interface with others, we have not yet put them together. As part of P4 you will be testing your interface with someone outside the course.
Things to consider:
- What are you testing
- Stay neutral
- Selecting participants
- Feedback methods
What are you testing?
Consider what you want your testing to help you understand:
- The interface's purpose
- The interaction design
- The structure and flow
- A specific feature or functionality
Staying neutral
Your job as part of a user test session is to get feedback. Do not try to sell them on your product.
Selecting participants
Early in the prototyping process (low-fidelity), picking a more likely user is reasonable.
Once the prototype is higher fidelity picking more extreme users — people who would use the interface heavily or would be unlikely to use it all — can be useful.
Feedback methods
Depending on what you are testing your methods may differ. Regardless of what methods you use aim to keep tasks and questions grounded in 'real' scenarios as much as possible.
Feedback methods
(Continued)
For example, if building an embedded fridge interface and you want to understand how users ask it to purchase a product:
- Do not ask them to 'buy milk' as a task.
- Do tell them that they just realized they have run out of milk and they need to buy more to make a cake for a friend's birthday.
Next week's testing
During critiques next week you will be testing your interface prototypes with peers. Make sure to bring a functioning prototype.
Usability failures
Where the quality of design is rendering the application unusable or unreliable for its users. This often appears as a mistake as the user does not know what to do. For example:
- Clicking on a magnifying glass and expecting to search, but instead the view is zoomed in.
- Searching for store hours in the contact information, when they are in the about section.
Failure is subjective
And that's okay
As it is the experience and utility that tends to drive users to continue using application, the subjective view of 'what is a failure' is something we need to accept.
Phases of interaction
Keep in mind that as a user engages with an interface, different errors are more likely at different points:
- Read/scan phase: Perceptual errors are more likely; i.e. mis-interpreting interactive elements.
- Thinking phase: Cognitive errors are more likely; i.e. evaluating options or making decisions.
- Response phase: Motor errors are more likely; i.e. username/password entry.
Attention is selective
Generally we can only deal with one message or situation requiring our attention at a time, effectively.
Building prototypes
Please do not forget what we have covered this far. Aim to have a prototype that enables us to move through at least two key features for next week's class.