Conflicting Signals From the Night Shift
NightShift is a grocery-delivery pilot for hospital staff working 12-hour shifts. The team ran 11 interviews and two ride-alongs with nurses and porters, then built a "quick reorder" screen. The findings conflict: some participants wanted a two-tap reorder of the same items, while others said they plan a week ahead and want a scheduled basket. The product manager has written this problem statement: "Night-shift workers need a faster app so they can order groceries quickly." She also wants a single persona, "busy professionals", to keep scope manageable. The pilot runs in two hospitals for eight weeks with one designer, two engineers, and a part-time PM. About 40% of interviewees mentioned that the hospital cafeteria closes at 8pm and that they decide what to eat during a 15-minute break. A separate group of six described sharing an account with a partner who does the ordering.
1. Critique the PM's problem statement and rewrite it as a point-of-view statement. Explain what you changed and why.
Read the worked answer
The statement has three defects. It is circular - a faster app so people can order quickly restates the goal as the solution. It bakes in the solution, since "app" and "faster" are decided before the need is defined; that quietly rules out scheduling, which half the interviews pointed at. And it has no user specificity or insight: "night-shift workers" is a job category, not a person in a situation, so any feature can be justified against it.
A POV statement is built as user + need + insight, where the insight is the non-obvious thing the research revealed:
Hospital staff on 12-hour shifts, who decide what to eat during a 15-minute break, need a way to get a reliable meal without planning ahead - because the cafeteria closes at 8pm and they cannot predict when the break will come.
What changed and why: the user is now defined by situation, not occupation; the need is stated as an outcome and permits multiple solutions; and the insight - the short, unpredictable break plus the 8pm cafeteria closure - is the part a designer could not have guessed. It also makes the shared-account group visibly out of scope rather than silently averaged in, which is a scope decision the team can now argue about explicitly.
2. Write two how-might-we questions from the research findings, one deliberately too broad and one too narrow, and evaluate both. Which would you pursue and why?
Read the worked answer
Too broad: "How might we make grocery shopping easier for busy people?" This fails because it has no user, no constraint, and no direction - it admits every idea, including ones the research already ruled out, so it cannot be used to judge concepts. A HMW that permits anything gives the team no basis for saying no.
Too narrow: "How might we add a two-tap reorder button to the app?" This is a solution wearing a question mark. It presumes the app, the button, and the quick-reorder hypothesis, and it excludes the scheduling behaviour half the sample described. Teams that ideate from this will produce variations of one idea.
Better: "How might we help staff with an unpredictable 15-minute break get a meal they can eat immediately, without requiring them to plan earlier in the day?" This keeps the situational insight, leaves the mechanism open - it could be a scheduled standing order, a saved basket, or a pickup locker - and is narrow enough to evaluate ideas against.
How to choose: pursue the question that is answerable within the pilot's constraints and whose answers would change a decision. The predictable-break segment can come later as a second HMW; the improvised-break group is the one the current product is failing, and it is the one an eight-week pilot can actually learn about.
3. The PM wants one persona, "busy professionals", to keep things manageable. How do you respond, and how do you use the research to set scope?
Read the worked answer
Agree with the instinct to limit scope, disagree with the instrument. A persona is a communication tool distilled from observed patterns, used to make design decisions without re-reading the raw data. "Busy professionals" is a demographic description, not a pattern - it does not predict what anyone does on a break, so it cannot arbitrate a decision between quick reorder and scheduled baskets. Personas built on demographics tend to become caricatures and are ignored by teams within a month.
The research offers behavioural segments instead:
- Improvisers - decide during the break, blocked by the cafeteria closing; need immediate availability.
- Planners - order a week ahead; need scheduling and repeat baskets.
- Account sharers - six participants; ordering is done by someone else, which changes the whole model.
Recommendation: build one primary persona from the largest behavioural cluster, name the second as a secondary persona, and capture account sharers as a scenario for a later phase rather than flattening all three into an average that describes nobody. Ground each persona in quoted goals, context, and frustrations from the interviews, and note the sample size next to it so nobody mistakes it for survey data. Then use the persona as the tie-breaker in the room: if a proposed feature serves neither persona's stated goal, that is a scope conversation with evidence behind it.