INTRO
PartsTech streamlined parts ordering, but some service advisors still relied on Epicor ISE for labor operations and vehicle reference information.
I led the end-to-end design of PartsTech EX, a new experience that brought labor, maintenance, fluid and vehicle specifications directly into PartsTech, reducing the need to switch between disconnected tools.
The challenge wasn't just adding new data, it was creating a consistent experience across complex datasets, while the product and data continued to evolve. I partnered closely with product and engineering to define an MVP that delivered immediate value while creating a foundation for future scalability.
ROLE
Sole product designer responsible for leading PartsTech EX from discovery through launch. I partnered closely with product and engineering to define the MVP and design scalable experiences around evolving partner data and technical constraints. I conducted usability testing to validate design decisions and partnered with research to conduct customer interviews.
STATUS
Shipped, 2025
TOOLS
Figma
Miro
Useberry
Userpilot
Results
Within 10 Months of launch we gained:
6 new SMS partnerships that resulted in 600+ net new repair shops on PartsTech and an increase of SaaS revenue.
DISCOVERY
RESEARCH AND DISCOVERY
We approached discovery from two directions: understanding shop workflows and what partners needed to switch.
Shops
Moderated interviews with service advisors to learn:
How they access labor times and create estimates
About their current solutions
Cold-called shops early on to observe real estimating behavior in the wild
Partners & Internal Stakeholders
Sessions with SMS partners to understand switching criteria
Cross-functional interviews with sales, support, product, and engineering to surface ISE integration pain points
Competitive Analysis
Deep dive into Epicor ISE via documentation, knowledge base, YouTube tutorials, and hands-on exploration. This helped us identify bad UX, and also understand the flows and mental models shops already used.
Analyzed labor patterns across supplier competitors to understand what was technically possible outside the Epicor ecosystem.
CHALLENGES
BRIDGING THE GAP BETWEEN HOW USERS THINK & HOW OUR DATA WORKED
Challenge
Repair shops don’t think in individual parts, they think in services and jobs they need to complete. A technician may start with “replace brakes” or “perform scheduled maintenance,” not “find a brake pad.”
Constraint
At this point, our data provider was only willing to provide labor tied to part types and not a full data source. This meant that labor recommendations were dependent on part selection, which meant the ideal service-first workflow wasn’t immediately supported by available data.
Solution
Rather than wait, I designed an MVP that introduced labor at the point where users already had intent: the cart.
The MVP, surfaced labor opportunities within the cart workflow based on the parts in the cart. This allowed users to still reference labor, while establishing a foundation for a future labor-first workflow.
When ideating, the goal is to think out of the box first, then narrow it down.
For the initial version, when a shop had parts in their cart, a prompt appeared to add labor.
Clicking it opened a modal displaying MOTOR labor operations tied to those specific parts.
Early usability testing in Useberry focused on discoverability and the ability to add labor to the cart. We also had a handful of customers that beta tested the first versions of our product.
CREATING A CONSISTENT EXPERIENCE ACROSS DIFFERENT DATA PROVIDERS
Challenge
Different labor providers exposed labor data in fundamentally different ways. While some repair shops had strong preferences for specific providers, they all expected the same reliable workflow inside PartsTech EX.
Constraint
MOTOR and Mitchell used different terminology, hierarchies, and data structures. We discovered Mitchell labor data was significantly more complex, with deeply nested operations and varying levels of detail. Supporting multiple providers required a flexible approach that could accommodate complex datasets without creating separate experiences for each integration.
Solution
Rather than creating provider-specific experience, I designed a scalable framework that could accommodate multiple data structures as integrations evolved. To achieve this, I established a fixed labor hierarchy that reduced information overload and scaled to larger, more complex datasets.
CONNECTING SERVICE INFORMATION WITH PARTS PURCHASING
Challenge
Service advisors often move between understanding a repair and acquiring the parts needed to complete it. On our MVP, labor and maintenance information served as reference only experiences. This meant users had to search for their parts separately within PartsTech, leaving room to better connect the two workflows.
As the product evolved, the opportunity was to create a more connected experience that helped users transition from understanding a repair to selecting relevant parts without disrupting their workflow.
Constraint
Users had different goals.
Not every user viewing a labor operation or maintenance item was ready to purchase a part. The experience needed to provide a natural path into parts search without disrupting users who were only researching information.
The experience needed to build on existing patterns.
Parts search already existed in other areas of the product. Introducing search into labor and maintenance workflows required leveraging existing components and interaction patterns to maintain consistency and avoid creating additional complexity.
Solution
I integrated contextual part type recommendations directly into labor and maintenance workflows, allowing service advisors to review and add relevant part types without leaving the experience.
Once part types were selected, users could continue through the existing sequential search flow to choose the specific parts to add to their cart. By reusing established search components, I created a familiar experience while minimizing additional design and engineering effort.
RESULTS
THE FINAL PRODUCT
What launched as a constrained MVP became a full-featured service.
What initially started as adding labor, became a comprehensive workflow bringing together labor, maintenance, fluids, and vehicle specifications aka service guides. Service Guides became a top-level nav item in PartsTech search, a reflection of how central it became to the product for a key segment of users.
Labor: Full browse by job category with search, parts recommendations tied to each operation, and optional vs. primary operations clearly distinguished.
Maintenance: Filterable by mileage, time, and driving conditions
Fluids: Type, capacity, part number, and grade with quick copy for cross-referencing
Specs: Tabular and procedural specs with progressive disclosure and diagrams
EXPANDING TO SERVICE GUIDES
The initial MVP created a foundation for expansion. As richer data capabilities became available, I partnered with product and engineering to evolve PartsTech EX into a scalable service platform, which expanded from labor into maintenance schedules, fluid specifications, and vehicle reference data under a unified search category: Service Guides.
OUTCOMES
Within 10 Months of launch we gained 6 new SMS partnerships
EstimateXpress launched its first paying SMS partnership in March 2025.
Within 10 months:
6 new SMS partnerships signed
600+ net new repair shops on the platform
$400K in SaaS ARR generated
Two major partnerships signed for 2026, representing 4,200 additional shops
Projected ARR by end of 2026: $1.1M – $2.5M
REFLECTION
Building a constrained MVP to get business partners on board was the right call
This project reinforced the importance of designing for uncertainty. As new partners and data sources came into the product, I learned that creating a scalable experience required balancing immediate customer needs with a longer-term product vision.
One of the biggest contributors to the project’s success was establishing a strong partnership with engineering early. I worked closely with engineers to understand the underlying datasets before designing solutions, allowing us to build around real data structures rather than assumptions. This collaboration helped shape the labor hierarchy and prevented us from creating patterns that would become difficult to scale later.
I also partnered closely with product to separate short-term MVP goals from the broader Service Guides vision. By aligning on what needed to be solved now versus what could evolve over time, I was able to make intentional tradeoffs and help the team move quickly without creating unnecessary UX debt.
The biggest challenge was navigating dependencies outside of our control. Some partner integrations moved slower than expected, which meant we had to continue making decisions without always having complete data. Because I grounded the work in user research, competitive analysis, and customer needs, the product direction remained strong even as external timelines shifted.
If I were to approach this project again, I would prioritize documenting research and design decisions throughout the process. Capturing those artifacts as the work evolved would not only strengthen the case study but also create a more valuable resource for future teams building on the product.