Customer and User Obsession Questions

Direct answer

I serve both with a safe default for everyday users and progressive disclosure for power users: the common path is simple and works out of the box, and fine-grained control lives one step deeper (an "Advanced" area, a rule editor), with guardrails. I decide per control, using who needs it, how often, and how safely it can be hidden.

Decision test for each requested control

1. Is a real job blocked without it? Ask power users what they are trying to achieve, not which control they want.
2. Can the default path stay unchanged? If adding it clutters the main screen, it goes behind a deeper layer.
3. Is it safe to misconfigure? If a wrong setting can cause harm, add a preview, a confirmation, and an undo.
4. How many people need it? Check usage evidence and who the power users are (revenue, influence, advocacy), but do not let the loudest segment set the default.
5. Can a preset do the job? Presets cover most of the need without exposing every knob.

Worked example (illustrative): alert rules in a monitoring product

Everyday users get three presets: "Recommended", "Quiet" and "Everything". Power users get a rule editor behind "Advanced" with a preview of how many alerts the rule would have sent last week and an undo for edits.

Five requests: one on the main screen, three behind Advanced, one declined in favour of a safer route. Measure the share of everyday users who keep the default and whether power users complete their jobs without support.

For an AI-based product

Expose a few outcome-level choices (for example a "creative" versus "precise" mode) as the default, and keep model-level settings in an advanced layer.

Pitfalls

• Settings sprawl: every extra control is a decision for every user.
• Hiding power features so deeply that experts leave.
• Treating the loudest segment as the whole user base.
• No safety net on advanced controls.

Direct answer

A stakeholder is anyone with a say in or stake in the work, here the person pushing for the dense layout. I would neither refuse nor build it blindly. I would treat "a dense dashboard" as a solution the customer proposed and find the need behind it: which users, doing which decisions, how often. Then I would bring the stakeholder evidence rather than opinion, and propose a design that serves both the experts who want density and the novices who might drown, validated with a quick test before we commit.

Step by step

1. Clarify who asked and why. Which customers made the request, and are they the same people as the novice users I am worried about? Power users who live in the tool all day want density. New users want a clear first answer.
2. Find the decisions behind the density. Ask "what do you decide with this screen on a Monday morning?" If three questions drive most of the value, those need prominence; the other numbers can sit one click away.
3. State my concern as a testable claim. "I expect first-time users to fail at finding X on the dense layout." That is something a test can show wrong, which keeps the conversation from becoming opinion against opinion.
4. Prototype both and test with real tasks. Give representative novice users and experienced users the same two or three tasks on each version and watch where they stall. Agree in advance what would count as a pass (for example, most participants can find the key figure unaided).
5. Offer alternatives that meet the request.
   • A summary view by default with drill-down for detail (progressive disclosure: show the essentials first and reveal more on demand).
   • A density toggle or saved "expert view" for power users.
   • Role-based defaults, so each user lands on the metrics they own.
6. Decide and record. Ship what the evidence supports, and write down what you would revisit.

Worked example

An operations dashboard has 24 tiles. Asking the requesters what they check first reveals that they open it to answer three questions: is anything late, is anything failing, what changed since yesterday. I would put those three at the top, keep the other 21 tiles in an expandable detail view, and test both layouts with a few new and a few experienced users. If experienced users complete tasks equally well on both and novices only succeed on the layered one, the layered version is the clear call.

What would change my mind

If testing shows the actual users are specialists who value seeing everything at once, I would ship the dense version, possibly with better grouping and labels. The aim is the customer's outcome, not winning the argument.

Pitfalls

Arguing from taste ("clutter is bad"), testing with colleagues instead of real users, and presenting the stakeholder's request as wrong rather than as a solution worth testing.

Direct answer

Spend time inside their working day instead of imagining it. Empathy here means you can predict what will get in their way (gloves, noise, interruptions, a shared device, a supervisor watching a productivity number) and you let that change product decisions. You build it by watching real work, asking about specific past events, trying a slice of the task yourself where it is safe, and then writing what you learned down as constraints the product must respect.

How to build it, in order

1. Learn the work before the user. Read their procedures and training material, learn their vocabulary, and ask a supervisor or trainer how the job is measured (picks per hour, patients seen per shift). That measure shapes nearly every choice they make.
2. Observe in context. Contextual inquiry means watching a person do their real work in their real setting and asking questions as they go. Shadow a warehouse shift or ride along on a home visit, with permission and following site rules. Note what they hold, where they stand, what interrupts them and where they improvise.
3. Ask about specific recent events, not opinions. "Tell me about the last time the handheld froze mid-shift. What did you do next?" works better than "Would you like a bigger button?", because a concrete past event is easier to describe than a prediction of what someone would want. Memory is fallible too (people forget details and rationalise what they remember, as Nielsen Norman Group notes), which is why step 2 pairs interviews with watching real work.
4. Try a slice of the job yourself if it is safe and allowed (a short pick shift, or the documentation task on a training system). Your friction teaches fast, but you are a visitor who leaves at lunch, so it supplements their experience and never replaces it.
5. Hear more than one voice. Frontline staff, their managers and the people who train them. Managers tend to describe the job as designed; staff describe the job as done.
6. Convert it into constraints and test with them. Write three to five testable statements, for example "must work one-handed with gloves on" or "must not lose entered data if the connection drops". Put early prototypes in front of the people who do the job, not colleagues.

Worked example (illustrative)

A team is building a documentation app for field nurses on home visits. Shadowing two visits shows the nurse keeps the phone in a bag during patient contact, jots notes on paper in the car, and retypes them at night. An interview confirms it ("I do my notes at nine in the evening"). The team's plan was a richer form with more required fields. After the visits it changes course: quick capture (tick-boxes, short voice note) that takes seconds between tasks, with sync and detail added later. Without being there, the team would have made the evening retyping worse. In a clinical setting, get consent and keep patient-identifying details out of your notes.

Trade-offs and pitfalls

• A single site visit followed by a slide is tourism. The test of empathy is a decision that changed.
• Empathy is not agreeing with every request. It sharpens the problem; you still weigh business goals and engineering cost.
• Letting managers speak for staff, or only meeting the most articulate users, gives a skewed picture.
• Watch for "they would never do that" in your own team's language. It usually means nobody has watched them.

Direct answer

I would not open with "we should delay". I would make the case in revenue and risk terms, show options each priced in days, recommend the smallest change that protects the revenue date, and ask for a staged rollout with a pre-agreed trigger. If I lose, I commit to the decision, instrument it, and reopen it only on agreed data.

Step 1: make sure the finding is solid

Usability testing means watching real users attempt tasks. Check how many participants failed, on which task, and whether they were blocked or only slowed. Illustrative finding used below: 5 of 8 participants could not find where to enter the promotion code at checkout. Five failures out of eight is a strong signal but a small sample, so confirm with analytics (the funnel drop-off, meaning the share of users who quit at each step of the flow, at that step) or a quick unmoderated test (participants do the task alone, with their screen recorded and no facilitator, so you can add many more of them cheaply).

Step 2: translate it into leadership's currency

Leadership is optimizing for revenue, so express confusion as lost revenue. Illustrative numbers: 10,000 users start the flow each month, baseline completion (today's share of starters who finish) is 70%, and beta data suggests completion could fall to 62% (an estimate to be confirmed, not a measurement).

Why the delay costs money rather than just moving it: the promo runs in a fixed window, so each day the launch slips is a day of promo revenue that does not happen later (illustrative: $48,000 a month, so 7/30 of it for a week). The two costs have different shapes. The delay is paid once ($11,200). The confusion is paid every month until it is fixed ($16,000 a month), so a one-week fix costs less than a single month of confusion and the gap widens each month the problem stays.

Step 3: the one-slide executive framing

One slide with the decision wanted as the title, a 20-second clip next to the number as evidence, three options with days and revenue effect, and a recommendation with a tripwire (a pre-agreed trigger that reverses or pauses the plan).

What the fix in option C is: relabel the small "Have a code?" link as a visible "Promo code" field and place it above the pay button. It changes wording and position only, not payment logic, so it is cheap (illustrative: 2 to 3 days of work), which is why it fits inside the launch date. The 10% of users who get it are a cohort (a group of users followed together), and the other 90% stay on the old layout until the numbers say it is safe to widen.

Recommendation: C. Tripwire: pause the promo placement if completion stays below 65% across the first 300 starters in the 10% cohort, which separates the estimated 62% from the 70% baseline. It flips to B if the 10% cohort breaches that line. Why 300 starters and not three days: 10% of 10,000 monthly starters is about 1,000 a month, roughly 33 a day, so three days is only about 100 starters, where completion is measured to within roughly 4.8 points (standard error), wider than the 3-point gap between 62% and 65%, so a three-day read would fire or stay silent largely by chance. 300 starters (about nine days) cuts that to roughly 2.8 points, which makes it a screen, not a verdict. A firm read of 62% against the 65% line needs about 700 starters (about three weeks; this is a one-sided 95% read, where the 3-point gap equals 1.64 standard errors, and a conventional two-sided 95% read would need about 1,000 starters, roughly a month at 10%), so if the date allows, widen the cohort to 30% to get there in about a week. Assign the cohort at random so the comparison with the other 90% is fair.

If I lose

Commit and ship without sandbagging (quietly half-hearted execution that lets the decision you opposed fail). Put in the instrumentation (the tracking that records which steps users complete, so the result is visible), log the fix in the backlog with an owner and a date, share the data at the agreed checkpoint, and escalate only if the tripwire is hit on data everyone accepted. Do not say "I told you so".

The same method in other versions of this fight

The same move (price the harm in leadership's units, offer a smaller option) carries over, with illustrative numbers:

Pitfalls

• An ultimatum ("it cannot ship") ends the conversation; options keep it going.
• Do not quote an estimated 62% as fact. Label it, then use the staged rollout to measure it.
• Delay is not the only lever. Changing scope, placement or rollout size often protects both goals.

Direct answer

Without having interviewed them, I can only offer hypotheses, not facts, and I would say so. I would build them from the company's product, its customers' jobs to be done (the outcomes customers hire the product to achieve) and public evidence, name the three or four pains I would expect, and then explain the link to the mission. The goal is to show I start from the customer's problem, then check my guesses in the first conversation.

How I would form the hypotheses before the interview

• Read what the company says it does and for whom (the mission and the target customer).
• Skim the places customers talk honestly: product reviews, support forums and community threads, job postings from customers' side, and competitors' reviews.
• Ask "what is the customer trying to get done, and what gets in the way?" That defines a pain point: a specific obstacle that makes a task slow, risky or frustrating.

Illustration (a made-up company: expense-management software for small businesses, mission "make spending simple and visible")

How I would tie each pain to the company's purpose

A pain is relevant to the mission if solving it moves the customer toward the outcome the company promises. If a pain is real but unrelated to the mission (say, complaints about a tax rule the company cannot influence), I would note it, but I would not prioritize it.

In the interview itself

• Ask for recent specific stories ("walk me through the last time you did month-end"), not opinions about features.
• Listen for severity (how bad), frequency (how often) and current workarounds, which show how much the pain is worth. Questions that draw each out: "What happens if the receipts are late?" (severity); "How many times did that come up last month?" (frequency); "What do you do today instead?" (workaround).
• Treat my hypotheses as something that could be wrong. A pain I did not expect is the most useful result.

Pitfalls

• Presenting guesses as findings.
• Listing solutions ("they want an app") instead of pains.
• Naming generic pains ("it is expensive") that would fit any company and show no research.