UX Researcher
UX Designer
Automotive Software Validation
One cloud platform. Every OEM. No more fragmented, complex software validation.
Industry :
Automotive Software
Client :
Global Engineering Enterprise
Project Duration :
Dec 2025 - Ongoing
Tools :
Figma, Miro, Gemini, Claude
Summary
Challenge
Engineering teams were stuck validating software across disconnected tools, physical hardware dependencies, and siloed knowledge that no single person fully owned.
Target Audience
Automotive software engineers, test architects, and OEM integration teams working on safety-critical software validation.
Impact
Leading OEM partners validated our core hypotheses and actively ran their own test scenarios on the platform. The workflow resonated before the product was fully shipped.
The real problem behind the work
The automotive software industry has a validation problem that is not talked about enough. As vehicles become software-defined, the complexity of testing that software grows faster than the tools available to manage it. Engineers rely on multiple specialized tools, each owned by a different team, each requiring its own setup, licensing, and expertise. Nobody owns the end-to-end picture.
When I joined this project, that fragmentation was not just a technical issue. It was a human one. Information was scattered across people, not systems. Every stakeholder had a piece of the puzzle: product owners had business assumptions, solution architects had infrastructure constraints, test architects had compliance requirements, and OEM partners had their own workflows we needed to understand before we could design anything useful.
"The hardest part was not understanding the software. It was understanding that every person in the room had a different mental model of what we were building, and none of them were wrong."
That was the real starting point: not a design problem, but an alignment problem at scale.
How we solved it
This was the most technically complex UX project I have worked on. Before I could map a single user flow, I had to build enough domain knowledge to have credible conversations with engineers who think in ECUs, virtual targets, and compliance test standards. That learning curve was steep and intentional.
Stakeholder alignment workshop
I facilitated a cross-functional alignment workshop with POs, PMs, solution architects, test architects, UX and UI designers, and external partners. The goal was not brainstorming. It was excavation. We surfaced every assumption, every competing priority, and every unanswered question about what the platform actually needed to do. Three core use cases emerged from that session, each tied to a real engineering pain point, not a product feature. Those became the foundation for everything that followed.
In-person workshop, cross-continent
I traveled to join an engineering workshop with the core development team to untangle the technical architecture into something a UX team could actually work with. Engineers are exceptional at building systems. They are not trained to see how a user moves through those systems end to end. That gap was my job to close.
User roles and workspace flows
The hardest UX work on this project was defining user roles and mapping a complete user flow for each workspace. Each workspace represents a distinct test case. Each test case involves different user permissions, different tool access, and a completely different backend configuration. Getting that wrong means an engineer cannot run their test. Mapping it correctly meant understanding both the user's mental model and the system's technical constraints at the same time.
Key research outputs
Role definition: Who can access what, do what, and see what inside each workspace. This was not obvious and required multiple rounds of validation with technical stakeholders.
End-to-end flow per workspace: Each test scenario required its own journey map, from setup through execution to output review. The flows looked deceptively simple from the outside and were extremely consequential to get right.
Competitor analysis: A structured comparison against platforms in the same market revealed a key strategic position: Strata is not competing with specialized simulation tools. It orchestrates them. That distinction shaped how we positioned features and communicated the platform's value to OEM partners.
The impact we made
We built this platform without a confirmed customer in the early stages. The use cases were hypotheses drawn from research, alignment workshops, and competitive analysis. That is a high-stakes position for a UX team to be in.
When we showcased the platform to major OEM partners, the signal was real. They did not just approve the concept. They created their own test scenarios and shared API calls with our system for deep-dive validation. That kind of engagement, from engineering teams at that level of scrutiny, does not happen unless the core workflow actually maps to how they think and work.
The project is still active. The platform is in POC and demo phase, with ongoing iteration. But the foundation we built through research and alignment is holding up under real engineering load.
What we learned
You cannot do meaningful UX research on a system you do not understand well enough to ask the right questions about. On this project, I had to learn enough about automotive software validation to recognize when an engineer's answer revealed a real constraint versus a preference. That took time and it was worth every hour.
The second lesson: in complex enterprise products, alignment is the design work. The user flows and journey maps I delivered were outputs of months of stakeholder work, not starting points. Getting every person in the room to agree on what the system needed to do before a single pixel was placed made every downstream decision faster, cheaper, and more grounded.
Some details in this case study have been abstracted to protect confidentiality. The research methods, findings, and design process are accurately represented.
