Happy Sunday/Monday. This week's issue is one I've been sitting on for a long time, and I'm glad I waited, because I've had a lot more chances to watch it play out at work.
It's about a habit my team picked up that I almost never hear other data folks talk about: before I build anything, I ask if I can shadow the team I'm building it for. Not another kickoff call. Actually watching someone run their manual report, click by click. I recognize not all of us are in the business of report building and automating but this method can apply to many other parts of the data field as well.
It has changed how I scope projects, how I prioritize, and honestly, how stakeholders work with me. But more on all that below.
First, this week's trivia.
TRIVIA
There's actually a formal name for the research practice this week's issue is built on. In UX research, observing people doing their real work in their real environment, instead of asking them about it in a conference room, is called:
A. Heuristic evaluation
B. Contextual inquiry
C. Card sorting
D. A/B testing
Answer at the bottom of this issue
TODAY’S TOPIC
Why I Ask to Shadow Teams Before Building Anything
Most projects start the same way: a kickoff call. Something long the lines of stakeholder explains what they want, we ask clarifying questions, someone sends over a requirements doc, and we're off.
And on every project where I stopped there, something important got missed. Not because anyone lied. Stakeholders tell you the truth as they understand it. The problem is that nobody can fully describe their own workflow from memory. The pain points have been normalized, and those workarounds have been so rooted in the everyday work that it’s no longer considered a workaround.
So I started adding one ask at the end of every kickoff call: "Before I build anything, can I shadow this process once? Can someone show me how you do the reporting, start to finish?"
The first time I did this, I watched an analyst spend twenty minutes copying values between two spreadsheets before she even opened the file I thought we were there to talk about. That step wasn't in the requirements doc. It wasn't in anyone's head as a requirement at all. It was just the thing you did first. And it ended up being one of the most valuable things I automated on that entire project.
That's the pattern I've seen over and over since: the gap between stated needs and observed needs is where the real value hides. Requirements docs capture what people can articulate. Shadowing captures what they actually do.
A few things it gets you that no kickoff call will:
The hidden business logic. Manual processes encode years of decisions nobody wrote down: which rows get excluded, which numbers get sanity-checked against what, which edge cases get handled by hand. Automate without seeing that, and you ship a dashboard that's technically correct but also kind of wrong.
Real prioritization. You stop guessing which pain point matters most. You can see it. The step people sigh at is the step to fix first.
Trust. This one surprised me. When you've sat next to someone and watched them work, you're no longer "the data person who takes requests." You're someone who understands their job. Adoption gets easier because they helped you see the problem, so the solution feels partly theirs as well.
Here's what I want to be honest about: nobody will ask you to do this. There's no ticket for it, it's not in anyone's project template. That's why I almost titled this issue with the word "voluntarily" in it. If we're in the business of delivering solutions that actually get used, at scale, that sometimes means taking steps beyond what the process asks of us.
If you want to try it, the ask is genuinely this small: "Could I watch you run this report once before I start? Thirty minutes. I'll just observe and take notes." In my experience, people are happy someone finally wants to see it.
Try it on your next kickoff. I'd love to hear what you find!
WORTH YOUR TIME
ARTICLE
Contextual Inquiry: Inspire Design by Observing and Interviewing Users in Their Context
The formal research discipline behind this week's issue. If you want the structured version of "watch people work," including the four principles that keep a session productive, start here. Read more →
TOOL
Scribe
When you shadow a manual process, you'll want to capture it. Scribe records the steps as the person clicks through them and turns them into a step-by-step guide with screenshots automatically. Great as both documentation of the current state and a spec for what you're about to automate. Discover more →
QUICK STUDY
▶️ Problems with Contextual Inquiries
Contextual inquiry is a UX research method where you shadow people as they do their job (or leisure tasks), allowing you to ask questions in context. This video provides advice on overcoming the main challenges with this method. Learn more →
COMMUNITY BOARD
FROM THE EDITOR
Summarize and understand anything on the web.
Turn any screen into instant insight, VizBuddy captures your browser and hands you a structured analyst-grade summary in seconds (Chrome only).
TRIVIA ANSWER
There's actually a formal name for the research practice this week's issue is built on. In UX research, observing people doing their real work in their real environment, instead of asking them about it in a conference room, is called:
A. Heuristic evaluation
B. Contextual inquiry ✅
C. Card sorting
D. A/B testing
It comes out of UX research: you observe and interview people in their own environment while they do their actual work, instead of pulling them into a conference room and asking them to describe it. If this week's issue resonated, that's the formal discipline behind it. Read more about it 📖
How was this week’s issue?
Newsletter publishing is hard work and it’s just me running the show here. If you ever feel like extending a thanks, idea, or insult you can do that here.
Or email me directly at → [email protected]
If you’re feeling generous and want to send a gift to me, I also keep an active wishlist of items or books I’m interested in.
