When the Research Plan Breaks
Context
I was brought to Minneapolis by my manager to lead end-to-end usability testing for an early Optum mobile application prototype (2016). I was not the assigned UX resource on the project. I was brought in specifically because of my research skills — to design and execute a study the team needed but wasn’t resourced to run on their own.
Over five days, I designed the study, collaborated with a recruiting vendor, moderated ten sessions solo across two days in a contracted usability lab, and delivered a written findings report the product team used to prioritize development decisions. When a process failure threatened the integrity of the analysis, I resolved it independently — without reducing the rigor of the work.
Context & Problem Space
Optum was developing one of its first mobile applications for members. The prototype was at an early but testable stage, and the product team needed to validate whether real users could complete core tasks before committing to a development roadmap.
At the time, Optum did not have a formal internal UX Research function although it did contract formal research infrastructure for larger, better-funded projects — including lab space and recruiting vendors, both of which this study used. Most of my research practice, however, lived at the other end of that spectrum: enterprise projects without dedicated research budgets, where I developed guerrilla methods to get user data under real constraints. This study was an opportunity to work at the formal end of that range, with the infrastructure to match the rigor the project deserved.
Research was something practitioners like me had built into our own practice — not because it was in the job description, but because design decisions without evidence are just opinions. When my manager identified a gap in research ownership on this project, I was the person called.
My Role
Solo research lead, end-to-end. I owned every phase of the study from design through delivery.
I was not the assigned UX designer on the mobile application. My involvement was scoped specifically to the research: plan it, execute it, report it. That clarity of ownership — and the trust behind it — shaped how I approached every decision on the project.
Challenges
- An unfamiliar prototype on a tight timeline. I spent approximately two weeks before the trip in meetings with the developers to understand how the prototype worked, what it was designed to do, and where the team’s open questions were. I needed to understand the product well enough to design a rigorous test before I ever saw the device I’d be testing on.
- The device arrived the night before. The iPhone 6 used as the test stimulus was handed to me the evening before the first session. I had one night to familiarize myself with how the prototype behaved on the actual device — interactions, transitions, any quirks — so nothing would surprise me in the room.
- Participant no-shows. Two scheduled participants did not show on test days. The recruiting vendor sourced two backup participants in real time. All ten sessions were completed.
- No note-taker. After returning home, I discovered that my manager had forgotten to arrange note-taking coverage for the sessions. Ten hours of recordings existed. No contemporaneous notes did. This was the most significant challenge of the study — and the one that most directly tested my research ownership.
Study Design
I designed a ten-task test script built around the core workflows the product team needed to validate, developed through working sessions with the project’s designers, product owner, and project manager — all conducted remotely in the weeks before the trip. This was all I did during that period; my manager had temporarily set aside my existing project to make room for it. I attended standups to get oriented, scheduled working sessions with stakeholders, and had continuous ad hoc sessions with the two lead developers to understand the prototype’s intended workflows and the team’s open questions.
The test script was mine to design, but it was built entirely on what I could absorb from those conversations and from an Axure prototype that hadn’t yet been developed with adaptive mobile screens — meaning I was working from a desktop version and anticipating how the experience would translate to the iPhone 6 I hadn’t yet held.
Preparation and Stakeholder Management
I had asked to travel with the test device so I could prepare properly in advance. That request was declined. The iPhone 6 was handed to me the evening before the first session by the product owner — whom I was meeting in person for the first time in my hotel lobby, despite having worked together remotely for weeks. I spent that evening familiarizing myself with how the prototype behaved on the actual device — interactions, transitions, any quirks — so nothing would surprise me in the room the next morning.
The studio was a traditional two-way mirror setup. Both lead developers observed every session. Managers and other stakeholders dropped in throughout the two days — the lab was close enough to the Optum campus that attendance was easy, and at times the observation room was quite full. I managed that environment to protect session integrity, keeping observers informed without allowing their presence to shape the moderation.
Moderation
I moderated all ten sessions solo, five per day, across two days at a contracted usability lab in Minneapolis. I used a think-aloud protocol and maintained consistent probing across sessions to ensure the findings were comparable.
The work required managing more than just the sessions themselves. Before the first participant arrived, I discovered a sound issue in the lab — the facility manager wasn’t immediately available, and I had to troubleshoot it myself. Fortunately it was a simple fix. Had it been more complicated, the entire day’s schedule would have been at risk.
Between sessions, after confirming each participant had left the building, I’d debrief briefly with the two lead developers in the hall — water, a snack, a few minutes to decompress. They were engaged and attentive observers, but developers see problems and think in fixes. When they’d float a solution they’d been considering, I’d redirect: the study was there to surface findings, not validate remedies. Keeping that boundary clear without losing their investment across two full days was its own form of moderation.
Two participants presented a different challenge: they wouldn’t stop talking. Managing a verbose participant — keeping the session on track without shutting down the candor that makes think-aloud valuable — is one of the less glamorous moderation skills. It requires patience, timing, and a light touch.
Solo Recovery: Thematic Analysis Without Notes
When I discovered the note-taker gap after returning home, I made a straightforward decision: I would do the analysis myself, at the level the study required. I listened back through all ten hours of session recordings, conducting thematic analysis as I went — identifying patterns in task completion, failure modes, and verbatim language that revealed how participants understood and misunderstood the interface. I structured findings using severity-weighted themes and translated them into a written report the product team could act on directly.
Methods
- Moderated usability testing (in-person, contracted lab)
- Ten-task test script design
- Participant screener development and vendor collaboration
- Think-aloud protocol
- Solo thematic analysis
- Verbatim synthesis across ten hours of session recordings
- Severity-weighted findings structuring
- Written research report and stakeholder delivery
Outcomes & Impacts
The written findings report was delivered to the product team and used to drive development prioritization decisions for the mobile application. The specific findings are proprietary, and supporting metrics were lost in a later migration from hosted storage to Microsoft OneDrive — they no longer exist to reference. What I can say with confidence is that the research was completed in full, delivered on time, and received as actionable.
The product owner — capable and engaged throughout — was well positioned to drive changes from the findings without my continued involvement. My role ended at delivery, by design. I returned to the project I had set aside, and the mobile application work continued without me.
The study was recognized in my next performance review. My manager and his manager both commended me for completing everything asked of me under the circumstances and delivering a report the team could act on. I don’t recall the precise language, but the recognition was noted formally.
Reflection
This study shaped how I think about research ownership more than any other project in my career.
Planning matters — but what you do when the plan fails matters more. The note-taker gap was a real problem. Treating it as a reason to deliver incomplete findings was never a consideration. The participants had given their time. The product team was waiting on evidence. The standard the work required didn’t change because the process had.
Being brought in as a specialist — not as the assigned resource, but as the person trusted to do the research right — was also formative. It told me something about how my colleagues understood what I was doing when I conducted research. That recognition shaped how I began to talk about research as a distinct competency, not just a part of design practice.
Most of my research practice lived at the guerrilla end of the spectrum — enterprise projects without dedicated research budgets, where I found ways to get user data under real constraints. This study was the exception: a contracted lab, a recruiting vendor, a formal protocol. Getting to work at that level of research infrastructure, and to do it well within a compressed timeline, was one of the deepest professional satisfactions of my career. It confirmed that the skill was there at full capacity when the conditions finally matched it.
The work doesn’t belong to the researcher. It belongs to the decisions it enables. Handing clean findings to a capable product owner and trusting the work to continue without me — that was the point. That’s always the point.