User Research
On the practice of understanding users before designing for them
Abstract:
I have conducted my own user research for most of my career. That has included one-on-one interviews, contextual inquiries, usability studies, benchmark tests, and surveys, across organizations of different sizes and against products in different stages of maturity. I recently completed the Nielsen Norman Group's User Research certification, a step that formalized and sharpened a skillset I have been using and refining in the field for years.
The personas shared on this page came out of a set of interviews I conducted shortly after joining Drake Software. I identified interview subjects by running a search of the company's sales database, which let me locate several distinct cohorts of users. Thirty-three interviews followed, each roughly an hour long, each one-on-one. What you see below is the synthesis.
A note on personas, since they are taking some heat lately
Personas have been getting some rough treatment in the design press for a while now. The critiques are not baseless. Personas built on assumptions rather than research, or built once and then left to gather dust on a shared drive, deserve the skepticism they attract. A persona that no one references after it is created is not a tool; it is an artifact of a workshop that happened.
That is not, however, my experience of what good personas can do. When they are grounded in real interviews, when their behaviors and motivations come from what people actually said rather than what a team wishes they would say, and when they are kept alive by being referenced in design reviews, prioritization conversations, and roadmap discussions, they earn their place on the wall. They give a team a shared vocabulary for who the product is for. They make tradeoffs concrete. They help new team members ramp faster. None of that is magic. It is simply what a good persona set has always done when it is used the way it is supposed to be used.
On methodology: recruiting, interviewing, and synthesizing
Recruiting happened through the sales database. I ran a series of queries to find customers who represented different ends of several spectrums at once: firm size, return volume, years with the product, and geographic distribution. The goal was not a statistically representative sample, which qualitative research rarely pretends to be. The goal was a set that spanned enough variance that patterns would surface rather than reflect one narrow slice of the user base.
The interviews themselves followed a semi-structured guide. I started with the same set of opening questions for everyone, to keep the early responses comparable, and let the conversation branch from there based on what each person wanted to say. Semi-structured works better than fully scripted for this kind of work because users routinely volunteer the most useful observations in response to questions I did not think to ask.
Synthesis was a two-pass process. On the first pass, I went through the transcripts and notes looking for behaviors, tools, frustrations, and attitudes, tagging anything that felt distinctive. On the second pass, I grouped the tags into clusters and looked for the clusters that held together across multiple interviewees. Four clusters kept reappearing. Those became the personas.
A few interviewees did not fit any of the four cleanly. That is normal and expected. Personas represent patterns that account for most of the observed variance; they do not have to account for all of it. The holdouts are worth noting in the research write-up, but they do not invalidate the personas any more than an outlier invalidates a trend.
On anonymization and honest representation
Everything visible in the persona cards below has been anonymized. The names are fictional and do not map to any interviewee. The photos are AI-generated and depict no real person. Demographic specifics have been generalized into ranges. Pull-quotes are composites that capture the pattern rather than reproducing any one person's words.
What has not been changed is the substance. The tools, the attitudes, the goals, the frustrations, the tech comfort profile, the return volumes, the mix of work the persona handles: all of that comes directly from the research. The point of a persona is to carry the research into the design process accurately. Anonymization protects the interviewees. It does not soften the findings.
“Research is formalized curiosity. It is poking and prying with a purpose.”
— Zora Neale Hurston
The four personas
Below are the four personas derived from the thirty-three interviews, starting with an overview of all four and followed by a detail card for each. The detail cards include main tasks and demands, tools used, a two-part tech comfort profile (Drake expertise versus broader automation and tooling), and the persona's goals and frustrations. Each card also notes how many interviewees the persona rests on.
If it is useful to have the personas in a portable format, the full set is available as a downloadable deck: PowerPoint or PDF. Both formats export cleanly to slides, images, or print.