Product & Problem Discovery
Eleven severity-rated findings, and software recommended for only three of them
Overview
Honda HALO runs a wind tunnel and acoustics testing facility used by both its own engineering staff and an outside operations partner running tests on behalf of third-party clients. The facility itself was new, its automation still being worked out in real time as testing ramped up, and nobody had stepped back to ask the people running it every day what actually got in their way. I was brought in as the product consultant on a two-person Discovery team for nine weeks, watching fully automated vehicle and acoustic testing at a scale I hadn't seen before and talking directly with the technicians and operators keeping it running, then delivered a severity-rated findings report and a recommendation for what was, and wasn't, worth building software to fix.
Role
Product Consultant
Scope
Nine weeks (team of two, made up of myself and a Callibrity Technical Consultant)
Tools
Contextual inquiry, structured 1:1 interviews, a severity-rating framework adapted from the Nielsen Norman Group's heuristic evaluation methodology, user stories
Approach
Problem Statement
The facility's two operating teams were each managing scheduling, documentation, error troubleshooting, and end-of-test data handling their own way, with no shared source of truth between them. Test data changed hands manually. Documentation lived across SharePoint, OneDrive, local wikis, and paper notebooks depending on who wrote it. Technicians reused the same shared login for every control-room machine at the start of every test, and login details were kept on a card at the workstation. Nobody had looked at the operation as one connected system, and nobody had asked the people running it what slowed them down.
Goals
- Understand daily facility operations well enough to find real friction points, not assumed ones
- Build enough trust with two separate operating teams, one long-tenured, one newer, to get honest feedback during live test days
- Translate what we heard into a prioritized, severity-rated set of findings the client could act on
- Recommend digital products only where they were genuinely the right answer, not by default
Process
Eleven distinct issues came out of the observations and interviews, everything from how technicians logged into control-room computers each morning to how test data got handed off to clients at the end of a session. Several of the highest-severity findings, like the lack of a single documentation source or unclear system error messages, were process and tooling gaps that a shared wiki and a plain-language error cross-reference could fix, not custom software. Only three of the eleven findings, the ones with a genuinely new digital workflow behind them, were recommended for a proposed build phase. Every finding was written up the same way regardless of whether it led to a recommended build: what we observed, possible solutions, the value if solved, and what we still didn't know.
- Onsite observation
- Structured 1:1 interviews
- Severity-rated findings
- User stories
- Recommendation report
- Extended into a custom-build engagement
Findings
One thing held across nearly every conversation: the client's own early guidance to us was that adding new technology for its own sake wasn't the goal, and that solving for the people running tests mattered before anything aimed at the end customer's experience. That framing shaped every recommendation that followed. It also surfaced a real gap between the two operating teams: the newer partner team had far less institutional knowledge to fall back on than the client's own long-tenured staff, so issues that were a minor annoyance for one team were a recurring blocker for the other. For the login-time finding specifically, we recommended the client first measure how long the existing process actually took, before evaluating any replacement, so a future fix could be judged against a real baseline instead of a guess.
Solution
Of the eleven findings, three were recommended as digital products for a proposed follow-on build phase: a secure, self-service scheduling tool for the operations partner's clients to replace a manual, Excel-based process; a guided data handoff-and-removal tool for end-of-test data transfer, replacing a 15-to-20-minute manual file copy and deletion process, with a client-facing digital sign-off confirming receipt before deletion; and a downtime-tracking tool to replace a whiteboard-to-spreadsheet process with something that could support maintenance forecasting over time. The remaining findings, including centralized documentation, plain-language error troubleshooting, and cross-team communication, were scoped as process and tooling recommendations rather than custom software, on purpose.
Impact
Results
- Four on-site visits and close to a dozen 1:1 interviews across two operating teams
- Eleven severity-rated findings delivered in a 28-page report, plus a summary deck for stakeholders
- Three findings scoped into a proposed digital-product build; the other eight scoped as process and documentation fixes instead of custom software
- The client extended the engagement into a three-month build phase for the end-of-test data handoff tool, one of the three recommended products, turning the Discovery recommendation into real, delivered work
Achievements
- Adapted a UX heuristic-evaluation framework to a physical operations environment that had never used one
- Recommended process and documentation fixes over new software on eight of eleven findings
- Built enough trust with the client stakeholder driving the engagement and an operations-partner stakeholder with deep system knowledge, and with a time-constrained technical team more broadly, to get honest, specific feedback during live test days without disrupting testing
- Turned the Discovery engagement into a three-month funded build of the end-of-test data handoff tool, the recommendation converting directly into delivered work
Takeaways
What would I do differently?
The report itself was explicit about what we didn't yet know. Several of the highest-value recommendations, including the client-facing scheduling tool, were flagged as needing more research before we could scope a build with confidence, not because they weren't real problems, but because a Discovery engagement should surface what still needs investigation as honestly as what it already knows. We proposed rolling that research into the next phase rather than guessing at a solution to hit a deadline.
How did I grow?
This was a great client, one whose trust let us work at full capacity instead of a boxed-in engagement. What stood out here was applying my product process to a full engineering facility rather than a digital product: the interview script, the severity ratings, and writing down every friction point even when it wouldn't become a product all worked exactly the same in a physical space as they do on a web or app project. The process didn't change, only the environment did, which is also why the most valuable recommendation here was that eight of the eleven findings didn't need new software built for them at all.
