EDI
Before H-E-B can put a product on the store shelf, that product’s Supplier has to set it up in our system.
But not all Suppliers use PAM, our product setup app, to do that. Some Suppliers use the Electronic Data Interchange (EDI) 832 standard to send us product data.
As the Senior UX Designer for PAM, I took on the task of designing how one HEB Partner would review product data received via EDI and resolve any errors that come up.
This is his story.
Meet Kyle.
He’s literally the only person* at HEB that reviews products set up via EDI.
*okay, technically one other person is trained on EDI setups, but she only reviews them when Kyle is out of office. Don’t worry, I interviewed her as well.
What is EDI?
EDI is a digital way for businesses to trade documents in a consistent format. It cuts out manual work, lowers mistakes, and automates data transfers.
We use the EDI 832 document for product setup. It allows Suppliers to send us all of the product & pricing data we need to get products set up in our system.
Kyle says EDI reviews are pretty easy—at least when everything works correctly.
Everything does not always work correctly.
So what can go wrong?
A product could already exist.
If a product already exists, Kyle tries to figure out why the Supplier included an existing product. He looks for clues in the data:
if the product is active, did cost or retail change?
if the product is discontinued, when was it discontinued? Who discontinued it?
If he can’t figure out what’s going on, he’ll contact the Supplier, but he likes to troubleshoot on his own first.
Data could be missing or invalid.
If a product doesn’t already exist in our system, then we can try to set it up. If it’s missing required data or if some of the data is invalid, then that’s an issue Kyle has to look at and try to resolve.
Let’s help Kyle.
Why now?
The old product setup app, CPS, runs on a costly mainframe system that HEB wants to deprecate. The product setup application that I work on, PAM, is replacing CPS.
EDI is one of the last features standing in the way of retiring CPS.
Scope
The app-for-app replacement game often leads to feature-parity work. We’re not interested in that.
We want to help our Partners work more efficiently, so we’re on the hunt for UX improvements to enable that. We’ll weigh our timeline and technical constraints when evaluating the design, but we won’t let that guide us away from a truly great solution.
We don’t assume this feature was built perfectly the first time around.
My role
I owned and led the UX research, design, testing, and handoff for this project. I directed the work of a new Associate Product Designer and helped guide her through the design process and reviewed her synthesis of our research sessions.
We collaborated closely with PAM's Product Manager, Engineers, and stakeholders throughout this 10 week* project.
*this wasn’t our only project during that time, so this timeline is a little longer than usual.
Design process
-
![]()
User interviews
We met with our users to learn about how they work today and the problems they face. They also shared training materials for us to review.
-
![]()
Synthesis, design ideation, & flow mapping
We synthesized the sessions and analyzed the training materials, then started mapping flows and iterating on designs.
-
![]()
Product, Design, & Engineering sync
We reviewed the first iterations with Product & Engineering to evaluate feasibility before we continued with this iteration.
-
![]()
Back to users
Then we checked back in with users to see if we’re going down the right path, conduct usability testing, and check if we missed anything.
-
![]()
More reviews
After making a few adjustments based test feedback, we reviewed the near-final designs with stakeholders that have decades of experience and are data experts. Then we synced with Product & Engineering again.
-
![]()
Finishing touches
After really digging into it with Engineering, we had a few minor adjustments to make. Then we cleaned up our file & components and wrote documentation for handoff!
What did we learn?
When there aren’t any errors, EDI is pretty peachy. So we mostly kept the parts of EDI review that work well in CPS and focused on the headaches—resolving errors.
Let’s build something that doesn’t waste Kyle’s time.
If a UPC already exists in our system, Kyle has to do a lot of investigating.
He has to open multiple apps to check and compare data, and even change data sometimes. At a minimum, our system should fetch this data for him. But after interviewing him extensively, I realized when certain conditions are met, we can do a lot more than that.
What Kyle was doing before was basically just a bunch of if, then statements.
Kyle’s actions were a set of instructions—in our new flow PAM will follow them so Kyle doesn’t have to anymore.
What about other errors?
If a UPC doesn’t already exist in our system, things can still go wrong. It could have invalid data or maybe it’s missing a value for a required field.
CPS doesn’t tell Kyle exactly what went wrong, so he wastes a ton of time digging through data.
There are over 80 fields, so it can take quite a while to track down an error. Our Suppliers using EDI expect a very quick turnaround and could deliver product to our stores the very next day—so every error eats into time Kyle doesn’t have.
PAM won’t keep Kyle in the dark—we’ll tell him exactly what went wrong and where.
To get these time-saving improvements out as fast as possible, we’ll let Kyle fix errors using a spreadsheet (similar to another workflow our users are familiar with).
Due to the complexity of our data, we’re still researching the best way to let our users edit in bulk in the UI.
Kyle is just excited we’re going to give him comprehensive and precise error messaging.
