galls
uniform configuration,
collapsed into one screen
Agency compliance rules, embroidery logic and placement standards for U.S. Army and Air Force buyers were spread across several pages. Buyers had to commit to choices before they could see the result. We pulled the whole configuration into one screen.
- my role
- UX strategy & system architectureInteraction design & prototyping
- team
- 1 head of design3 engineers1 UX designer (me)
- users
- U.S. ArmyU.S. Air Force procurement
- status
- Live on Galls.comOngoing since Feb 2025
Two quarters after launch.
+22%
more orders included customisation
26%
faster to configure an order
+17%
more customisable orders reached checkout
MEASURED. Production analytics, comparing the two quarters after launch against the two before, on the same product set.
this was never a
customisation feature
Galls' Uniform Service Program supplies agencies, not individuals. A single order carries agency compliance rules about what insignia may appear where, embroidery logic that varies by garment and thread, placement standards written by the branch rather than the retailer, and bulk quantities across dozens of personnel.
The site handled all of this by turning every possible combination into its own product listing. A different nameplate, rank, patch or placement meant a different item to find. The buyer's job was to hunt down the right set and hope it added up correctly.
That framing was the real problem. This was never a catalogue to browse. It was a product to configure, and it had been built as the wrong one.
Before: the original customizer. Every option is shown at once and every option looks equally important, so the buyer has to work out the order to do things in.
you couldn't see what you
were building until too late
Nothing showed the finished uniform until the cart.
A buyer picked the garment on one page, the insignia on another, the placement on a third and the quantity on a fourth. Nothing warned them if a combination broke an agency rule. Two groups paid for that, in different ways.
the buyer
- Had to remember every choice while moving between pages
- Only found mistakes at checkout, when they cost the most to fix
- Was ordering for dozens of people, so one error multiplied
the business
- Staff had to correct wrong orders by hand
- Customers gave up most often on the products worth the most
- Every new rule added more listings instead of more capability
three ways to fix it.
two were wrong.
The obvious move was a better options panel. It would have been faster to build and it would not have worked, because the problem was never that the options were badly presented.
improve the existing single page
Better grouping, better labels, sticky summary. Cheapest option and the one most people expected. Rejected because it preserves the actual failure. Every decision still competes for attention with every other decision, and a buyer configuring for a whole unit is not short of information, they are short of sequence.
Rejected: treats the symptoma multi-step wizard across separate pages
Sequence the decisions properly, one page each. Solves ordering, but keeps the context switching that was already the expensive part, and makes reviewing or revising an earlier choice a navigation task. On bulk orders where buyers routinely go back three steps, that is a worse trade than it looks.
Rejected: sequence without continuityone full-screen checkpoint, stepped inside it
A single overlay that holds the entire configuration — sizing, fabric, identity, branding — grouped into logical clusters and stepped through without leaving the view. The buyer keeps the assembled garment in sight the whole time, validation runs live, and nothing is committed until the whole thing resolves.
built
The structural change. Not fewer decisions — the same decisions, made in one place, with the consequence visible while they are still reversible.
one checkpoint, three
clusters, live validation
grouped by the decision, not the database
Identity (nameplate, rank, unit), fit (size, cut, fabric) and branding (patches, placement, thread). Three questions instead of thirty fields.
compliance as rules, not SKUs
Agency constraints run as validation against the configuration, so an invalid combination is caught while it is being made rather than manufactured into the catalogue.
the garment stays on screen
Every selection updates a live preview with placement shown in position, which is what turns an abstract choice into a visible one.
nothing commits until it resolves
The checkpoint is a boundary. Inside it everything is revisable, and crossing it means the order is complete and compliant.
AI-assisted exploration, early only
Prompt-built variants let the team look at four real alternatives in the time a single mockup used to take. It compressed the ideation loop. It did not decide anything.
bulk is a first-class case
A configuration is a reusable object, so ordering for a whole unit is one configuration applied many times, rather than many passes through the same flow.
Mobile. The same single checkpoint, stepped — the preview stays anchored above the controls so the consequence of each selection is never off-screen.
Desktop. Options on the left, assembled garment on the right, total and validation state always visible.
Placement labelled directly on the garment. Buyers stopped asking internal teams where a patch was allowed to go, because the answer was on the screen.
what I'd prove next
most buyers still don't customise
More of them do than before, but the majority still skip it. I don't know whether that's because they don't need it or because they never notice it's there, and the analytics we have can't tell those two apart.
I never measured mistakes directly
We could see that staff were fixing fewer orders by hand, and assumed that meant fewer errors were being made. That is a reasonable guess, not a measurement. The system should track wrong configurations properly so we would know.
only engineers can add new rules
When an agency changes what is allowed, it takes a developer and a release to update it. Until the operations team can make that change themselves, every new client creates engineering work.
the parts that didn't
make the page
The rule model went through four versions before it held. Happy to walk through it, and through what I'd change now. The same idea — replace a library to browse with a decision to configure — carries into the next project, in a different domain.