VAS Engineering
How we transformed a 30+ year-old legacy ERP procurement workflow, reducing a 30–45 minute process of juggling data across tools to a single-screen experience in under 10 minutes
Complex ERP Workflows ✦ Enterprise UX ✦ System Thinking
Role
Sole product designer
UX architecture, visual design, marketing campaign, copy
Team
Duration
3 Months
Outcome
The challenge
Redesigning for Speed, Simplicity & Scale
The problem wasn’t a lack of data. It was the lack of a system that could connect it. What should have been a software-supported decision had become a manual exercise in remembering, cross-checking, and validating information.
I’m doing half the work in my head — what’s the point of the ERP if I’m still tracking this manually?
Unpacking the workflow
Understanding the Legacy Decision-Making Flow
Before redesigning, we mapped out the exact journey the stakeholder followed to make a purchasing decision each day. Although the tools and data already existed, they operated in isolation forcing him to rely on memory, manual analysis, and constant cross-referencing to connect the dots.
Friction point 01
The consultation looked blocked
Step
Action
Tool Used
Decision
1
Check needed vs in-stock quantity
Excel
Do we need to order?
2
Check in-hand quantity (after attrition)
Expandable (ERP)
How much to order?
3
Check seasonal demand patterns
Expandable (ERP)
Should we order extra?
4
Filter by quality/material constraints
Expandable (ERP)
Is this the right part type?
5
Open Digikey and evaluate options
Digikey
What & how much to order (unit vs reel)?
Friction point 01
The consultation looked blocked
Process
He starts by comparing the needed quantity (from quotation data) with current warehouse stock in Excel.
If Stock < Needed Qty, he knows he has to place an order — but it’s just the start of a longer check.
Example
For example, if part RES(resistor) 1505-835 is needed but the available stock falls short, then that part needs to be purchased.
Design Opportunity
Could we bring this visibility inside the ERP, eliminating the need for Excel?
Friction point 01
The consultation looked blocked
Process
Then he switches to Expandable ERP to check the actual in-hand quantity, factoring in attrition (tiny components often go missing during export or assembly)
This gives a more realistic sense of how many parts are usable.
Example
For example, the current in-hand quantity is 250, but an expected attrition of 132 pieces needs to be accounted for. This brings the total shortage to 382 pieces—meaning we need to place an order for at least 382 parts.
Design Opportunity
Could we automatically calculate attrition-adjusted stock?
Friction point 01
The consultation looked blocked
Process
He mentally evaluates seasonal demand trends like Easter rushes and decides whether to order just enough or buffer stock.
This insight is tracked by the system & also based on his tribal knowledge.
Example
Here, ordering 382 parts would solve the immediate shortage but not necessarily the next one. The projected demand showed an additional requirement of 1,258 parts, and because orders had lead times and were often delivered in multiple lots, simply ordering enough for the current project could mean the first batch was fulfilled while the next one faced another shortage. Factoring in both the immediate requirement and projected demand meant planning for a total of 1,640 parts.
Design Opportunity
Could we build in a trends layer (based on past ordering data) to help forecast needs?
Friction point 01
The consultation looked blocked
Process
Certain buyers restrict component choices e.g., only accepting resistors of a certain material.
Currently, he either filters this manually in Expandable or remembers the constraints based on client.
Example
For example, the inventory might show enough parts overall, but if only a portion meets the client’s required quality standard, the remaining quantity cannot be used for that order. The purchasing calculation therefore had to account for both the quantity available and the quality type of each part, determining the exact shortage for every eligible variant rather than treating all inventory as interchangeable.
Design Opportunity
Could we flag or pre-filter approved part types based on client rules?
Friction point 01
The consultation looked blocked
Friction point 01
The consultation looked blocked
Process
Final step is logging into Digikey and deciding whether to order individual quantities or reels (bulk).
If trends show likely future demand and the price difference is small, reels are chosen to save on time, cost, and logistics.
Example
Qty
Cut Tap price
Reeling fee
Ext/Total price
5000
$0.00306
$7
$37.60
Qty
Cut Tape/Digi-Reel unit price
Ext/Total price
10,000
$0.00306
$30.60
Cut Tape/Digi-Reel would cost 5,000 ×2 × $0.00306 = $30.60, plus a $7 reeling fee, bringing the total to $37.60. The same 10,000 parts were available as a full Tape & Reel for $30.60. In this case, ordering the reel saves $7, making the larger packaging option the more cost-effective choice even though the required quantity was determined independently of the packaging decision.
Design Opportunity
Could we show real-time Digikey pricing and reel savings within the ERP?
So, Order Quantity ≠ Required Quantity − Available Stock
Order Quantity = (Required Quantity − Available Stock) + Attrition + Projected Seasonal Demand
Once we knew what information actually mattered, the question was how do we bring it together without creating another information-heavy screen?
Layout explorations
Turning the decision-making logic into a single, scannable workflow
With the key variables identified, we began sketching different ways to structure and prioritize the information—exploring what users needed to see first, what could support the decision, and how each step could naturally lead to the next. Through multiple layout iterations, we worked toward bringing a previously fragmented workflow into one clear decision-making experience.
Friction point 01
The consultation looked blocked
Option 1
Everything visible at once
The first exploration attempted to give every major decision area its own dedicated space on a single screen. While this made the information architecture clear, it treated all information as equally important. The result was a dense layout that required users to scan across multiple sections before understanding what information was relevant to their immediate decision.
The challenge
Giving every data point equal space made the structure clear, but the decision path unclear.
Exploration 1: Everything visible at once
Option 2
Navigation-led detail view
The second exploration moved toward a left-navigation model, allowing users to focus on one category at a time. This reduced visual overload, but introduced a new problem: the information needed to make a single purchasing decision became distributed across multiple sections. Users would have to navigate back and forth between inventory, demand, product details, and pricing to build the full picture.
The challenge
Reducing clutter came at the cost of context, critical decision inputs were now separated across multiple views.
Exploration 2: Navigation-led detail view
Option 3 (What we went ahead with)
A Structure that follows the decision
After exploring different ways of organizing the information, this structure provided the clearest path forward. It creates a logical flow from inventory and demand to part details, pricing, and finally the decision, making the next step feel obvious without overwhelming users with everything at once.
Why this worked
It matched how the client already pieced together information across different screens—just in one connected view.
Exploration 3: Organizing the Decision
Lo-fi exploration
Exploring how information, hierarchy, and interaction could work together
The approved layout gave us the structure. High-fidelity explorations helped define how users would distinguish critical information from supporting context, move through each decision, and understand what required their attention at a glance.
Option 1
Heading
The first high-fidelity exploration relied on a longer, scrollable layout to accommodate all the information. But this brought back the very friction we were trying to solve i.e. users still had to move through the screen to connect the information needed for a decision.
Feedback
The goal was to move away from scrolling and bring the complete decision-making context into a single, above-the-fold view.
Initial ideation
The added scroll made key decision points harder to view together
More screen space meant an opportunity to move supporting information aside and give decision-critical data the room it needed
Option 1
Making space for the decision
We moved part-specific, secondary information into a side panel, keeping it accessible when needed without competing with the primary decision points.
What Moved to the Side Panel
Part Details: Attrition, detailed inventory breakdowns, Juki data, expandable stock information, and adjustments.
Costing: Historical purchase prices and the current standard cost for the part.
MPN & Product Data: Manufacturer part numbers and product-specific details—useful when comparing alternatives or validating a particular part, but not needed for every decision
Supporting information, prioritised by relevance
Finalised concept
Making the decision easier to see
The final concept combined a visual representation of the purchasing formula with the key information needed to act on it, from order inputs and pricing to MPN comparisons and sourcing context.
Finalised concept
Minor changes to hierarchy and layout
With the side panel handling the supporting context, the main workspace was designed around the user’s actual decision-making journey
Wireframe of main panel
Organising the main workspace around how users naturally move from data to decision
Finalised main panel
A structured journey from understanding the requirement to making the final purchasing decision
Final concept
What once lived across screens now works as one decision-making flow
…the information is now organised around the decisions users need to make—turning a process that once relied on memory, cross-checking, and manual calculation into a clearer path towards a confident purchasing decision.
The outcome
Less time spent finding information. More time making the decision.
The redesigned workflow brought together information that previously lived across a 30+ year-old ERP, spreadsheets, supplier platforms, and the stakeholder’s own memory. What once took 30–45 minutes of cross-referencing, validating, and manually connecting information could now be reviewed through a single connected workspace in under 10 minutes.
Reduction in time spent reaching a purchasing decision
Tools and information sources brought into one workspace
Disconnected steps streamlined into one decision flow
Learning
What this project taught me
Working on this project changed how I think about complex enterprise products. The legacy system already contained most of the information the stakeholder needed. The problem was that the system didn’t help him understand what mattered, when it mattered, or how one piece of information influenced the next decision.
By mapping the decision step by step, separating primary information from supporting context, and making the underlying calculations more visible, we were able to design around how the user actually thought, rather than simply modernising the screens they were used to.
