Purpose: The person’s goals and desires. Context: The environment and situation that The person is in.

If you change the user, the interface changes. If you change the purpose, the interface changes. If you change the context, the interface changes.

Starting Scenario

User: A qualified driver Purpose: Go from point A to point B Context: Over land Interface: Car

Change The User

User: A licensed pilot Purpose: Go from point A to point B Context: Over land Interface: Plane

Change The Purpose

User: A qualified driver Purpose: Go from point A to point C Context: Over land Interface: Bicycle

Change The Context

Change the context.

User: A qualified driver Purpose: Go from point A to point B Context: Over water Interface: Boat

How To Use

Apply this model before starting on interface sketches, Wireframes or prototypes. It’s OK if It’s initially wrong and you start with prototypes… … as long as you verify your assumptions with research.

If you’re simply telling a story of the sketches, wireframes or prototype, use this model as your introduction before revealing them to people. It primes everyone. It creates common ground. Wondrous things will happen. It’s a framework to tell a product story. Again, though, be sure to have a disclaimer that it needs to be tested and verified against research.

Guerrilla testing is better than none.

Why Use It?

  • To keep it simple. To focus.
  • To more easily spot assumptions that would destroy the product.
  • To ensure the core of the product stays true to 80% of the people that will use it.
  • To keep people, and yourself, focused on the core of the product or page.
  • To prevent feature creep.
  • To more easily communicate the intentions of an interface (product).
  • To communicate your design decisions effectively, with confidence, and without overhead.
  • To expand your design/UX arsenal.
  • To help give design equal respect among business and technology requirements.
  • To provide and create a common language that builds common ground towards a shared vision.
  • To avoid over-complicated models that aren’t realistic when working on multidisciplinary teams in tight timelines or rapid development cycles.
  • To keep you humble.

When To Use It

  • When you want to try something new.
  • When you recognize not everyone is on the same page.
  • When you want to build a story to introduce new design concepts.
  • When you’ve exhausted everything else to prevent feature creep.
  • When you’re working with people who are very attached to the existing, standard way of doing things.
  • Buttons on the left or at least for people to understand right?)