EDI Mapping App Case Study

Team: Me as sole designer

Focus: Full design process from research to execution

Summary

I undertook a practice project to design an EDI mapping application to build my eCommerce background. With no prior experience designing EDI software, I chose to follow Alan Cooper’s Goal-Directed Design process rigorously to ensure my work was grounded in solid research.

What is EDI Mapping?

EDI (Electronic Data Interchange) mapping is the behind-the-scenes process that connects one business’s eCommerce platform to another’s eProcurement system, allowing them to exchange structured business documents automatically and accurately. This gives buyers an experience not unlike purchasing on Amazon, but using pre-negotiated contracts and prices.

EDI mapping always involves three components:

A source schema – the structure of data coming from one platform (e.g. a purchase order from Coupa)
A target schema – the structure expected by the receiving platform (e.g. an 850 transaction set for a vendor’s ERP)
A transformation map – the logic that translates source fields to target fields

These three components are grouped into Packages. Source and target schemas can be reused across multiple packages, but each transformation map is unique to its package since every trading partner relationship has its own unique data requirements.

Applying Goal Directed Design

Alan Cooper’s Goal-Directed Design (GDD) is built on a simple premise: good software begins not with features, but with a deep understanding of who will use it and what they’re ultimately trying to accomplish. While I adapted the process to fit a shorter engagement rather than a full product team, the discipline of researching before designing proved invaluable.

GDD was taught to me at the University of Washington’s HCDE program by Dr. Brock Craft and has been an invaluable tool in my toolbelt throughout my career.

Research

Anytime I perform research in an unfamiliar domain, I know I’m going to need three things.

Understanding of how the industry works
Understanding of the competitive landscape of that industry
Understanding of the end user

Hey Claude…

Can you explain how EDI mapping works at a conceptual level? What the key components are, how they relate to each other, and what kinds of tasks the people who use these tools typically perform day to day? Can you give your sources and where I can go to learn more?

Understanding EDI Mapping

This was the least glamorous step, consisting mostly of AI queries, Google searches, vendor documentation, and the occasional deep Wikipedia rabbit hole. But getting a personal grasp on the domain was essential before I could meaningfully research the people who work in it.

A few things I needed to understand before I could design anything

EDI standards like X12 and EDIFACT define the structure of business documents exchanged between trading partners. They’re rigid by design. A misplaced field breaks the transaction.
Transmission protocols like AS2 and SFTP are how those documents actually travel between systems. Failures at this layer are common and often the first thing an EDI specialist has to diagnose.
The relationship between translation objects and packages is the core data model of any EDI mapping tool. Understanding this early was what made the dependency tracking problem legible to me as a design challenge.

Hey Figma Make…

Can you produce an EDI Mapping application where an expert user can manage sources, targets, and transformations?

Understanding the Competitive Landscape

I looked at every major EDI mapping tool that had publicly available UI and organized them by page type. This helped me get a feel for how these applications are normally structured, as well as what cutting-edge features are being promoted by the biggest players. I also asked Figma Make to create an EDI mapping app just to get one extra data point.

Competitive landscape PDF available here.

Hey Claude…

I’m looking to make a UX Persona for an EDI Integration specialist who would use an EDI Mapping tool. Can you tell me more about their background in that context and share where I can go to learn more?

Understanding the End User

Without direct access to end users, I made do by researching EDI Integration Specialists – their typical background, education, and work experience. Because I didn’t start this project with a problem statement, I made it a point to learn their frustrations here to develop requirements later. Those frustrations included:

When packages have outages, it’s a stressful experience that affects company stakeholders and end-users. Packages can be easy to break because it can be hard to know what translation objects are being used in which packages. Changing one object to suit one package may break others.
Version control is handled mostly by file naming conventions, which makes it difficult to address broken packages caused by new object versions.

Research Notes

User Research Notes

Sources: LinkedIn job postings, Reddit (r/EDI, r/sysadmin), Stack Overflow, vendor documentation (Cleo, Boomi, Mulesoft), industry blogs, G2 and Capterra reviews for EDI platforms

Job postings (LinkedIn, Indeed)

Searched “EDI analyst,” “EDI specialist,” and “EDI integration engineer.” Reviewed ~20 postings to understand role expectations and common tool stacks.

Titles vary widely: EDI Analyst, EDI Developer, Integration Specialist, B2B Integration Engineer. Often sits within IT or Supply Chain departments.
Consistently required: X12 and/or EDIFACT standards knowledge, experience with AS2/SFTP transmission protocols, familiarity with at least one ERP (SAP, Oracle, NetSuite).
Mid-level roles (5-8 years exp.) frequently asked to own the full lifecycle: mapping, testing, partner onboarding, and production support.
Several postings mentioned “trading partner onboarding” as a primary KPI. Speed to onboard matters to the business.

Reddit (r/EDI, r/sysadmin)

Searched for pain points, tool complaints, and workflow discussions. Most active threads were troubleshooting-focused.

Common frustration: no easy way to see what downstream processes depend on a given map. Users described manually maintaining spreadsheets to track dependencies.
Outages are high-stress. Several users described being the sole person on-call for production EDI failures, with direct pressure from operations or sales teams.
Version control is a persistent problem. Most teams rely on file naming conventions or informal documentation rather than built-in history.
“I broke three other packages touching one map” came up more than once, in different threads.

G2 / Capterra reviews (Cleo, Boomi, SPS Commerce)

Looked for recurring praise and complaints across 30-40 reviews.

Positive reviews almost always mentioned reliability and uptime.
Negative reviews clustered around: poor error messaging, difficulty tracing failures back to a root cause, and steep learning curves for new team members.
Several reviewers noted that onboarding a new trading partner required touching multiple disconnected tools.
One review specifically praised a platform for showing “which maps are used where” suggesting this is not a given and is valued when present.

Vendor documentation and marketing copy (Boomi, Mulesoft, Cleo)

Skimmed to understand how vendors frame the user and their needs.

Vendors consistently emphasize “accelerating partner onboarding” and “reducing integration errors” as headline benefits.
Documentation assumes a technical user comfortable with schema concepts, but UI design often targets a broader operations audience.
Suggests a tension between the technical specialist who builds maps and the operations manager who monitors them.

General observations

The EDI specialist role is often a small team or a team of one. They are highly accountable for uptime but rarely have purpose-built tools for dependency tracking, version management, or audit trails. Most workarounds involve spreadsheets, shared drives, or tribal knowledge. The job is reactive by nature and the work becomes visible to the rest of the business only when something breaks.

Modeling

Hey Claude…

Here are my user research notes on EDI integration specialists. Do my conclusions about their main frustrations and goals hold up against what the research actually says, or am I reading too much into it?

Using my research notes as a foundation, I synthesized recurring patterns into a single representative user: Marcus Reid, an EDI Integration Specialist at a mid-size distributor, accountable for uptime across dozens of live trading partner connections.

Select the persona, then right click and “open image in new tab” to see details.

Requirements

I composed a set of user and technical requirements to ensure my designs hit the mark while being feasible to execute on.

User Requirements

• Users must be able to see every package that uses a given translation object, before making changes to it.

• Users must be able to view a full version history for any translation object and restore a previous version.

• Users must receive error notifications early enough to diagnose and resolve failures before trading partners are impacted.

• Users must be able to assess the health of all active packages from a single view without navigating between tools.

Technical Requirements

• Simple, reusable React components should be used whenever possible.

• Work should be cleanly annotated with reusable design system components.

Framework

The “Visual Sitemap”

Sitemaps are a stakeholder communication tool for explaining how an app’s pages connect to each other. In practice, I find they rarely succeed at this. They look a little too much like something a back-end engineer would share about system dependencies, and most people zone out when they’re being presented.

I’ve found that adding even a minimal visual component changes everything. Suddenly people are seeing their app for the first time and they realize this is their chance to have a say in the architecture before anything is built.

An example sitemap. (Credit – Ian Lawson @stickmap.com)

Refinement

I iterated on each screen of the app until I had polished high fidelity comps in Figma. I created a custom design system for the project with tokenized colors, flexible reusable components, and WCAG accessible visuals. Every comp has light/dark mode support.

Interactive Flow

Error diagnosis was one of the most consistent frustrations surfaced in my user research. specialists would often have no clear way to trace a failure back to its root cause. The flow below shows how the application addresses that, walking through how a user would diagnose and resolve an error affecting a live package.

Support

For larger engagements, post-handoff support can involve anything from regular dev syncs to usability testing on the live product. For a short engagement like this, the right move was thorough annotations and redlines on every comp, giving a development team as much of what they would need to build accurately as possible.

Back to Projects