Redesigning a 30-Year-Old Store Front App for Tablet-First Experience

ROLE

UX/UI Designer

TIMELINE

2026

TL;DR

What started as a reskin became a much larger usability and flow refactoring effort. The project involved redesigning a 30-year-old internal automotive retail system from client-server-application to web-based tablet experience, dealing with constraints from engineering where backend/API changes were out of scope.

The work focused on improving clarity, reducing hidden friction, and restructuring critical flows without breaking the system’s underlying logic. The strongest examples were the refactor of the Service Work Order flow and the integration of the sourcing experience into the new web-based product.

A System That Had Outgrown Its Original Shape

This project focused on an internal system used by store associates to manage sales, services, parts, and related in-store operations within an international automotive retail environment.

The work happened in a cross-functional team, with stakeholders, engineers, and designers collaborating in English across different regions.

The original system had been in use for more than 25 years and was built as a desktop executable. One of the project goals was to redesign that experience as a browser-based application for tablet use in-store. This was not only a visual or technical update. It also supported scale, standardization across stores, and easier rollout, since updates would no longer need to be deployed location by location.

To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study.

The Project Changed After The First Demo

The first stakeholder demo made it clear that a visual refresh would not be enough.

The proposed screens looked newer, but still carried the same structural issues the system had accumulated over the years. The reading was still heavy, actions were still difficult to find, and the same usability problems remained underneath a cleaner visual layer.

That was the point where the project stopped being a reskin and became a much broader usability and flow problem.

Why The Work Became More Complex

The system was heavily data-driven, with much of its behavior defined by backend logic and shared structures rather than by interface logic.

That created two problems at once.

The first was usability. Actions were often hidden, terminology was inconsistent, and similar tasks behaved differently depending on context. People relied on prior knowledge more than on the interface itself.
The second was feasibility. Backend logic could not be changed, data structures could not be changed, and development was already moving. This meant even small interface changes had to be evaluated in terms of implementation risk.

There was also no reliable documentation, and the original creators were no longer part of the company. Understanding how flows worked required reconstructing them from behavior, existing screens, stakeholder knowledge, and engineering validation.

The Core Challenge Was Judgment

The work was not just about finding bad UX and replacing it with better UX.

It was about deciding where change was possible, where it was too risky, and where the best decision was to preserve structure and improve clarity around it.

That judgment shaped the entire project.

Role in The Project

The work covered flow mapping, interface refactoring, stakeholder validation, and close alignment with frontend engineering.

In practice, this meant identifying where users depended on hidden knowledge, where actions were unclear or hard to reach, and where the interface could be improved without requiring backend or structural changes.

Because reviews happened every week and demos every month, decisions were continuously tested against both stakeholder expectations and implementation reality.

How Decisions Were Made

A few principles remained consistent throughout the project.

Clarity came before reducing steps. Exposing actions was often more valuable than aggressively minimizing interactions. And when a cleaner interaction model introduced too much technical risk, preserving structure was usually the better decision.

This was especially important in a legacy product where one local improvement could create problems in another part of the system.

SWO Became The Clearest Example of The Work

The Service Work Order flow was one of the most critical parts of the system.

It was the screen where associates reviewed what the customer had purchased, what services had been requested, assigned technicians to services, printed the order, and moved the order toward completion. It needed to support a lot, but it was difficult to read and depended too much on prior familiarity.

The refactor focused on making the structure clearer without reducing the functional depth of the screen. Actions were regrouped by type, such as services and parts, while keeping relevant categories visible. More than 20 functions were reorganized into an interaction model that could be navigated within a maximum of three interactions.

This was one of the most positively received changes in the project because it improved legibility and practicality without weakening what the flow needed to support.

Other Changes Followed The Same Logic

The sourcing experience was another good example.

Part of the old system relied on a hosted web layer opened from inside the executable. In practice, this created a disconnected experience for stock, sourcing, and inventory-related actions.

As the product moved to the web, this became an integrated part of the browser-based system instead of something opened separately. The improvement was not that the work became simpler, but that it became more coherent. The interaction no longer felt like leaving one system to enter another in the middle of a task.

Smaller changes reinforced the same pattern. In the Oil Change flow, for example, the number of interactions was reduced from 12 steps to 4 when the system allowed that level of simplification.

Not Every Problem Was Solved

And That Was Part of The Job

Some parts of the system could not be redesigned in the way a cleaner product would ideally require.

In those cases, the work focused on improving labels, structure, and visibility while preserving the underlying behavior. A good example was comment handling inside SWO: from a usability perspective, a unified model would have been better, but the system could not support that safely, so the legacy structure had to remain.

This happened repeatedly across the project. Some ideas were reduced. Some were postponed to Phase 2. Some inefficient patterns remained because changing them would have created more risk than value in the current release.

It was part of working responsibly within the conditions the system imposed.

Design System As An Enabler

One important part of making the project viable was the design system.

It worked closely with Angular, Material, and AG Grid, which helped speed up delivery, reduce rework, improve consistency, and make handoff more actionable. Components were documented in a way that supported implementation directly, which made alignment with engineering more effective throughout the project.

This mattered because the design system was not just a visual layer. It supported feasibility.

What Changed on This Phase

This phase has not yet gone through full field validation, and Phase 2 is planned to incorporate what is learned once the redesigned product is used in practice.

Even so, the current phase already changed several things:

the project moved beyond a reskin.
critical flows became easier to read and operate.
hidden usability problems became more visible to stakeholders.
engineering gained clearer documentation and stronger implementation guidance.
the new browser/tablet direction created a more scalable operational foundation.

Stakeholder feedback reflected that shift. Some of the strongest reactions were not about aesthetics, but about finally seeing usability problems that had existed for years without being named clearly.

Phase 2 - What Comes Next

Phase 2 is intended to go further than the current release could.

Its purpose is to address what can only be corrected once the product is live in the field and to refactor areas where deeper data-driven constraints still limit the experience.

That makes the current phase important for two reasons:

It improved the product where change was feasible now, and it clarified what the next phase will need to solve more structurally.

Summary

This project began as a reskin and became a broader redesign effort once it became clear that visual change alone would preserve the same usability issues the system had carried for years.

The work involved redesigning a 25-year-old internal automotive sales and service system from desktop executable to browser-based tablet use, within a global team, under fixed backend and structural constraints, while development was already underway.

The strongest improvements came from flow refactoring, clearer structure, better exposure of actions, and decisions grounded in feasibility rather than idealized redesign.