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:

P4: Interface Design
Sketching exercise

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:

An overlay explaining how the user is meant to move through the application

Will our users remember this?

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?

Consider what you want your testing to help you understand:

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:

Next week's testing

During critiques next week you will be testing your interface prototypes with peers. Make sure to bring a functioning prototype.

The Windows XP 'blue screen of death' with a cryptic error displayed
A modal window indicating that something went wrong with the transaction and that the user should try to repeat the process

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:

A credit card input in a checkout process with large red text at the top indicating they have put in the wrong information

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:

  1. Read/scan phase: Perceptual errors are more likely; i.e. mis-interpreting interactive elements.
  2. Thinking phase: Cognitive errors are more likely; i.e. evaluating options or making decisions.
  3. 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.

1/1