Founding UX Designer
: Leading UX Design with Product Ownership
PL
2/FE
5/BE
+CS/Operation
Enterprise B2B SaaS
05.24~03.25(10Months)
Summary
Request: Build a convenient book ordering system for publishing staff, increase app usage,
Objective: set KPIs based on increased order rates through the app.
I led a B2B OMS built to replace a fragmented order process, publishers placing book orders via phone, email, and group chat messengers,
manually tracked with follow-up confirmations. With no PM at project start, I served as Founding Designer, owning both product direction and design.
The key discovery: users weren't calling support because features were missing, they called because they couldn't trust the system. Redesigned around visibility, not features. Result: orders +42%, errors −82%.
Friction points
The entire order system ran on manual communication, not the platform
01. Problem
Non-systemized workflow
Orders aggregated manually across email, phone, and group chat
Manual post-order edits and communication
Every modification routed through CS, creating a recurring error loop
AS-IS
Ordering Book Process
AS-IS process
A multi-step manual chain; call or email in, passed through Excel, scanned and shipped out
Why it breaks
No order edits meant CS calls became the default, and miscommunications in that loop caused 3+ delivery incidents every week
Today, an order travels through five hands and three tools before it reaches the bookstore. A bookstore sends the order via call or email. The publisher re-enters it into the OMS. CS verifies it, forwards an Excel sheet to operations, who scan and ship. Because the system had no edit function after submission, every mistake became a CS call. And every CS call became a chance for something to slip.
Working Process
01. Challenge
No reference
No comparable B2B publishing logistics platform to benchmark
No domain fluency
Consignment, direct trade, returns, fragmented OMS ecosystem
No cause data
Only one signal 5.8% adoption. The "why" was a black box.
02. Approach - A
Before designing the flow, I mapped the one already running, then workshopped a rough IA from what I found
First, it was essential to identify the issues with the existing order management structure.
I examined and analyzed the problems from three perspectives: functionality, structure, and UX flow, and incorporated the insights gained
into the MVP features. Since the ETA was set, I organized the features into phases. I ensured that the essential features were included in Phase 1, and then I listed additional features that would be beneficial to consider for future expansion.
Kick-Off Work Shop
System Analysis & Key Flow Brainstorming
Draft
OMS Process(Ordering Management System)
02. Approach - B
The plan assumed publishers wouldn't need to place orders, The Excel files said otherwise
Ordering Book Process
The initial assumption was straightforward: if bookstore orders came in via API, publishers wouldn't need to place orders manually, less work, more convenience. But while mapping the existing workflow, I found Excel files being exchanged between publishers and the CS team. Those files told a different story. Publishers place orders directly because many of them sell directly too. That changed the scope immediately.
Direct order entry wasn't an edge case. It was core. So I added a bulk order feature to the plan: a way to upload all book information at once.
03. User Research - Verifying the thesis
Was this feature something users actually needed or were we building in the wrong direction?
But before building it, I needed to verify: was bulk order upload actually what users needed?
I ran In-Depth Interviews with two groups: publishing staff who place orders, and CS team members who handle everything in between.
Goal
01
To validate how publishing staff mentally model the workflow, and to understand their day-to-day routines.
02
All order-related communication needed to live inside the system, not scattered across external channels.
03
All order-related communication needed to live inside the system, not scattered across external channels.
IDI
In Depth Interview Research
What I found
01
To validate how publishing staff mentally model the workflow, and to understand their day-to-day routines.
02
All order-related communication needed to live inside the system, not scattered across external channels.
03
All order-related communication needed to live inside the system, not scattered across external channels.
Publishers needed to register orders themselves, and with dozens of titles per order, bulk upload wasn't optional.
The bulk order assumption was wrong. Publishers don't send large batches of different titles at once, they send small quantities of the same title to multiple different addresses. The bottleneck wasn't entering book information. It was managing delivery fragmentation. Grouping by delivery destination, not by book title, was what actually simplified the work. Not bulk upload. Bulk delivery.
Final
OMS Process(Ordering Management System)
Solution
Build an environment where users can easily place and track orders on the go, through a simple and frictionless flow
TO-BE
Ordering Book Process
UX Strategy
01
Simplified ordering → real-time via tablet/app (web app)
02
Orders possible anytime
03
All communication handled within the platform
04
Eliminate order errors caused by miscommunication
Final
OMS Process(Ordering Management System)
The design principle behind every decision:
"A state where users can resolve it themselves without going through CS."
Real-time order status : Users can resolve issues themselves without calling customer service
In-platform order modification : No more group chat edits. Publishers modify directly.
Bulk ordering : Same title, multiple addresses, one shipment. Delivery fragmentation eliminated.
Final Design
Order Flow
Order Approval Flow
OutComes
CS error loop broken. Two numbers tell the whole story
+
42%
5% → 42%, platform viability threshold crossed
-
82%
CS error loop broken, users resolved issues themselves
Reflection
The interface was the last thing that needed fixing. It was about understanding the system behind it.
When I first looked at the Excel sheets and CX software, my honest reaction was that the structure felt overwhelmingly complex. I assumed my job was to untangle that complexity. But what this system actually needed wasn't just better usability, it was translating how work actually happens on the ground into the language of a product. That reframing brought me back to a more fundamental question: is what I find uncomfortable actually uncomfortable for this user?
UX designers tend to reach for quantitative data as their default tool. But what mattered more here was understanding the field directly, how publishing staff actually do their work, and how the CS team handles the communication running alongside it. Going through that process shifted my own mental model. UX isn't just about building interfaces. It's about figuring out how to translate the way people actually work into technology, and that starts not from data, but from people and the context they're in.