EDI Mapping App Case Study

Team: Me as sole designer w/ PM point of contact

Focus: Full design process from research to execution

Summary

I recently undertook a freelance project for an anonymous client to design an EDI mapping application supporting their B2B integration operations. With no prior experience designing software in this domain, I chose to follow Alan Cooper’s Goal-Directed Design process rigorously to ensure my work was grounded in solid research rather than assumption.

What is EDI Mapping?

EDI (Electronic Data Interchange) mapping is the behind-the-scenes process that connects one business’s eCommerce or ERP 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 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 freelance 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

Understanding EDI Mapping

This was the least glamorous step due to it simply entailing me trawling through AI calls, Google searches, articles, and other documentation to get a personal grasp on what EDI Mapping is. The end result is purely knowledge and context – because we have to start somewhere.

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.

Research Notes

User Research Notes — Desk Research

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…

Can you compile my research notes on EDI Integration Specialists into a Persona?

I leveraged Claude to generate a Persona based on my user research. Quick AI wins like this are part of what helped me apply an intensive research methodology like GDD to a small freelance project.

Requirements

I composed a set of user, business, 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. (Client very interested in this too)

• 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.

Business Requirements

• Client wants an app with better visual polish than their current one.

• Client wants it to be easy to deal with errors.

• Client wants design on a two-week timeline.

Technical Requirements

• Small dev team – simple, reusable React components should be used whenever possible.

Research Modeling Requirements Framework Refinement Support