Skip to content
Jonathan HeavnerProduct & Systems Designer

03Operational modernizationAuto Wares, contract · Feb 2024 – Aug 2025

CounterWorks

Modernizing a mature inventory and point-of-sale system without disrupting established customer operations.

“I have 5 windows open; which customer was in this window?”

Store observation · 2024A counter employee
Two people at a red parts-counter: one operating a terminal, phone, and register, the other leaning over a battery box on the counter. Store signage in the background., enlarge to full resolution
The work happened here, not inside the application. Every interruption changed priorities, but customers still expected the conversation to continue exactly where it left off.
Problem
Counter staff build multi-item, multi-vehicle orders while customers wait, and orders change mid-flow. The legacy system kept one order per window, so staff opened a new instance of the app for each customer and kept track from memory.
My role
Lead designer, end-to-end UX and UI, working with product, business, and engineering.
Key decision
Replace one app instance per customer with one workspace: each customer gets a tab, each tab can hold several vehicles, and switching never resets the work.
Outcome
Shipped as an Electron desktop application. After launch, staff reported less context switching and less reliance on memory and workarounds.

01

Firsthand observation

Method
Observation during live transactions

Before changing the interface, I spent time behind the counter watching parts specialists work during live transactions.

Orders rarely followed a straight line, conversations overlapped, interruptions were constant, and work was spread across memory, paper, handheld devices, and multiple terminals because the software couldn’t keep pace with the job. Staff opened a new instance of the application for each customer and switched between them.

I focused on how they built orders, when they paused or hesitated, where errors occurred, and how they handled pricing questions. A clear pattern emerged: employees worked around the system, developing habits to compensate for gaps in the interface. They needed software that matched how they already worked.

A counter workstation running the legacy software on a monitor, beside a phone, keyboard, and calculator on a red counter, with a busy parts-store aisle behind it., enlarge to full resolution
A counter workstation: the legacy software beside a phone and a calculator. Multiple systems, multiple conversations, constant movement between tasks.
Two rugged tablets and a phone resting on the red store counter beside supply boxes., enlarge to full resolution
Rugged tablets and a phone kept within reach on the counter: more devices to switch between during a single transaction.

02

Parallel customer and order workflows

Most interactions happen while a customer is standing at the counter. Speed and accuracy both matter.

  • Multi-item orders
  • Multiple vehicles per customer
  • Real-time inventory checks
  • Pricing overrides and discounts

The software treated interruptions as exceptions. Counter work depends on interruptions. Mechanics called back. Commercial customers placed multiple orders. Parts needed verification. The interface forced specialists to rebuild context every time work changed direction.

What the observation showed

  • Only one customer order could remain active at a time.
  • Switching customers meant rebuilding context from memory.
  • Catalog searches interrupted active work instead of supporting it.
What I saw at the counter, and the model that replaced it.

Before

The legacy Windows invoicing screen: a dense grid of order-entry fields, a top menu bar, and a single active transaction., enlarge to full resolution
Original systemThe legacy invoicing screen: one transaction per window, its fields spread across one dense grid.

After

The CounterWorks order workspace with six customer tabs across the top, the active order's line items grouped by vehicle, and an order summary panel; prices are masked., enlarge to full resolution
Shipped productThe redesigned workspace: every customer in a tab, the active order grouped by vehicle.

03

Multi-tab interaction model

The turning point was reframing the experience from multiple windows into a single workspace.

Instead of opening a new instance of the app for each customer, each customer had their own tab within a single window. Counter staff could switch context instantly without losing their place, and a single customer tab could hold several vehicles, which matched how real orders and quotes actually worked.

Switching customers shouldn’t reset your work. It should feel like turning your head and looking at another order that’s already waiting.

Decision 01

One window, a tab per customer

BecauseStaff were opening a new instance of the app for each customer and losing track of which window held whom.

Trade-offThe product, not the operating system, now has to manage many open orders at once.

A tab strip with a New button and customer tabs, each showing a customer name, a vehicle, and a status icon, beside an iconography key and an overflow list of further customers., enlarge to full resolution
Design specThe multi-tab model: one tab per customer, each showing its vehicle and status (in progress, quote, invoice, fixed bid, parts on hold), with an overflow list once the strip is full.

Worked out in wireframes first

  1. 1An earlier direction

    An early wireframe of a quote screen with browser-style tabs, a top utility bar, a parts table, and placeholder notes text., enlarge to full resolution
    WireframeAn earlier concept explored browser-style tabs and a top utility bar.

  2. 2A new order beside the current one

    A wireframe of a New Order tab, opened beside an existing customer tab, with a parts search bar and a list of frequently used customers., enlarge to full resolution
    WireframeStarting another order without leaving the first: a New Order tab (Ctrl+N) opens beside the customer already in progress.

  3. 3Saved quotes and open invoices

    A wireframe of a Saved Quotes and Open Invoices view inside a tab, with a search field and a list of recent quotes showing items on hold., enlarge to full resolution
    WireframeSaved quotes and open invoices, reached from the same tab strip, with items on hold flagged in the list.

Decision 02

Several vehicles inside one customer tab

BecauseThat matched how real orders and quotes actually worked at the counter.

Trade-offOrders group line items by vehicle, so the order view has to keep each group scannable.

The CounterWorks order workspace with six customer tabs across the top, the active order's line items grouped by vehicle, and an order summary panel; prices are masked., enlarge to full resolution
Shipped productSix customers open in one window. The active order groups line items by vehicle beside an order summary.

04

Redesigned orders experience

Once everything lived in one place, the rest of the experience could be simplified.

  • Order details consolidated into one view to reduce context switching
  • A clear pricing summary for fast verification
  • Information structured to follow the natural flow of a transaction
  • Fewer steps for common actions
  • Progressive disclosure, consistent action placement, and inline feedback for pricing and changes
  • Catalog search embedded in the customer’s tab, with side-by-side comparison and instant add-to-order

The catalog stopped being a separate tool and became part of the order itself: results appear in the same tab as the active customer, so search, filtering, comparison, and adding to the order happen without a window change or a mental reset.

The Search Orders screen: filters for order number, purchase order, date and status on the left, a list of recent orders, and the selected order's line items grouped by vehicle., enlarge to full resolution
Shipped productSearch Orders: filters, recent orders, and a selected order’s detail in one view, with the customer tabs still open above.

Decision 03

The catalog lives in the active customer’s tab

BecauseThe old catalog was a separate third-party window that pulled specialists away from the order.

Trade-offAdvanced fitment detail is deferred until it is needed, so the order stays primary.

The integrated catalog inside a customer's tab: the vehicle at the top, and categories, groups, and part types chosen in three columns., enlarge to full resolution
Shipped productThe integrated catalog, inside the active customer’s tab: categories, groups, and part types narrowed against the vehicle already on the order.

Before

A separate third-party catalog window titled 'Cover to Cover Information' showing one part's details, floating over the legacy invoicing screen., enlarge to full resolution
Third-party catalogThe old catalog: a separate third-party window over the invoicing screen, with its own look and behavior. Parts were moved into the order by hand.

After

The integrated catalog inside a customer's tab: the vehicle at the top, and categories, groups, and part types chosen in three columns., enlarge to full resolution
Shipped productThe new catalog, inside the customer’s tab with the vehicle already known.

  1. 1Catalog search, in wireframe

    A catalog wireframe: the customer and vehicle at the top, and categories, groups, and part types chosen in three columns., enlarge to full resolution
    WireframeThe catalog worked out in wireframe first: the vehicle stays at the top while categories, groups, and part types narrow the search.

  2. 2Catalog results, in wireframe

    A catalog results wireframe with brand filters on the left and a parts list with availability, quantity, price, and add-to-order actions., enlarge to full resolution
    WireframeResults with filters beside them and an add-to-order action on every row, so a part goes straight into the open order.
Catalog results for brake rotors with a product-details panel open beside them, showing specifications and product photographs., enlarge to full resolution
Shipped productProduct details open beside the results, so supporting information never replaces the list or the order.

05

Shipped Electron application

The interface was built with Angular and PrimeNG components for faster development, consistency, and long-term maintainability, and delivered as an Electron desktop application.

The integrated catalog launched as part of the new CounterWorks platform. Counter terminals are shared, so the shipped application starts with a sign-in that lists who is working at which terminal.

The screens show the store name Bumper to Bumper and a CBCS copyright line, as they appeared in the software, with sample customers and masked prices.

Try an interactive reconstructionRebuilt for this portfolio with sample data.

The CounterWorks sign-in screen: a list of active users, each assigned to a numbered counter terminal, an option to sign in as another user, and a PIN entry panel., enlarge to full resolution
Shipped productSigning in at a shared counter: active users are listed by terminal, and anyone can step in as another user.

06

Outcome and feedback

  • Faster order completion during peak hours
  • Fewer pricing errors during checkout
  • Less reliance on memory and workarounds
  • More confidence for new employees
  • Less context switching during parts lookup

Looking back, the redesign was never really about tabs or multiple orders. It was about respecting the reality that experienced people rarely work in straight lines. Good software shouldn’t force someone to remember where they left off. It should remember for them.