The Power of Knowing Before Building
Context (The Business):
The electric vehicle (EV) business within this Fortune 50 Oil and Gas company was divided into home and commercial lines of business. This project focused specifically on the commercial segment, particularly on-the-street charging stations, with an emphasis on internal operations. Internal operators relied on software that had been in use for several years but was plagued by persistent complaints from both internal and external customers.
Project Goals:
The long-term objectives included enhancing customer satisfaction and driving adoption, as even internal users had started turning to competitor solutions. However, the primary goal of this project was to deepen the organization’s understanding of user needs and behaviors, laying the groundwork for future improvements to better meet operational and customer expectations.
Research Goals:
Understand and document the current architecture of the product.
Define the existing jobs-to-be-done by internal users.
Identify potential future workflows to address evolving needs.
Role:
As the Senior UX Researcher on this project, my focus was on gathering insights from internal stakeholders and users, while external customer perspectives were explored in parallel efforts. This project was internal-facing, with a cross-functional team that included a UX Director and Leads from Product Management and Engineering.
Timeline:
The project spanned four months.
Why this case study?
As researchers, we often hear statements like, "Research takes too much time," or "Research is expensive." However, this case study demonstrates how research can actually reduce development time and costs. When incorporated early in the product development process, research helps mitigate risks effectively.
As a pragmatic researcher, my goal is to efficiently conduct thorough research that meets both user and business needs. Simply put, involving researchers early ensures you avoid the issues outlined below.
Approach
Current state analysis
First, I needed to understand the product's current architecture. While I can't share the full architecture here, I can describe its structure: the product was composed of seven smaller mini-applications.
The primary issue with this product was the absence of a cohesive UX strategy. This deficiency caused significant breakdowns in both its architectural design and front-end implementation. The development culture resembled a "Frankenstein" approach, characterized by:
Five distinct UIs across the mini-applications.
No cohesive workflow structure, meaning the product wasn't organized around user journeys or real-world components like chargers or networks.
Product managers working in silos, each focusing solely on their own mini-application(s), without coordination or alignment.
Approach
Methodology implementation and choice
Interviews: I conducted eight internal interviews with users/customers. These participants were chosen based upon their role within the currently understood journey phases.
Methodology: I used a combination of a virtual whiteboard and discussion guide when interviewing participants. The whiteboard contained the journey phases on top.
I asked questions that began with uncovering the ideal state: what does the user want to be able to accomplish in each step along the way?
Given this desired state… How is it currently being accomplished?
Given this desired state… What are the challenges in accomplishing it?
Analysis
During the course of the project, funding cuts led to the loss of access to some critical research tools, including Dovetail. With affinity mapping no longer an option due to the complexity and volume of interview data, I adapted my approach. Given the time available, I decided to conduct a deeper, more granular analysis that would also provide secondary value to the team.
I listened to each recording and reviewed every transcript to extract “atomic-level” observations. These insights were then recorded and tagged in Airtable. By utilizing Airtable’s functionality—such as grouping, filtering, and custom views—I was able to synthesize the observations in meaningful ways and deliver actionable insights to the team.
Outputs
Development of a Research Repository: Underpinnings
Below is a snapshot of the developed Research Repository, along with a graphic on the right explaining its architecture.
One Study may consist of several sessions, each involving multiple participants.
One Participant may contribute multiple observations, which will be distilled into findings.
The repository captures the relationships between these elements:
1:1 (One study to one session)
1:M (One session to multiple participants)
M:1 (Multiple participants to one observation)
M:M (Multiple sessions to multiple findings)
This structure allows for efficient categorization and retrieval of insights across different levels of analysis.
Outputs
Research repository: a snapshot
Outputs
Jobs-to-be-Done
Based on data collected from interviews in the form of whiteboard sticky notes and interview recording atomic observations, I developed two core jobs:
Operational and Technical support across the journey/value chain.
Account Management once networks are in Operations.
Additional outputs provided (not shown): additional outputs included user pain points, competitor solutions
Impact & Insights
Pain points and challenges were more significant than expected.
Challenges went beyond a poor user experience. Users were frustrated by not being able to accomplish key operational tasks.
A mismatch between architecture and real-world meant lack of efficiency across the journey, affecting front-end customer experiences.
There were parts of the product users were no longer using (and had built work arounds for) due its poor performance.
Potential, new internal users had chosen not to use the company software and purchased competitor software due its poor performance.
Foundational jobs-to-be-done uncovered.
Suggested future work
If the product team decides to move forward with redesigning the product, I would recommend testing user mental models of workflows using low-fidelity prototypes.
The first mental model test would focus on the task-oriented journey, moving from pre-commissioning to monitoring.
A second test would examine the same set of tasks, but through the lens of business-related components (e.g., networks, stations, chargers).
In parallel, a thorough analysis should be conducted to assess the current usage of workaround applications and tools. This will help determine whether these applications should be integrated into the redesigned product or whether they’ve matured enough to function independently.