Most of my recent work is under NDA. This is a solo practice project I took on during a career break partly to stay sharp, and partly to have something post-NDA I could show. I picked EDI mapping specifically because it was a field I knew nothing about. There are no shipped outcomes here. The other studies have those. This one exists to show process.
I came in knowing next to nothing about EDI. My research plan was to explore three questions:
I began with Google searches and AI prompts to learn the basics. So what is EDI mapping?
EDI (Electronic Data Interchange) mapping is the process that allows two businesses’ systems to automatically exchange structured documents, like purchase orders and invoices, without human intervention.
Every EDI map is made up of three components:
These three components are grouped into packages. Schemas can be reused across packages, but each transformation map is unique because every trading partner relationship has its own data requirements.
I looked at every major EDI mapping tool that had publicly available UI and cataloged it, organizing 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.
EDI Mapping is a niche workflow and legacy WinForms apps like EDI Notepad are still seeing use as free options. Tools like this can handle the actual mapping process, but none of the document management around it.
That said, more advanced tools exist which handle the entire process within SaaS apps. Boomi, one of the leading competitors in the space, supports AI driven creation of packages.
I performed two exploratory user interviews with EDI integration specialists I had reached out to through r/EDI. My questions were focused on understanding their contexts and identifying pain points with current EDI mapping solutions.
The average EDI specialist is over 40, largely self-taught on the standards, and often the only person at their company who fully understands the integration layer. Their work is depended on daily, but has no visibility until a package fails.
EDI specialists are often the only person at their company who owns the integration layer. When a package fails, the business feels it immediately and the pressure lands on one desk.
For specialists on legacy and mid-market platforms, they’re not slowed down by the complexity of the problem, but by missing context. Dependency chains, version history, and audit trails all live in spreadsheets, other apps, or someone’s memory.
The research pointed to a clear gap: specialists need a single place to manage packages, track dependencies, and diagnose failures. I designed Package Manager, a mock SaaS app, around that need, starting with a sitemap to establish the information architecture.
I focused the hi-fi effort on the highest-stakes scenario: a production outage where the cause isn’t immediately clear. I designed the core diagnostic flow around that moment, starting from an AI alert on the dashboard and following through investigation and resolution, without leaving the app.
Every screen in this flow was fully specced for handoff with redlines, annotations, and edge cases documented for each component. All UI is built from a modular atomic design system constructed from scratch, with every token, component, and variant available in the same Figma file.
This project was an exercise in creativity where AI became a vector for that creativity. Knowing nothing about EDI at the outset, AI helped with plain-language explanations backed by good sources and let me steer my learnings towards the problems I’m most well positioned to solve. It gave crit on my research outline, interview questions, and design choices. It analyzed and clarified user interview responses. It helped me explore visual and functional treatments. I felt empowered having a coprocessing system I could rely on to solve a complicated problem.
If I could take this project further it would be through the AI insights on the dashboard. The feature is built on a real observation, that EDI tools already have everything needed to diagnose most failures but don’t connect the dots for you. What I didn’t get to answer is whether a specialist would trust that diagnosis enough to act on it. I’d love to explore how the AI could best show its work when diagnosing each of the common reasons for outages.