01 — Overview
Project Overview
Epicor BisTrack is a leading ERP platform used by building materials distributors and retailers across the UK and US. The Sales Order Entry module is one of the most frequently used features — used dozens of times daily by inside sales reps, counter staff, and order management teams to process complex B2B orders.
Despite being the heart of the business, the module was running on a legacy Windows desktop interface — a form-heavy, click-intensive UI that hadn't been fundamentally redesigned in over a decade. As the product migrated to a web-based architecture, this became the flagship modernization project.
I was brought in as the sole UX designer and co-lead frontend engineer. My job was to own the design, validate it with real users, and then help build it — end to end.
02 — The Problem
A Legacy System Failing Its Users
The existing Sales Order Entry module was a Windows desktop form with 40+ input fields visible simultaneously, no contextual guidance, no real-time validation, and a deeply non-intuitive workflow. Every order required a CSR to navigate through multiple nested modals, remember non-obvious keyboard shortcuts, and fix errors only revealed at submission.
During our first research visit, I sat beside a senior CSR — 11 years at the company, one of their fastest order processors. I watched her switch screens 8 times in under 4 minutes to complete a single order. She had a handwritten cheat sheet taped to her monitor listing keyboard shortcut sequences she'd memorised just to survive the daily volume. When I asked her what she'd change, she paused and said: "I've stopped thinking about changing it. I just try not to make mistakes." That moment shaped every design decision that followed.
Legacy Windows ERP — Sales Order Entry
What users dealt with daily
40+ fields visible on one screen simultaneously
No real-time validation — errors shown only on submit
12+ mouse clicks required for a simple order
Critical data (stock levels, pricing) required switching to a different screen
No auto-save — power failure = lost order
Completely unusable on tablets or laptops
Business pain
Avg. 8–12 min to process one sales order
High training time — 3+ weeks for new CSRs
30+ support tickets/day from order errors
Revenue risk from delayed or incorrect orders
Staff frustration & high turnover among CSRs
Customer complaints from delayed confirmations
"I have to use this thing 60 times a day. Every single order feels like I'm fighting the software instead of helping the customer."
— Inside Sales Representative, User Research Interview
03 — My Role
End-to-End Owner: UX + Frontend
This project was unique because I didn't just design it — I helped build it. My role spanned the full product lifecycle, which gave me a rare perspective: I could validate design decisions against technical constraints in real time, and push back on engineering shortcuts that would have hurt the UX.
01
User Research
Interviews, observation sessions, and workflow audits with CSRs, counter staff, and managers
02
Journey Mapping
Mapped 15 end-to-end order scenarios, identified 40+ friction points and UX debt
03
Wireframing
Low-fidelity sketches → mid-fi wireframes → high-fi Figma prototypes with 5 iteration rounds
04
Usability Testing
Moderated sessions with 12 users across 3 roles; unmoderated remote testing via prototype
05
Frontend Build
Built Kendo UI components, form validation logic, and API integrations alongside engineering team
06
Ship & Iterate
Phased rollout, live monitoring, post-launch interviews, and 3 rapid follow-on iterations
04 — Goals
What We Were Trying to Achieve
Before a single wireframe was drawn, I worked with the product manager, business analysts, and customer success team to align on a clear set of success criteria. These became the north star throughout the project.
G1
Reduce order entry time from 8–12 min to under 4 min for a standard order
G2
Eliminate preventable submission errors through inline validation and contextual guidance
G3
Surface critical data in-context — stock, pricing, customer history — without switching screens
G4
Reduce new CSR onboarding time — from 3 weeks to under 1 week for Sales Order tasks
G5
Cut support ticket volume related to order errors and UI confusion by 60%+
G6
Build a reusable component foundation — form patterns that extend across the ERP suite
05 — UX Challenges
The Hard Problems We Had to Solve
This wasn't a simple redesign. The Sales Order module carries significant business complexity — pricing rules, stock allocation logic, customer-specific terms, multi-branch ordering, and partial fulfillment — all of which had to be reflected in the UI without overwhelming the user.
Extreme Information Density
A single sales order can involve 30–50 line items, each with pricing tiers, stock status, discount overrides, delivery splits, and notes. Showing everything is overwhelming; hiding it causes errors. We had to design a smart progressive disclosure system that revealed complexity only when needed.
Speed vs. Accuracy Trade-off
Experienced CSRs needed to process orders rapidly — any additional confirmation step or UX friction was a workflow regression. But new users needed guidance guardrails. We had to design a system that adapted to expertise level: minimal friction for power users, protective scaffolding for novices.
Real-Time Data Dependency
Stock levels, pricing, and customer credit limits change in real time. Any field in the order form might trigger backend recalculations that cascade across the UI. We had to design optimistic UI patterns and clear loading/error states that didn't break the user's flow.
Legacy Mental Models
Users had 5–15 years of muscle memory on the old interface. A clean-sheet redesign risked breaking that muscle memory and triggering resistance. We had to modernize the workflow while preserving enough structural familiarity that power users could adapt quickly.
Technical Constraints from Legacy Backend
The underlying business logic was a 15-year-old ASP.NET backend. Some API responses were slow (200–800ms for pricing lookups), some data wasn't available in the format the new UI needed, and some fields were deeply coupled in ways that constrained the UX. I had to work directly with engineers to identify what was changeable and design around what wasn't.
06 — UX Strategy
Four Design Strategies That Drove the Solution
After synthesizing research findings and aligning on goals, I developed four core design strategies that shaped every major decision — from layout to interaction model to error handling.
Strategy 01
Progressive Disclosure — Show Less, Do More
Restructured 40+ fields into a smart split-panel layout. Primary fields visible by default; advanced options (delivery splits, override pricing, notes) revealed contextually through expandable panels and smart defaults.
WHY
Research showed 70% of daily orders used only 12–15 fields. Yet every user had to visually parse 40+ fields for every order. The cost wasn't complexity — it was the constant cognitive load of ignoring what didn't apply. Hiding low-frequency fields behind progressive disclosure cut visual noise without removing any capability.
- Split-panel layout: left for order structure, right for line-item details
- Collapsed sections for rarely-used fields (auto-expanded when relevant)
- Smart defaults pre-fill 60% of fields based on customer history
- Quick-add mode for repeat orders (90% same as last time)
Strategy 02
Inline Validation & Real-Time Feedback
Moved validation from submission-time to field-level, with clear visual feedback on every input. Errors no longer surface as a wall of messages at the end — they're addressed in the moment, in context.
WHY
In observation sessions, users routinely hit 'Submit' and faced 6–10 error messages at once. They'd scroll back up, locate each field, then fix it — often losing track of what data they'd already entered. We measured this error-recovery loop adding 2–4 minutes per failed submission. Moving validation to the field level eliminated the loop entirely.
- Field-level validation on blur, not submit
- Real-time stock status badges next to product search
- Inline price override warnings (flagged, not blocked)
- Unsaved changes indicator + auto-save draft every 60s
Strategy 03
Contextual Intelligence — Data When You Need It
Surfaced the right data at the right moment. Stock levels appear when you search a product. Customer credit status appears when you select a customer. Pricing history appears when you hover a price field. Zero extra clicks.
WHY
The most-requested feature in every interview wasn't a new feature at all — it was "don't make me leave this screen." Every context switch broke the user's mental model of the order in progress. CSRs reported that by the time they'd navigated to a stock check and back, they'd lost their place. The solution wasn't more data — it was data in the right place at the right moment.
- Customer panel: credit limit, payment terms, last 5 orders
- Product autocomplete with inline stock status and price
- Delivery address smart selector (most-used first)
- Order total updates live as line items change
Strategy 04
Power User Acceleration — Speed Without Sacrifice
Designed for the 80% case (standard order) to be very fast, while keeping full complexity accessible. Power users can move from customer selection to submitted order in under 3 minutes using keyboard-optimized flows.
WHY
Our top 20% of users processed 80+ orders per day. A 30-second reduction per order saved them 40 minutes daily — a meaningful productivity gain. But they were also our most resistant-to-change users. We couldn't afford to slow them down with a learning curve, so we designed a system that could match their muscle memory from day one and reward deeper expertise over time.
- Full keyboard navigation (Tab, Enter, arrow keys throughout)
- Duplicate order flow: clone a previous order in 2 clicks
- Quick product search with barcode scanner support
- Saved order templates for recurring order types
Fig 1 — Final Figma design: split-panel Sales Order Entry with inline validation, contextual customer panel, and real-time pricing.
Iteration History — 5 Rounds of Wireframes
Round 1: Single-column form. Round 2: Two-panel layout. Round 3: Progressive disclosure added. Round 4: Keyboard navigation tested. Round 5: Final polish with edge-case states.
Fig 2 — Wireframe evolution across 5 iteration rounds, each validated with users before moving forward.
07 — Engineering Thinking
Where UX Met Code
Because I was co-building what I designed, I could make decisions that most UX designers can't — catching technical debt before it became a UX problem, designing within real performance constraints, and writing component APIs that matched the design system intent.
Engineering Contributions
What I built alongside the engineering team
- Built Kendo UI Grid component with custom cell rendering for line-item table (inline edit, delete, reorder)
- Implemented real-time product autocomplete with debounced API calls (300ms) and optimistic stock-status display
- Authored client-side form validation layer using vanilla JS — zero library dependency, fully accessible
- Built progressive auto-save system using localStorage + backend draft endpoint — no lost orders on browser crash
- Created reusable "Customer Detail Panel" Angular component — adopted across 4 other modules after delivery
- Wrote SQL query optimizations for pricing lookup that reduced API response from 800ms → 120ms (avg)
- Documented all Kendo UI customizations in the internal design system Figma library + README
One of the most impactful engineering decisions I made was convincing the team to implement an optimistic UI pattern for line item additions. Instead of waiting for the API to confirm an item was added, we'd render it immediately in the grid and roll back with a clear error state if the API failed. This made the UI feel 3× faster than it actually was — a perception win that users noted in post-launch interviews.
"Having a designer who could review PRs and catch issues before they shipped was completely new for us. It changed how we thought about UX handoff."
— Senior Frontend Engineer, Epicor BisTrack
08 — Before / After
Legacy vs. Modern — Side by Side
The visual transformation was dramatic — but more importantly, the workflow transformation was fundamental. Here's the comparison across the dimensions that matter.
Single-screen form with 40+ fields visible simultaneously
No real-time validation — errors revealed only on submit
12+ clicks to complete a standard sales order
Stock & pricing info required navigating to a different screen
No auto-save — incomplete orders lost on crash or accidental close
3+ weeks to onboard new CSRs to order entry tasks
Desktop-only — completely broken on tablets and smaller screens
Generic UI patterns with no Epicor branding or design consistency
Smart split-panel: primary fields visible, complex fields revealed contextually
Field-level inline validation on blur — errors resolved in the moment
3 clicks for a standard order; full keyboard navigation for power users
Stock, pricing, and customer history shown inline — no screen switching
Auto-save draft every 60s + localStorage persistence — zero order loss
New CSRs productive on day 3 — guided UI reduces learning cliff
Desktop-first responsive — functional on tablets for warehouse use
Built on design system tokens — consistent with all other web modules
Visual Before / After Comparison
Left: Legacy Windows form — cluttered grid of input fields, modal dialogs, no visual hierarchy.
Right: Modern web interface — clean split panel, clear typography, contextual sidebar, inline product search with stock status.
Fig 3 — Side-by-side screenshot comparison: legacy Windows desktop ERP (left) vs. redesigned web interface in Epicor BisTrack (right).
09 — Impact
Measurable Results Across Three Dimensions
We measured impact across UX, engineering, and product dimensions — using a combination of analytics, support ticket data, and post-launch user interviews. Results were tracked over 3 months post-launch.
75%
Fewer Support Tickets
UX Outcomes
Order entry time: 8–12 min → under 3 min (65% reduction)
Task completion rate improved from 71% → 94% (first-attempt)
New CSR ramp time: 3 weeks → 5 days for order tasks
User satisfaction score: 4.7/5 avg (up from 2.1/5)
Zero order-loss incidents post auto-save launch
Engineering Outcomes
Customer Detail Panel reused in 4 other modules — 60% dev time saved
Pricing API response: 800ms → 120ms (query optimization)
0 critical post-launch bugs in first 30 days
Validation layer adopted as standard across all forms
Design system components added: 12 new reusable tokens
Product & Business Outcomes
Support tickets from order errors: 30/day → 7/day (75% reduction)
Feature adoption: 97% of CSRs using new interface within 2 weeks
Zero rollback requests — full adoption in 4 weeks
Project cited in Epicor product roadmap as modernization reference
2 enterprise customers extended contracts referencing UX improvements
10 — Reflection
What I Learned
This project reinforced something I now believe deeply: the best UX work happens at the boundary between design and engineering. The decisions that had the most impact — optimistic UI patterns, the auto-save system, progressive disclosure tied to real API response times — were only possible because I understood both sides of the problem.
Speed is a UX feature
A beautiful UI that feels slow is still a failure for power users. Optimizing API response time and adding perceived performance (optimistic UI) were UX decisions that happened to be engineering problems.
Test with real data, not sample data
Our prototypes looked great with 5 line items. Real orders had 40. Our first usability test with production data revealed 3 layout bugs we'd missed completely. Always test with scale.
Legacy mental models are assets, not obstacles
Our most resistant users became our biggest advocates — once we preserved the structural logic they'd internalized, just made it faster. Familiarity + improvement > novelty for enterprise users.
Design systems pay compounding dividends
Every component we built with care became a shared asset. The Customer Panel, the validation layer, the form tokens — all reused across the suite. Good foundational work multiplies value over time.
If I were to do this project again, I'd push even harder for a phased rollout with a feature flag — letting users opt in to the new UI before the hard cutover. We did a 2-week parallel run, but more transition time would have smoothed the mental model shift for our most experienced users.
"This is genuinely the best software experience we've had in our 8 years using BisTrack. My team actually looks forward to using it now."
— Operations Manager, Enterprise Customer (post-launch interview)
11 — What I'd Improve Next
If We Continued, Here's What I'd Build Next
Shipping the redesign was the start, not the end. Post-launch interviews and usage analytics surfaced a clear set of opportunities. These are the five areas I'd prioritize in the next phase — each grounded in observed user behaviour, not feature-request lists.
01
AI-Assisted Order Entry
Use the order history database to train a suggestion model. As a CSR selects a customer, surface the 3 most likely line items based on seasonal patterns and past orders. The goal: get a standard repeat order to near-zero manual input.
02
Predictive Delivery Date Intelligence
Current delivery date is manually entered. Real warehouse data (stock location, delivery routes, current load) should drive an intelligent suggested date with confidence indicators — reducing customer complaints from missed ETAs.
03
Manager Analytics Dashboard
Managers currently have no live visibility into the order pipeline without pulling reports. An embedded real-time dashboard — orders in progress, stuck orders, error rates by CSR — would surface operational issues before they escalate.
04
Full WCAG 2.1 AA Accessibility Audit
We shipped with solid keyboard navigation and basic ARIA labels, but a formal screen reader audit and focus-management review is overdue. Several complex interactions (the line-item grid, modal dialogs) need more robust accessibility patterns.
05
Offline / PWA Mode for Warehouse Counter
Counter staff in warehouse environments deal with intermittent connectivity. A service worker + IndexedDB layer would let them start and edit orders offline, then sync on reconnect — eliminating the last paper-based workaround still in use.
