Designing an AI-assisted workspace that turns complex procurement documents into structured information teams can verify and move into their ERP workflow.
GLS processes procurement documents that move between customers, internal teams and multiple suppliers; from RFQs and quotations to purchase orders, confirmations and invoices.
When I joined the project, the team was in process of coding a working AI extraction prototype. It could read PDFs and return structured data, but the experience around it was still organised around technical processing runs rather than the way procurement teams actually work.
I led the UX redesign of the document workspace: defining how documents are uploaded and organised, how users understand processing states, how AI-extracted information is reviewed against its source, and how related documents can eventually come together as one procurement case.
To comply with my non-disclosure agreement, I have omitted or altered confidential information in this case study. The work shown represents my own design contribution and does not necessarily reflect the views of GLS.
Year
2026
Client
GLS Global Logistics Support GmbH
Role
Senior Product Designer
Work
Product strategy · UX architecture ·
AI UX · Interaction design · Prototyping
Team
Product Owner, 1 front end developer,
2 backend developers,
designer + PM (me)
Solution Preview
Research & Data insights
A procurement request isn't one document. It's a chain of evidence.
What looks like a simple order from the outside can pass through customers, GLS and several suppliers before it is complete.
Current state
Current AI tool could read the doc but the experience around it wasn't built right.
Users could upload a document, view the original PDF and inspect structured information extracted by the model. But the interface had evolved around what the system could do, not around how procurement users actually worked.
Sometimes we need to switch b/w networks, check reference numbers from previous documents and then manually enter the data into the ERP.
- Janina, Product Owner, GLS
The extraction engine worked, but the surrounding workflow had not yet been designed for scale.
Due to NDA reasons, I have blurred out confidential information. Reach out to me for more details.
And even if it's a simple document, the tool didn't give them:
What deserved our attention first?
Measure importance and workflow impact.
I grouped stakeholder feedback and current-state findings by how important they were to the procurement workflow and how much friction they introduced.
(hover on the points to read them)
01
Know which documents belong together
02
Verify extracted values against the source
03
See what needs attention
04
Identify the right document quickly
06
Correct extracted information before it moves forward
07
Preserve context when several files are uploaded together
08
Search and filter a large document set
09
Know whether processing is still running
10
Prevent accidental deletion
11
See technical processing metadata
12
Access raw JSON
05
Compare the same position across documents
Low impact
Lower importance
High importance
High impact
Importance to completing the procurement workflow correctly
Impact on the user's current workflow
Man job to be done
As a document manager, I want to see all incoming documents in one place, quickly review and verify their information, and transfer the correct data to the ERP system so that the ERP remains the single source of truth for tracking and downstream work.
What should the product understand for them?
Our hypothesis is:
If related documents enter the product with clear hierarchy, visible processing states and traceable extracted data, procurement users can move from manually interpreting files to reviewing exceptions and making decisions.
What can we do?
Align on the questions that drive us.
Instead of jumping directly to features, I reframed the work around a small set of experience questions.
How might related documents be compared without rebuilding the context manually?
How might every important AI value be easy to verify?
How might documents organise themselves if uploaded together?
What we call win?
Defining success
How would we know our design is working?
Reduce the 10–40 minute manual document-processing workflow
Make important extracted fields faster to verify and correct
Reduce how many places users need to visit to understand one document
Let users identify supplier, document type and status without opening every PDF
Quick ideation, quick reviews
Building the ideas
Since the timeline was only 2 weeks and I was relying on dev team, and PO for reviews and had multiple directions to test out. I followed Atlassian's ideation framework of building good, better, best flows and present them for feedback.
We ended up combining few ideas from each other and have final version of good, better, best flows which also helped us document what we could add in future.
What we shipped
Final solution highlights
The final product isn’t designed to store documents forever. It gives users just enough structure, context and control to move them from incoming PDF to ERP with confidence.
Homepage stays focused on the documents themselves and giving a way to start.
Document page new structure was designed to support flexibility of search in any way user wants: be it column filter, global filter or search box.
Email sync is designed to be configurable rather than always-on. Users can decide which incoming emails and attachments should be pulled into the tool.
Activity gives users a lightweight view of what the system is currently reading, what’s ready, and where something may have failed, keeping the main workflow uninterrupted.
Email sync is designed to be configurable rather than always-on. Users can decide which incoming emails and attachments should be pulled into the tool.
Combine the documents as a case and find inconsistencies with GLS AI.
Review auto suggestions given by GLS AI for low confidence extracted fields.
Edit directly in the panel before transferring to ERP system.
Ask questions to GLS AI to help with the quick review of the long documents.
What difference did we make?
Fin.
Final thoughts
This started as a pretty straightforward idea: use AI to read procurement docs and reduce manual ERP entry.
But the more I got into the workflow, the more obvious it became that extraction was only one part of the problem. The bigger challenge was everything around it: how documents come in, how people find the right one, how they verify what AI pulled out, and how much control they still need before anything gets pushed to ERP.
I also didn’t want this to become another system people have to maintain forever. The ERP is still the source of truth. This tool just makes the messy part before it a lot faster and easier to work through.