User, Purpose, Context

Stupid simple software design communication.

User: A person.
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 assumptions…
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’s of doing things.
  • When people are arguing on details that don’t really matter to the overall user experience. (buttons on the left or right?)

Was this useful? Share or recommend if you think so!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.