IAT-334: 10 When We Fail

Quiz Rules

  1. You will have only thirty minutes to complete the quiz. Keep an eye on the time due, as late submissions receive a zero.
  2. This quiz is open book, meaning you can draw on online resources as much as you would like. Please remember that if you cannot access a reading because everyone else did so before you, there is nothing we can do. Please refer to your notes.
  3. Any words that are not your own must be cited using a proper format — for example (Author, 2000). Any plagiarism will result in a grade of zero. No exceptions.
  4. Any talking, texting, messaging, paging, or secret-tiny bluetooth resulting in communications with friends or classmates will result in a grade of zero. No exceptions. Facebook can wait.
  5. Please answer any questions in full sentences.

Quiz time

The secret password is . You have 30 minutes.

Close laptops please

P03 Schedule

Mar 13: Prototyping week for generating high-fidelity, interactive prototypes of your application.

Mar 20: Testing week for finding flaws and improving your prototype.

Mar 27: Refinement and final presentation development week. (Worth 20%)

Functional failures...
...the user has no clue.
Why might this prompt be problematic?

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:

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. Let's take a look at an example of attention and focus.

What is being asked here?

Check Yourself

(Before You Wreck Yourself)

As an interviewer you want to avoid bringing your own biases and opinions, as this can influence how the interviewee responds.

Check Yourself After

There are some common traps that we can fall into when we fear a potential failure:

Asking for Permission

It is important that your interviewee understand the why and what you are doing. This ensures that they can safely agree to participate in what you are doing.

Permission Requirements

Before interviewing your users, you need to make sure that they understand:

Gathering Data

This week you will be collecting data on how your app works or does not work. Remember the following:

Users are Biased

Also remember that those testing your application are bringing their own views and experiences into testing. This may change how they perceive or interact with the application:

Any questions?

UI Sketchbook

Sketch #10

The interactive systems you are designing will have to be prepared to deal with system failure at some point. Your sketching task this week is to come up with 5 different approaches to responding to one error. The sketches should clearly demonstrate:

In This Week's Labs...

We will testing your prototypes. Please make sure to have your prototypes ready to go when you arrive, as we will need to move through and provide feedback relatively quickly.

In Next Week's Lecture...

An in-class opportunity for feedback on your prototypes as well as 'where to go' from here.

Please bring in your prototypes to next week's lecture.

Contacting Andrew