How empathy, observation, and real-world context reveal what product analytics alone cannot.
Every weekday at around eight, Thrisna stopped at a small coffee shop near her office in South Jakarta.
She rarely needed to order. The barista would look up, notice whether she was walking quickly or slowly, and begin preparing the right drink.
On ordinary mornings, it was an iced palm sugar latte with less ice. On rainy mornings, it became a hot long black. When Thrisna arrived while holding her laptop charger, office badge, and a phone already ringing, the barista placed the cup near the edge of the counter so she could pick it up without rearranging everything in her hands.
One Monday, Thrisna entered looking unusually quiet. The barista reached for the familiar plastic cup, paused, then asked, “Hot today?”
Thrisna nodded.
Nothing dramatic happened. No long conversation. No customer profile appeared on a dashboard. Yet the barista had noticed something important: the same person can need different things in different contexts.
That small moment captures an ability product designers often describe too narrowly as empathy.
The Stanford d.school calls it Learn from Others, People and Contexts.
It is the ability to understand people as they live, decide, adapt, struggle, and make meaning inside a particular environment. It asks us to learn not only from what people say, but also from what they do, what surrounds them, and what changes from one situation to another.
📊 The Dashboard Said Users Were Doing Fine
Thrisna’s product team was redesigning a mobile attendance tool used by staff across retail stores. The dashboard showed a healthy number of daily check-ins. Most employees completed the task in less than a minute. From the office, the experience looked simple: open the app, confirm the store location, take a selfie, and submit.
The team planned to polish the interface and move on.
Then customer support forwarded a strange pattern of complaints. Some employees said the app was “susah dipakai,” difficult to use. Others asked supervisors to check in on their behalf. A few submitted blurry photos or repeated attempts minutes apart.
The numbers showed completion. They did not show the effort hidden inside it.
Thrisna proposed visiting several stores before changing the screen. At the first location, she watched an employee begin the check-in while the store shutters were opening. Delivery boxes blocked part of the entrance. A supervisor was calling out tasks. The phone’s GPS took time to stabilize indoors, so the employee walked toward the pavement while still wearing a store apron.
At another location, the morning sun made the screen difficult to read. At a third, employees shared a charging cable because their phones had been used for the long commute. One employee worried that repeated selfies would remain visible to managers beyond attendance needs.
None of these details appeared in the funnel.
Analytics had answered what was happening. Context began to explain how and why.
👀 Watch the Work, Not Only the Interface
Learning from others is not the same as asking people what feature they want.
People are experts in their own experience, but they do not always have ready-made language for everything influencing their behavior. Habits become invisible. Workarounds feel normal. Social pressures are difficult to describe. Sometimes people explain what they believe they should do rather than what happens on a hectic Monday morning.
This is why observation matters.
Thrisna did not only watch where employees tapped. She paid attention to what happened before and after the tap. Who was nearby? What else demanded attention? What did people protect, postpone, or improvise? Which objects, rules, relationships, and environmental conditions shaped the task?
One employee completed attendance quickly, then reopened the app to take a screenshot. When Thrisna asked why, he said he kept proof in case the system later marked him absent. That screenshot was not part of the official journey, but it was part of the real experience.
The team had designed a submission flow. The employee had designed his own trust mechanism.
If Thrisna had limited the research to a usability test in a quiet meeting room, the screen might have performed beautifully. The test would still have missed the reality that mattered.
🗣️ Ask for a Story, Then Stay Long Enough to Notice
Good field research combines curiosity with humility. It does not treat people as sources from whom answers must be extracted as quickly as possible.
Thrisna began interviews with concrete stories:
“Tell me about the last time check-in did not go as expected.”
“Can you show me what you did next?”
“Who did you contact?”
“What were you worried might happen?”
These prompts brought the conversation closer to actual events. An employee could point to the place where GPS often failed. A supervisor could show the WhatsApp group used to resolve attendance disputes. A store manager could explain that late check-in was not just a technical issue. It affected payroll, trust, and sometimes a difficult conversation with a worker.
Thrisna also paid attention to contradictions without treating them as dishonesty.
One participant said the selfie step was easy, yet waited until other employees moved away before demonstrating it. The words described usability. The body described discomfort.
Learning from others requires us to hold both.
☕ The Barista Does Not Memorize Only the Order
The barista near Thrisna’s office knew that an order was not a permanent definition of a person. The drink depended on weather, time, pace, mood, and what Thrisna was carrying that morning.
Product teams often create personas that accidentally freeze people. “Busy professional.” “Price-sensitive user.” “Store employee.” Labels can help organize information, but they can also remove the changing context that gives behavior its meaning.
A person may feel confident using an app at home and hesitant using the same app in front of a supervisor. They may have a stable internet connection at noon and almost none during the morning commute. They may value speed in a food order but careful explanation in a financial decision.
Context is not decoration around the user. It participates in the experience.
For the attendance product, this insight shifted the design question. The team stopped asking only, “How might we make selfie check-in faster?” They began asking, “How might we help employees establish trustworthy attendance in the conditions where work actually begins?”
That larger question opened different possibilities: clearer GPS status, a private explanation of photo use, better recovery when location services failed, visible submission receipts, and a supervisor review path that did not depend on scattered screenshots.
🪞 Empathy Is Not Imagining Yourself in Someone Else’s Place
Designers sometimes say, “If I were the user, I would want this.” The sentence sounds empathetic, but it can quietly replace another person’s reality with our own preferences.
Thrisna worked in an air-conditioned office, used a recent phone, and understood why the company collected location data. Imagining herself checking in would not reproduce the experience of an employee using an older device, standing beside traffic, wondering whether a failed attempt would reduce a monthly allowance.
Empathy is not confident projection. It is disciplined openness.
It asks us to notice the distance between our assumptions and another person’s world. It also asks us to recognize power, culture, language, and consequences. Who can refuse? Who must adapt? Who carries the cost when the product fails?
Learning from others does not mean accepting every request literally. It means allowing people and contexts to change how we understand the problem before we decide what to make.
🛠️ Let What You Learn Change the Work
Research becomes performative when the team visits people, fills a wall with photographs, and then continues with the original solution.
What Thrisna’s team learned changed both the product and the project. Engineering joined a store visit and saw how long GPS recovery felt in context. Legal rewrote the explanation of photo retention in plain language. The team tested the interface outdoors on older devices instead of only using office Wi-Fi. Product success was expanded beyond completion time to include failed attempts, recovery, and attendance disputes.
The research did not produce a magical single answer. It changed the quality of the team’s questions and decisions.
That is the deeper purpose of learning from others. We are not collecting human stories to decorate a presentation. We are inviting reality into the design room, especially the parts that our dashboards and assumptions leave outside.
🌧️ The Next Rainy Morning
A week later, Thrisna entered the coffee shop while shaking rain from her umbrella. The barista placed a hot long black on the counter and slid a small tissue underneath the wet cup.
Thrisna smiled because the gesture felt personal. Yet it was not magic. It came from attention repeated over time: noticing patterns, recognizing change, and responding to the situation in front of him.
Product designers rarely know users as individually as a neighborhood barista knows a regular customer. But we can practice the same quality of attention.
We can step out of the meeting room. We can observe what people actually do. We can ask for specific stories. We can notice the phone, the weather, the supervisor, the fear, the workaround, and the small act that makes the system feel trustworthy.
Because people do not use products in research plans. They use them in the middle of life.
🧺 Takeaways to Bring Into Your Next Project
- Learn from people and the contexts surrounding their behavior, not only from stated preferences.
- Use analytics to locate patterns, then qualitative research to understand meaning and effort.
- Observe the wider activity before, during, and after someone touches the interface.
- Ask for recent, specific stories and invite people to show their workarounds.
- Treat empathy as disciplined openness, not as imagining that your experience represents someone else’s.
- Let research change the question, the plan, and the measures of success.
P.S. Next up:
“Synthesize Information: Like Sifting Gold from Sand to Find Meaning in Messy Research” 👀
🔗 About This Series
This is article 2 of Designerly Thinking: Eight Core Design Abilities, followed by a reflection epilogue. The abilities come from the Stanford d.school and are not intended as a rigid sequence.
- Design Your Design Work: Like Setting Up Your Kitchen Before You Cook
- Learn from Others: Like Watching a Barista Who Knows Your Order and Your Mood
- Synthesize Information: Like Sifting Gold from Sand to Find Meaning in Messy Research
- Rapidly Experiment: Like a Chef Testing Small Portions Before Serving the Full Menu
- Move Between Concrete and Abstract: Like a Doctor Connecting Symptoms to the Larger System
- Build and Craft Intentionally: Like a Watchmaker Engineering Every Gear
- Communicate Deliberately: Like a Diplomat Aligning Allies in a High-Stakes Room
- Navigate Ambiguity: Like a Captain Forging the Route Through the Fog
- Reflection: Like a Warung After Closing, Turning a Busy Day into Better Judgment
Learn from Others: Like Watching a Barista Who Knows Your Order and Your Mood ☕ was originally published in Product Design Community on Medium, where people are continuing the conversation by highlighting and responding to this story.
