How to Start by Understanding a Person or a Group of (Be Creative)

Design Thinking

Published October 06, 2025By MetalHatsCats Team

Quick Overview

Start by understanding a person or a group of.., then brainstorm and prototype ideas, and refine them based on feedback.

At 8:12 a.m., we stood at the office kettle waiting for water to boil. A small thing, but it gave us a chance to ask a teammate one gentle question about last week’s launch: “When did you feel friction?” She paused, looked down at her cup, and said, “Honestly? When I had to guess what people wanted from that first screen.” That moment set our plan for the day. We would not solve anything clever yet. We would start by understanding a person—one person, or a small group—before we created anything else. That is the habit: begin by seeing, hearing, and measuring what life is like for someone specific, then brainstorm, prototype, and refine from their feedback.

At MetalHatsCats, we investigate and collect practical knowledge to help you. We share it for free, we educate, and we provide tools to apply it. Use the Brali LifeOS app for this hack. It's where tasks, check‑ins, and your journal live. App link: https://metalhatscats.com/life-os/design-thinking-playbook

Background snapshot: This hack sits inside human‑centered design and ethnographic research—disciplines that ask us to observe real behaviors and listen for patterns before we design. The most common trap is to ask leading questions and then rush to build the thing we already wanted to build. Another trap is to collect a mountain of notes without a decision rule, causing analysis paralysis. Outcomes change when we define one person or one group clearly, design short contact moments (5–20 minutes), and convert what we hear into testable prototypes within 24–72 hours. Research suggests that testing with five people can reveal about 80% of usability issues; small, iterative loops beat big, infrequent studies. And when feedback connects directly to visible design changes, trust and participation rise, while rework drops.

We will keep this habit small today: in under one hour, we can plan and run two to three contact moments, capture five to ten observations, pull two sharp quotes, decide on one change, and draft a tiny prototype (paper, slide, or quick screen). We will also set up Brali LifeOS check‑ins so the habit survives busy weeks.

Use the Brali LifeOS app for this hack. It's where tasks, check‑ins, and your journal live. App link: https://metalhatscats.com/life-os/design-thinking-playbook

Why this matters today

We often feel the pressure to be original. But originality that ignores reality becomes fragile; it looks good in our head and fails in someone else’s hands. Understanding a person or a group first is not a ritual of politeness; it is the cheapest form of quality control. If we spend 30 minutes seeing actual behavior, we save hours of rework and unbuild. If we collect three sharp constraints, we design five times faster because our options narrow to what matters.

We will work like this:

Choose a person or group (name them, write a sentence).
Plan three contact points (total 20–40 minutes).
Collect observations and quotes (count them).
Synthesize two tensions into one “How might we…?” question.
Brainstorm 10 ideas in 10 minutes.
Pick one idea, prototype it in 15 minutes.
Share and refine based on feedback within the same day.

After the list, we return to the kitchen scene. We decided to start with the teammate who felt friction, then ask two customers and one stakeholder. That felt doable before lunch. We blocked 45 minutes on the calendar and told ourselves: no slides, no pitch. Just questions, artifacts, and listening.

Defining the person or group: the smallest sharp target We resisted the urge to write “users” or “team.” Instead, we wrote a specific sentence in our journal: “Today we seek to understand Ana, a first‑time coordinator who plans daily shifts for 8–12 contractors using her phone on a noisy bus.” Sharp targets unlock sharp decisions. If we had instead written, “people who plan schedules,” we would have invented features for edge cases we would not even meet today.

We set ground rules:

Contact time: 30–40 minutes total.
Evidence: 8 observations + 2 quotes minimum.
Bias guardrails: ask “When did that happen last?” and “Can you show me?” instead of “Would you use…?”
Decision rule: ship one prototype change in 24 hours.

When constraints are explicit, our attention loosens. We stop chasing the perfect interview and start collecting enough signal to make a real change.

Designing the contact moments (micro‑scenes)
We planned three micro‑scenes:

Bus‑simulated environment (7 minutes): We asked Ana to show us how she schedules on her phone while standing, with one hand, and with ambient noise. We observed thumb reach, error rates, and where her eyes moved first.
Two‑person call (12 minutes): We spoke with a second coordinator, Jamal, and a skeptical stakeholder who approves budget. We let them interrupt each other, which reveals friction (“He always sends me three versions!”). We captured exact phrases.
Silent observation of one daily check‑in (8–10 minutes): We watched a Slack stand‑up to see what is actually shared versus what is assumed. We noted time stamps, delays, and message patterns (e.g., emoji used to acknowledge tasks).

We set a timer for each, and we decided on exact captures: a photo of thumb reach on the phone (with consent), a count of taps to complete one scheduling block, and a screenshot of the most common message format (blurred names).

We assumed X → observed Y → changed to Z We assumed Ana’s biggest pain was “finding the right contractor quickly.” We observed her pausing, not at search, but at “confirming time windows fit the bus route delays.” We changed to a prototype that pulled route delay data into the scheduling view and allowed “fit window” filters before search. The pivot was immediate and specific, not abstract. Without that observation, we would have optimized search—and missed the real constraint.

How to ask without leading: three question frames We wrote our prompts on a sticky note we kept at the edge of the frame:

“Walk me through the last time you did this, step by step.” (Timeline)
“What made that step easy? What made it hard?” (Contrast)
“If this disappeared tomorrow, what would you miss? What wouldn’t you miss?” (Value test)

We avoided “Would you use X?” because it invites imagination, not behavior. When people answer from memory and artifact (screens, receipts, messages), we get fewer fantasies and more data we can design with.

Quantifying understanding: what to measure today Understanding can be counted. Today we tracked:

Minutes of direct contact: target 30 minutes.
Distinct observations: target 8–12.
Quotes with exact wording: target 2–4.
Measurable friction: taps, time, corrections (e.g., 17 taps, 2 backspaces).
Change we can ship in 24 hours: 1.

We also set a ceiling: we would not exceed 60 minutes of research before prototyping. Attention fades; diminishing returns arrive sooner than we like. Studies on usability show that after five participants, we capture most major usability issues; beyond that, we find smaller gains. The point is to loop, not to exhaust every angle in one pass.

A quick setup scene: consent, context, clarity At 9:20 a.m., we sent a message: “We’re trying to understand how scheduling goes for you—small things, not policy. Can we watch your next 10 minutes and ask two questions? We’ll anonymize details. If anything feels off, say stop.” Ana replied with a thumbs‑up. We stored the message in our journal as proof of consent and a template for next time.

We prepared props: a paper version of our current screen, a marker to draw on it in the moment, and a timer. Sometimes paper is faster than code, and watching someone draw exposes mental models cleanly. We also cleared a 15‑minute block right after the sessions for synthesis. If we do not synthesize while the details are fresh, the texture of the quotes fades and we start inventing patterns that fit our hopes.

Synthesis in 15 minutes: turning noise into a “How might we” We dumped our notes into four boxes on one page:

Goals (what the person is trying to achieve).
Constraints (what stops progress, with numbers).
Workarounds (what they already do to cope).
Quotes (exact words with initials).

Example notes:

Goal: “Confirm today’s shifts by 9:45 a.m.”
Constraint: Bus delays are posted at 9:05–9:15; schedule needs lock by 9:30; 17 taps required to adjust windows; one‑hand use common.
Workaround: She sends a voice note to herself to remember which route is chronically late.
Quotes: “I can do this fast, but I don’t trust it.”

We then wrote one tension statement: “Speed versus trust.” And one “How might we…”: “How might we reduce taps and increase trust—especially for one‑handed use in noisy conditions—by 9:30 a.m.?” Constraints sharpen creativity.

10 ideas in 10 minutes: a sprint, not a slog We set a visible timer and wrote fast, one idea per line:

Route delay overlay with green/yellow/red fit windows.
One‑hand thumb‑zone redesign for primary actions.
“Auto‑fit” button that proposes the top three viable shifts.
Quick voice input: “Fit Jamal to Route 3, 9–11.”
Confirmation strip that shows “confidence” based on delay data.
Two‑tap undo for last action (trust anchor).
Default filter: “only show contractors available for 9–11 with bus delay <5 min.”
Sticky “last three changes” at bottom for rapid review.
Haptic feedback on confirmation (for noisy environments).
End‑of‑flow summary with anomalies highlighted.

We circled three that matched our constraints and what we observed Ana doing. We crossed off voice input for now; noisy bus conditions make voice recognition unreliable. We moved the “auto‑fit” and “thumb‑zone redesign” to the top. We stuck “undo” to the side as a trust lever.

Prototype in 15 minutes: what “good enough” looks like We drew five frames on paper:

Frame 1: Filter panel with pre‑loaded “fit window,” toggled by bus delay thresholds (<5 min, 5–10, >10).
Frame 2: List view with only eligible contractors, large tap targets in the lower third of the screen.
Frame 3: “Auto‑fit” suggestion tray with three options and small confidence badges (e.g., 82%).
Frame 4: Confirmation with summary line and a two‑tap undo.
Frame 5: Anomaly banner: “Route 3 delay increased by 12 min; shift fit risk now 68%.”

We used thick markers to avoid getting lost in pixel details. We colored tap zones with highlighter. We practiced the flow once with our own phone in one hand to feel the reach.

Immediate feedback loop: back to Ana We sent photos to Ana with a quick prompt: “If this is your screen in tomorrow’s rush, what is the first thing you’d try? What would you avoid? Anything confusing?” She replied in 9 minutes: “I’d tap ‘auto‑fit’ but I’d want to see why. Confidence helpful. Undo is essential.” A specific note, not a vague “looks good.”

We refined one detail: we added a small “Why?” expander that shows the two main factors behind each confidence score (e.g., historical delay variance + current report). We stopped there. We protected momentum.

Mini‑App Nudge: In Brali, add a 3‑day “Understand First” streak with one task: “Collect 8 observations + 2 quotes before ideating.” A single checkbox each day keeps us honest.

What if the person or group is different? Perhaps we do not design software. Maybe we plan a volunteer day for a neighborhood group, or we write a policy memo for a school board, or we pitch an internal process change. The mechanics stay: name the person or group, collect specific moments, and test the smallest useful change.

Three scenes outside tech:

Neighborhood group: We observed a Saturday cleanup sign‑up table. We counted wait times (3–9 minutes), watched pen hand‑offs, and noted where people hesitated. We learned that the real bottleneck was not choice—it was privacy. People did not want to write their phone number where others could see it. We prototyped a tear‑off slip and a drop box. Sign‑ups increased by 27% in two Saturdays.
Policy memo: We called a school treasurer for 12 minutes. We asked, “When do you feel rushed during monthly reconciliation?” The treasurer said, “When receipts come in on paper clips with sticky notes and I have to retype vendor names.” We prototyped a one‑page cover sheet with three typed lines and a QR for photos. Adoption reached 60% of submissions in three weeks.
Internal process: We shadowed a remote stand‑up. We timed how long it took to find decisions in the chat (an average of 4 minutes, 12 seconds). We tested a “Decisions” tag with an emoji and a weekly digest. Search time dropped to under a minute by week two.

These scenes differ in substance, not in method. We observe, count, quote, hypothesize, and change something small within a day.

Misconceptions we should retire

“We need a statistically significant sample before we can act.” For qualitative design changes, we need saturated themes, not p‑values. Five participants often surface most major usability issues; two or three targeted observations can reveal pattern‑level constraints.
“People do not know what they want, so why ask?” People show what they do, and they can name pain. We are not asking them to design; we are asking them to reveal constraints and values. Our job is to translate.
“We must be neutral robots.” We can be warm and still avoid leading. We show care by protecting time, clarifying consent, and sharing how feedback changed something.

Edge cases, risks, and limits

Power dynamics: If our subject reports to us, they may tell us what we want to hear. We can mitigate by asking for artifacts (“Show me the last three messages you sent”) and by inviting a neutral observer. Anonymize quotes when we share.
Privacy: Blur names in screenshots, store notes in a restricted folder, and get explicit consent for recording. With minors or sensitive contexts, avoid recording altogether and rely on notes.
Loud voices: Strong opinions can skew our path. Cap any one participant’s weight by committing to at least two other sources before locking a change.
Overfitting: Designing for one person too tightly can hurt the group. We keep constraints general (one‑handed use, noisy environments) and test variants with a second person.
Remote constraints: If we cannot observe in person, ask for screen recordings or a 3‑minute “show me” video. If that fails, use a guided recall: “Open your last sent message; what were you trying to achieve?”
Safety: In public or physical contexts (workshops, streets), do not compromise safety for observation. If a scene is risky, reconstruct with props elsewhere.

The quiet power of artifacts

We learned to ask for “the last thing you used.” In one project, a volunteer coordinator showed us a wrinkled paper with circles and arrows. That artifact said more than ten interviews: the circles were people, arrows were “no‑go” pairs. It was a constraint map. We snapped a photo, traced the logic, and prototyped a pairing view that respected those rules. The double win: the coordinator felt seen, and we stopped guessing.

Sample Day Tally: reach today’s target Target: 30 minutes of contact, 8–12 distinct observations, 2–4 exact quotes, 1 prototype change.

5‑minute intercept with Ana on her bus break: 3 observations (one‑hand use, pause on delays, 17 taps), 1 quote.
12‑minute two‑person call: 5 observations (approval timing, “three versions” complaint, delays posting at 9:05–9:15, mistrust of fast changes, preference for undo), 2 quotes.
8‑minute stand‑up observation: 3 observations (emoji acknowledge pattern, 4‑minute delay to confirm decisions, confusion over route updates), 1 quote.
5‑minute paper prototype feedback: 2 observations (auto‑fit acceptance, desire for “why”), 1 quote.

Totals: 30 minutes contact, 13 observations, 4 quotes, 1 prototype change drafted.

If we can only spare 5 minutes today

Busy‑day path (≤5 minutes):

Ping one person: “What’s the last step in [task] that felt clumsy? Send me a screenshot or describe in one sentence.”
Log 2 observations and 1 quote in Brali.
Sketch one small change on paper (2 frames). Share a photo with: “Would this remove the clumsy step?”

This keeps the streak alive and builds a small library of constraints for a deeper session later.

Integrating Brali LifeOS: tasks, check‑ins, journal We opened the Brali LifeOS app and created a micro‑project called “Understand First: Scheduling.” Three tasks:

Plan contact moments (due today, 10 minutes).
Run sessions and log counts (due today, 30 minutes).
Draft and share prototype (due today, 15 minutes).

We added two check‑ins:

Daily: “Minutes of contact,” “Observation count,” “One quote captured?”
Weekly: “How many iterations shipped?” “Did we act within 24 hours?” “Which constraint repeated?”

We created a journal template with four boxes (Goals, Constraints, Workarounds, Quotes)
and a fifth for “Pivot notes”: “We assumed X → observed Y → changed to Z.” This keeps our thinking grounded and visible to future us.

How we keep emotional tone steady

Understanding someone else’s world can stir feelings. We may feel relief when we spot a simple fix. We may feel frustration when a cherished idea collides with a fact. We let that emotion inform but not dominate. If we feel defensive, we return to the artifacts. If we feel triumphant, we still ask for one more quote. And if we feel stuck, we reduce scope: one person, one scene, one change.

Time boxing and energy management

We gave ourselves strict boxes today:

10 minutes planning.
30 minutes contact.
15 minutes synthesis.
15 minutes prototyping.
10 minutes feedback and tweak.

Total: 80 minutes, but we could compress to 40 by skipping the two‑person call. We kept snacks and water nearby because fatigue breeds shortcuts. We used a visible timer so we would stop while energy was still available for a small win.

What to do after day one

We log outcomes in Brali:

Observations that repeated (count).
The one change we shipped (screenshot or photo).
Feedback received (one quote).
Next loop plan (who, where, when).

We also share a one‑page “Change Note” to the group we observed: “You said X; we changed Y; we will test Z next.” This trust move is small and pays back by increasing participation. People who see their words shape a tool or process will give better feedback next time.

One explicit trade‑off we made We skipped a formal survey. A survey would have given us breadth but not the detail of a pause, a thumb reach, a sigh. We traded breadth for depth on day one, because our decisions were about flow and feel, not policy or pricing. If we later need to choose between two directions, we might run a 5‑question survey to quantify preference. Today, we needed texture.

When to stop researching and build

We stop when:

The last two observations repeat earlier ones (diminishing returns).
We can write a “How might we…” without guessing.
We can draw a prototype that directly addresses a measured constraint.
We have at least one person willing to try the change.

If we pass those thresholds, building is cheaper than more research. If we have contradiction (two people need opposite flows), we branch once and test both. Our goal is not to please everyone at once; it is to learn which path works for who, and under which conditions.

Common traps and our guardrails

Trap: Leading questions. Guardrail: always ask “last time” and “show me.”
Trap: Solving during the interview. Guardrail: write ideas in the margin, not aloud.
Trap: Over‑documenting instead of deciding. Guardrail: decision rule—one shipped change within 24 hours.
Trap: Ignoring non‑verbal cues. Guardrail: write one sentence about posture, pace, or gesture.
Trap: Collecting advice but not constraints. Guardrail: ask for obstacles and measures (taps, minutes), not feature requests.

We tested these guardrails with our own team and found that the 24‑hour shipping rule prevented drift. If a change is too big for 24 hours, we break off a visible slice (button label, default filter, chunked layout). Visibility matters; it keeps the loop honest.

A quick detour into creative technique: design by subtraction Sometimes understanding a group reveals clutter. We tried a subtraction exercise: remove one part and see what breaks. We removed the search bar from our paper prototype and forced “fit window” first. The result? Fewer taps and fewer errors because options narrowed. We would not have dared this without the constraint we heard. Creativity came from removal, not addition.

Remote adaptation when we cannot meet live

We used asynchronous prompts:

“Send a 30‑second screen recording of your next [task] with narration.”
“Reply with the last message you sent about [topic] and one sentence: what were you trying to achieve?”

We scheduled a 10‑minute window to watch these in a batch and extract observations. We used a simple counter (“Observation #1…#10”). We kept recordings for seven days and then deleted them for privacy.

How to handle disagreement inside the group we study

Groups are not monoliths. When we received opposite preferences—“Auto‑fit is magic” versus “Auto‑fit hides logic”—we split the prototype. We offered a setting: “Show steps” on by default for novices, “Suggest result” for experienced coordinators. We then tracked which setting reduced error rate (measured by number of undos per session). With 12 uses, we saw “Suggest result” led to fewer undos (average 0.7 versus 1.9). We kept both, with a gentle nudge toward “Suggest result” for repeat users.

Narrating the pivot builds trust

We wrote our pivot note in the journal: “We assumed speed was the main value → we observed that trust plus speed mattered more → we changed to an auto‑fit with transparent ‘Why?’” We shared that sentence in our ‘Change Note’. People, even busy people, want to know that their time changed our path. It also keeps us from falling in love with our first idea.

What to do when the first prototype flops

It will happen. We have shipped changes that landed with a thud. In one case, our confidence badges confused people. They assumed 82% meant a failure rate, not a probability fit. We removed the percentage and instead used “Low/Medium/High” with two factors listed (Delay variance + Availability). Flop to fix in 45 minutes because our target was narrow.

Measuring impact without heavy analytics

For light teams, we picked two numbers:

Time to complete the task (stopwatch, minutes and seconds).
Errors or corrections (count of undos or backspaces).

Baseline and after:

Before: 1:42 average to adjust a shift; 2.1 corrections.
After: 0:58 average; 0.8 corrections.

This is enough to justify the next iteration and to persuade skeptics without building a full analytics pipeline. Later, if we deploy widely, we can implement a proper event log. Today, a stopwatch is sufficient.

Closing the loop with the group

At 4:55 p.m., we sent a thank you and a screenshot of the updated paper with the “Why?” expander. We asked one more question: “If this shipped tomorrow, what would you tell a colleague about it?” The replies were short and practical. Good sign. We scheduled a second 15‑minute check‑in next week. We also printed the four boxes synthesis and pinned it near our desk. A reminder: understand first.

Check‑in Block

Daily (3 Qs):
1. How many minutes of direct contact did we have today (0, 5, 10, 20, 30+)?
2. How many distinct observations did we capture (count)?
3. Did we record at least one exact quote and one measurable constraint (yes/no)?
Weekly (3 Qs):
1. On how many days did we “understand first” before ideating (0–7)?
2. How many prototype changes did we ship within 24–72 hours (count)?
3. Which constraint repeated most often, and did we design directly for it (name + yes/no)?
Metrics to log:
- Minutes of contact per day.
- Observation count per day.
- Optional: average time to complete target task (seconds) and corrections per task (count).

Practice details for today

Choose a person or group. Write one sentence.
Plan three micro‑scenes, total 30 minutes. Set timers.
Capture 8–12 observations, 2–4 quotes, and one measurable constraint (e.g., taps, minutes).
Synthesize into one “How might we…”
Generate 10 ideas in 10 minutes. Pick one.
Prototype in 15 minutes (paper or slide).
Share and refine once. Ship one visible change within 24 hours.

All of this fits into a morning or afternoon slot. If you miss a step, log it. A missed step is data: maybe our plan was too heavy; maybe we need a 5‑minute path tomorrow.

Resources and small notes

Consent template: “We’re trying to understand [task]. Could we watch your next [10 minutes], ask two questions, and take a photo of your screen (blurred later)? If anything feels off, say stop.” Save it in Brali.
Observation counter: Create a “#Observation” tag in your journal. Count to eight.
Quote capture: Use exact words with quotation marks. One sentence is enough.

We will get better at this with two adjustments:

We will ask earlier in the day. People are less guarded before the day piles up.
We will show the change within 24 hours. Momentum beats perfection.

We end where we began: at the kettle, listening. If we start by understanding one person or group, then brainstorm and prototype, and refine based on feedback, we make fewer heroic leaps and more grounded moves. The habit is not glamorous. It is reliable. It teaches us to replace opinion with observation, to narrate our pivots, and to build the minimum change that matters right now.

Hack №72 is not a theory. It is a daily discipline we can do in under an hour, with paper, a pen, and a phone. Tomorrow, we will do it again—with a different person, a different group, and a new constraint to transform into a design.

Metric(s): minutes of contact; observation count; optional task time (seconds) and corrections (count).

First micro‑task (≤10 minutes): Message one person, ask for a 5‑minute “show me the last time you did X,” capture 2 observations + 1 quote, and sketch a 2‑frame paper prototype addressing one constraint.

Hack #72