Studio Matrx Monthly · Volume 1 · Issue 1 · June 2026
Amogh N P
 In loving memory of Amogh N P — Architect · Designer · Visionary 
The Point-of-View statementLesson 2.1
Design Thinking/Module 2 · Define — framing the right problem

Lesson 2.1

The Point-of-View statement

Turning a deeply understood person into one sharp, solvable problem

6 min Lesson 10 of 32
The hook
Two designers understand Lakshmi completely. Designer A writes 'design a good 2BHK for the family' — it points nowhere. Designer B writes 'Lakshmi, a visiting mother, needs a dignified space of her own in a home that isn't hers — because she'd rather belong than ask and risk being a burden' — a loaded spring that fires off ideas against your will. The difference between those sentences is this lesson.

The most dangerous gap

Understanding a person is not the same as having a problem to solve. There's a gap between insight and action, and the Define mode bridges it. Define is the first hard convergence: squeeze everything into a single sharp statement of the problem worth solving. The tool is the Point-of-View (POV) statement — and writing it well is half of designing well.

The anatomy: [user] needs [need] because [insight]

The user is specific (from your persona) — 'Lakshmi, a visiting mother' beats 'an elderly user' beats 'the family.' The need is a verb, a goal, never a solution — 'needs a prayer corner' is a solution in disguise; the real need is 'to worship with dignity and privacy,' which opens many answers. The needs come from the gaps in your empathy map. The insight is the surprising, emotional why — the deep driver from the iceberg — 'because she'd rather belong than ask and risk being a burden.' A POV without a real insight is just a task; with one it's a problem you want to solve.

Watch a POV get fixed

First attempt: 'Lakshmi needs a prayer corner because she likes to pray' — the need is a solution, the insight flat. Second: 'Lakshmi needs to worship with dignity and privacy because she likes to pray' — better need, flat insight. Third: 'Lakshmi, a visiting mother, needs to worship with dignity and privacy in a home that isn't hers — because she'd rather feel she belongs than ask for anything and risk being a burden.' Now it's a loaded spring.

Why a sharp POV is a loaded spring

A well-framed POV generates solutions because it contains the shape of its own answers, all serving the same insight ('belong without asking'): a permanent prayer nook (never has to ask), supportive seating (never has to ask for help rising), a space that's hers by default, a kitchen for two. The test of a good POV: does it generate ideas, or just sit there? A vague POV is a dead spring.

Framing beats talent

How you frame a problem determines which solutions you can even see. A brilliant designer working from a badly framed problem produces a brilliant solution to the wrong problem. The POV is how you take control of the frame deliberately, instead of letting the client's casual words frame it by accident.

[user]specific, from personaneeds [need]a verb / goal, never a solutionbecause [insight]the surprising emotional why a POV without a real insight is just a task; with one it's a problem you want to solve
The anatomy of a Point-of-View statement: a specific user, a need as a verb, an insight as the surprising emotional why.
[user]specific, from personaneeds [need]a verb / goal, never a solutionbecause [insight]the surprising emotional why a POV without a real insight is just a task; with one it's a problem you want to solve
The anatomy of a Point-of-View statement: a specific user, a need as a verb, an insight as the surprising emotional why.
Go deeper — for practitioners & students

Test your need against the why/how ladder: if 'why?' climbs to something more fundamental, you were too solution-y; if 'how?' descends to something concrete, you were too vague. The sweet spot is a real goal still spatial enough to design toward. A project has multiple POVs that conflict — name the conflict rather than suppressing it; the collision between two well-framed POVs is your richest problem. And beware the seductive, premature POV — it's a hypothesis, not a verdict, revisable when prototype or test reveals you framed the wrong problem.

Try it

1. Take your overlooked inhabitant's persona and the gap you circled in 1.5. Write a first-draft POV: [user] needs [need] because [insight]. Audit in three passes — is the user specific? is the need a verb/goal not a solution? is the insight surprising and emotional? Then test the spring: write three different design ideas it fires off. Can't get three? Reframe until it generates.

Check yourself

3 quick questions — pick an answer to see why.

Q1What is the correct anatomy of a Point-of-View statement?

Q2Why is 'Lakshmi needs a prayer corner' a weak need for a POV?

Q3What is the practical test of a well-framed POV?

Key terms

Point-of-View (POV) statement
The Define-mode tool that squeezes a deeply understood person into one sharp, solvable problem using the form [user] needs [need] because [insight].
Insight
The surprising, emotional 'why' behind a need — the deep driver that turns a task into a problem worth solving.
Loaded spring
A well-framed POV that contains the shape of its own answers and fires off multiple solutions all serving the same insight.
Recap
Understanding a person isn't yet a problem to solve — the POV statement bridges the gap, the first hard convergence. Its anatomy is [user] needs [need] because [insight]: a specific user, a need as a verb (never a solution), an insight as the surprising emotional why. A sharp POV is a loaded spring that fires off solutions, all serving the same insight. Framing beats talent — and the POV is a revisable hypothesis.
Carry forward →

A statement, however sharp, is still closed. How do you turn that problem into an open invitation — a question phrased so it pulls ideas out of you? And what do you do when two POVs collide?