Skip to main content

UX & UI Real World Vademecum

Part V: Goal-Directed Design (The Cooper Method)

How to transform research into strategy. Here we learn to distinguish what the user does from what the user wants to achieve.

Goals and Strategy​

25. Goals vs. Tasks​

The 1850 Traveler

What it does: Distinguishes the desired outcome from the actions required to get it, avoiding the optimization of processes that should be eliminated.

The Analogy: In 1850, a settler's goal was "get to California safely." Their tasks were: fix the wagon wheel, load the rifle, build a fire. Today, a businessman has the same goal: "get to California safely." But his tasks are: call Uber, pass security, buckle seatbelt.

The Tech Trap: If you focus on tasks, you'll design a lighter rifle for the settler. If you focus on goals, you'll invent the airplane. Don't digitize paper bureaucracy (e.g., making an editable PDF form). Ask: "Why are we filling out this form?". If technology can eliminate the task to achieve the goal directly, do it. The user doesn't want to "configure settings," they want the system to work.

26. Implementation Model​

The Magic Electricity Pipe

What it does: Hides database complexity behind an interface that mirrors human thought.

The Analogy: The user thinks electricity flows in the wire like water in a pipe. It is physically false (electrons don't work like that), but it is a perfect mental model for using a toaster.

The Engineer's Sin: Developers love showing the "Implementation Model." If the database has three separate tables for Customer, Order, and Address, the engineer will create three separate screens. This is logical for code, but hell for the user. Your job as a UX Engineer is to lie. Create a "Represented Model" that seems magical and simple, and then sweat bullets in the code to make that magic work. If the user needs to understand how the database works to use your app, you failed.

27. Software Postures​

Sovereign vs. Transient Programs

What it does: Defines how "heavy" and invasive the interface should be based on frequency of use.

The Analogy:

  • Sovereign: Like the artisan's workbench (e.g., Excel, VS Code, Photoshop). The user lives inside it for 8 hours.
    • Design: Neutral colors (to avoid fatigue), high information density, essential keyboard shortcuts. Don't waste space with giant borders.
  • Transient: Like the waiter bringing coffee (e.g., Calculator, Save Dialog, Weather Widget). They arrive, do one thing, leave.
    • Design: Big buttons, brighter colors, clear instructions. The user shouldn't "learn" them, they should use them and go.

The Error: If you design a factory management system (Sovereign) with the style of a landing page (lots of space, little data), the operator will go mad scrolling. If you design a confirmation popup (Transient) full of small text and options, the user will panic. Adapt density to duration of use.

Operational Method​

28. Scenarios and "Magic Thinking"​

Pretend it's Magic

What it does: Imagines the ideal interaction without current tech limits, then works backward to build it.

The Analogy: Remember the Spotify launch? Everyone was used to downloading MP3s (the task). Spotify said: "What if you clicked and music played instantly, like magic?". It seemed impossible. They worked hard on buffering to make that magic real.

The Method: Write the ideal scenario. "Mario enters the factory, the tablet already knows which shift it is and shows him only the machines he needs to check." Don't worry yet about how to do it (Bluetooth? GPS? Login?). Define the magic, then let the engineer in you find the way to build it.

29. Generation and Synthesis​

The Engine and the Steering Wheel

What it does: Structures teamwork to avoid the chaos of unproductive brainstorming.

The Analogy: A car needs an engine that pushes (Generator) and a steering wheel that directs (Synthesizer).

The Roles:

  • The Generator: Fires ideas rapidly, even stupid ones, even impossible ones. It is pure energy. If it stops, the project dies.
  • The Synthesizer: Doesn't kill ideas, connects them. Asks "Why does this work?", "How does this connect to Mario's goal?". Don't argue about who is right. Swap hats. "Now I'll be the generator for 10 minutes." The best teams are small (2-4 people) to avoid the "town hall meeting" effect where everyone talks and nothing is decided.

30. Prototyping​

Measure Twice, Cut Once

What it does: Solves design problems when they are cheap (drawing phase), not when they are expensive (dev phase).

The Analogy: Building a brick wall and then having to move it 10 centimeters is a nightmare. Moving a line on a blueprint is free.

The Critique of Extreme Agile: The mantra "release early and break things" is fine for pure software, but risky for UX. Changing an interaction flow via code is complex and introduces bugs. Use "Low Fidelity" (gray rectangles, whiteboard) to test logic. If it works there, it will work in code. Design must guide engineering, because deleting a rectangle in Figma takes 1 second, refactoring a React component takes hours.