Why a 1970s TV Detective Still Explains UX Research

Lieutenant Columbo, the disheveled Los Angeles homicide detective from the classic 1970s series, built his entire career on one premise: the truth is rarely what people say it is. Each episode shows the crime upfront, leaving the real mystery in how he distinguishes lies from the truth and proves guilt.

That is also the daily reality of UX work. We explore human behavior, but we inevitably influence the very findings we uncover because we are humans too. People disguise their real needs. Missing facts have to be discovered before something useful can be built. A designer who has ever found themselves doing research without a dedicated researcher on the team will recognize the parallels instantly.

Keep Your Title Out of the Room

Columbo understood something fundamental: people behave differently when they know a detective (or a state official, or management) is in the room. Suspects and witnesses would consciously or subconsciously tweak facts the moment they realized who he was. So he kept his position out of sight as long as possible, preferring to blend in entirely.

Pictures of Columbo in two situations, such as during the UX research and in a job interview, with speech balloons where it states, ‘My name is Frank, and I am a researcher. Today we will talk about..’
Understate your role to users. (Large preview)

UX research faces the same challenge. Designers run a constant risk of receiving twisted information because they fail to address users' fears and insecurity. Common failure modes include:

  • Interviewees assuming their boss sent you to evaluate their performance;
  • Users believing you created the design and holding back criticism to avoid offending you;
  • Customers worrying you will judge their computer literacy.

An introduction that kills research accuracy sounds something like: "Hello! I'm a Senior UX Designer and Product Manager. Today, I'll conduct a usability testing session and jobs-to-be-done interview to identify UX gaps in our design…" After that, most people will flood you with socially expected answers.

Keep fancy titles to yourself. A humble opening for usability testing works better: "My name is <…>, and I was asked to check whether this website is useful and clear to you." Do not let people think you designed it, even when you did.

For a user interview, a simple introduction is safer: "I'm a researcher, and today I'd like to ask you a couple of questions about <…>." Redundant details only scare people and raise tension.

In some situations, you might say: "I didn't design this, so I won't be offended if you criticize it; please be honest with your feedback!" That sits on a thin edge between reducing research bias and outright lying, so use it consciously.

Play the "Little Man" to Let People Open Up

Columbo routinely faced wealthy, powerful criminals who assumed they would never be caught. His counter-strategy was playing the role of an unassuming "little man" without any shame. Hiding his intellect entirely, he deliberately encouraged others to feel superior to him. This made people behave freely and reveal their true motives. His messy appearance — a creased raincoat, a cigar, an old Peugeot — hid a shrewd mind behind a slack demeanor and sloppy conversation.

A picture of Colombo who looks messy signed with a phase ‘Conducting field research’. On the right side, Columbo, wearing a suit, signed with the phrase ‘Presenting research results to the stakeholders’.
Research is not meant to show off. (Large preview)

New designers are often taught the opposite: the value of presentation skills, making a positive first impression, and firmly defending design decisions. Those habits sabotage research. Presenting designs to top management is not the same as conducting research. A presentation requires you to assure everyone that your decisions are well informed. Research requires the exact inverse: making people feel relaxed enough to tell the truth.

Research is not a stage for showing off. Users are not your manager; they will not influence your career path, and they are not there to be impressed. Acting humble while staying in control of the session produces better material than reproducing a "boss-subordinate" or "expert-noob" dynamic. The key is blending in, practically translated as:

  • Match the dress code of your interviewees (within reason). A flashy designer "Helvetica" T-shirt belongs at a UX meetup, not in front of a user who cannot relate.
  • Avoid design jargon that demands constant explanation. A reasonable dose of the interviewee's professional terminology helps when the topic is specialized.
  • Behave neutrally but naturally. Balance impartiality with ordinary empathy — do not act like a robot.

Learn the Domain Before You Ask Questions

Modern teams call this approach a "user safari" or contextual inquiry. Columbo practiced it long before that term existed. If you want to understand your users, observe them in their natural habitat and seize any chance to try their occupation. Seeing something once is worth hearing about it a thousand times.

Pictures of Colombo in different roles, such as a doctor, a sommelier, a photographer, a vagabond, and so on
A researcher is a master of many trades. (Large preview)

Translating this into UX comes in many practical forms. Observation studies and contextual inquiries give direct access to users. When that is impossible, documentary films, YouTube channels from professionals, and niche communities can help you prepare to face real users without wasting their time on surface-level questions.

Take a project preparing interviews with drilling engineers — future users of an app suite for drilling planning. A subject matter expert from the client side recommended watching Deepwater Horizon, the film about the 2010 Gulf of Mexico oil spill, because it realistically showed drilling rig activity. That preparation made the technical jargon familiar enough to spend interview time on genuinely unobvious facts, not Wikipedia basics.

Another example comes from a product discovery team working with a Middle East logistics company. During an on-site observation, the team found couriers only simulated using a navigation feature. The app required the step to proceed but had been designed around European address formats, which clashed with local realities. Couriers solved it by faking the action — something they would never have reported to superiors, and something no interview or management workshop could have revealed.

Ask Another Question: "Just One More Thing"

The most famous Columbo catchphrase — "just one more thing" — appeared nearly every episode. Sometimes it sounded like a forgetful cop rambling; sometimes it landed like a carefully planned bomb.

A picture of Colombo next to a chart pie, where around 40 percent relate to insights after all scripted questions, and the rest 60 percent relate to insights after contextual questions
“Uhh… Just one more thing!” (Large preview)

Translating that phrase into modern practice means building the skill of asking follow-up questions and improvising in pursuit of insights. The stakes are lower in tech than at a homicide scene — no one needs to provoke a confession for trial — but the underlying instinct is identical. Detectives and UX folks both chase a sensation of valuable information, a buzz that pushes them beyond the script and protocol to dig deeper into the unexpected.

"I have always found that plans are useless, but planning is indispensable."
— Dwight Eisenhower

Even the best interview, usability test, or workshop script cannot anticipate every nuance. The discipline lives in distinguishing between two kinds of questions:

  • Research questions define what your team wants to learn to make better design decisions: Will they buy this app? What is their top problem? Why are we worse than competitors? These stay internal and hidden from participants.
  • Interview questions are what you actually ask participants, formulated carefully because answers cannot always be retrieved directly: Please tell me about the last time you ordered grocery delivery. They are the practical means to answer your research questions.

Research questions are locked in advance with the team, but the interview questions remain at the researcher's discretion. One respondent might answer a single "Tell me about the last time…" with a stream of usable data. Another will hand over only small fragments, requiring more granular follow-ups: "What did you order? How did you choose? What payment did you choose? Why this option?" A researcher who can only recite prepared questions has outsourced their job to a script reader. Human sessions often demand treading carefully, adapting on the spot, and asking another question — just one more thing — before wrapping up.

Trust, But Verify: The Columbo Method For Digging Deeper

Part of the fun of watching Columbo is seeing suspects talk themselves into a corner. They believe a well-rehearsed explanation will deflect suspicion, so they keep talking — and with every word, they hand the Lieutenant the evidence he needs. The lesson for UX professionals is blunt: people lie, often without meaning to.

Stakeholders have agendas. Some want to look smarter than they are. Others hold back real opinions because they aren’t sure how those opinions will be used. Office politics can muddy the waters further when what gets said officially doesn’t match the actual goal. In all these cases, the designer’s job is not to take statements at face value but to probe gently until the truth surfaces.

A dialogue between Columbo as an interviewer and a user, where a user says that he like a feature. Columbo asks when the user last time used a feature. And a user replies that he actually hasn’t used it yet.
Don’t take words at face value. (Large preview)

Consider the classic exchange from the episode “Murder Under Glass” (S7E2). A food critic, Paul Gerard, has been poisoning restaurant owners who refuse to pay for positive reviews. When asked when he first suspected Gerard, Columbo replies that it took about two minutes — because a man who had just dined with a poisoned companion went straight to the police instead of a hospital, never asking to have his stomach pumped. Gerard’s story was too clean, too convenient.

The same logic applies to feature requests. A product owner asks for an export button because “export is a standard thing for engineering applications.” But if the design team has already watched users copy-paste data into a branded PowerPoint template during interviews, the request falls apart under one or two gentle questions. Columbo’s approach works: never show skepticism, always ask for context, keep the conversation going until you reach the root cause.

Classical UX doctrine casts designers as “user advocates” who broadcast the user’s voice. But that doesn’t mean listening indiscriminately. If someone demands a feature yet cannot point to a single past example of how a similar tool helped them, treat it as an exaggeration. If a business owner calls an app successful but has only consulted colleagues, treat it as optimism, not data.

The Five Rules Columbo Would Hand Down

If the Lieutenant traded his trench coat for a UX portfolio, his advice to practitioners would read like a short handbook:

  1. Don’t flash a fancy UX title unless it serves the situation.
  2. Avoid showing off in front of users; this isn’t a job interview or a board presentation.
  3. Observe people in context, in their natural environment.
  4. Keep a stockpile of contextual and follow-up questions ready.
  5. Remember that everyone lies, often unintentionally — double-check their words.