Docwize case study — SaaS document workflow design

The context

As an enterprise workflow and document intelligence platform, built by a company with twenty-five years in case management. It sells into mining, engineering, construction, forensics, litigation, finance and HR.

8,000+Documents in motion

2,000+Organisations

1,200+People acting daily

Every task the system generates arrives on their inbox compliance feature which has roughly 8,000 documents in motion, around 2,000 organisations and about 1,200 people taking action on a given day, two or three tasks each.

It is the most trafficked surface in the product hence a need to be prioritized.

The problem

Internal managers, external technicians and professional teams all share the same Inbox. On top of that, workflow steps were over-exposed, and permissions quietly showed what every person was allowed to know. The founders called it functional but not intuitive.

The discovery

Dian and Simon walked me through their own product analytics before I drew anything. Users were only interacting with about 22% of the dashboard on a regular basis.

What we ran

Interviews

Document controllers, external technicians and internal managers
Recordings

Watching where people stalled inside an item
Heat maps

Controls carrying traffic vs. controls carrying none
Survey

Which fields must be legible without a click
Usability TEST

Rounds on wireframes, each feeding the next

34%never opened the document preview before acting

42%left an item without taking the action it requested

66%used the left rail as a task list rather than the columns

7clicks on average to complete one approval

Legacy Docwize inbox with interaction heat map — Interaction clustered on the left rail. The workflow panel in the centre saw a fraction of the clicks. ColdHot

The process

I rewrote the hierarchy before touching a card. And I projected it down to four levels, in the order a person needs them. The entire flow was now clear without competing for each other.

Workflow→ Inbox Items→ Documents→ User Actions

Excalidraw low-fi approval flow — Approval flow · Excalidraw

Inbox wireframing board in draw.io — Wireframe set

↑01CaptureDCET

02ReviewDCIM

03CorrectionDCET

04ApprovalIM

05Proof readDC

✓06ClosedDCIM

Touchpoint map

Our simple collaboration flow was excalidraw for flows, until every action could be defended one at a time. Miro and FigJam for sessions with Dian and Simon. Low-fidelity wireframes first, they were deliberately ugly to ship ideas quickly, so the conversation stayed on structure while structure was still cheap to change.

Three rounds, and what killed each one

Round 01KilledStage columns with a close-confidence star rating. Failed on four points: no dates, no sender, no signal in the left rail, and history vanished once an item stopped being pending.

Round 02KilledAnswered those and opened new ones. Task types wanted grouping, document actions needed a home outside the workflow area, and the header ate too much vertical space.

Round 03ShippedThe shape that held under testing, and the one that went to engineering.

The solution

User tasks, system tasks and history, each given a place of its own.

Empty state: no task selected, 125 pending tasks

User Tasks and System Tasks tabs with card outcomes

Activity panel with stage, priority, dates and notes

Empty state

Nothing selected used to mean nothing on screen. Now it reads: you have 125 pending tasks, pick one to start. An empty state on a task surface is the moment before the work.

User & system tasks

Index Contents moved to its own tab, with started and ended timestamps and an explicit completed state. You can tell whether something waits on you or on the system.

Activity panel

The Activity panel replaced the highlighter: who approved what, which stage it moved to, and the note they left, in order.

The card carries the answer, not a route to it.

01Due date reads what's left for the action you particularly need to take.
02Sent From and Proceeding To carry names and faces. You see the chain you stand in.
03The outcome sits on the face of the card. A word as the button.
04The radio marker is the activator. It marks the live card and opens it.
05Sent date, time and View Notes and users and operators can drop comments as a means of communication additionally for each action.

Shipped inbox, user tasks with outcomes on cards

The approval control was living in the window chrome.

Legacy workflow view with the action trail and item form — Before 01For Approval sat centred in the chrome. It read as a title. It was a button. 02Status and action wore the same clothes. 03No reject beside it. Approval means nothing without its opposite. 04Nowhere to say why. A decision with no reason cannot be audited. 05No sense of the chain: who else was waiting, who had signed.

Legacy workflow beside the document viewer — Before 01For Approval sat centred in the chrome. It read as a title. It was a button. 02Status and action wore the same clothes. 03No reject beside it. Approval means nothing without its opposite. 04Nowhere to say why. A decision with no reason cannot be audited. 05No sense of the chain: who else was waiting, who had signed.

Review decision panel with signature warning — After 01Approve and Reject as one pair, both unselected. The system never guesses intent. 02Notes with a 1000-character counter. The reason is captured at the decision. 03The file is named with its reference. You cannot approve the wrong thing. 04Five persons awaiting, four approved. One line closes the context gap. 05Skip the decision and an inline error stops you. Prevention, not messaging.

Review decision, second view — After 01Approve and Reject as one pair, both unselected. The system never guesses intent. 02Notes with a 1000-character counter. The reason is captured at the decision. 03The file is named with its reference. You cannot approve the wrong thing. 04Five persons awaiting, four approved. One line closes the context gap. 05Skip the decision and an inline error stops you. Prevention, not messaging.

Signing document state in the review panel

There was initially no signature configured, and a banner says so with a direct route to set one. Signing has its own state, so nobody presses twice on something legally binding.

I asked the engineers what they could build easily before I designed that animation.

The design system

Tokens, variants and a style guide, walked through with the team so it did not rot the week after I left. Variant organisation borrowed ideas from Google Material and Airbnb. Eventually, most of the handover was mostly about rules.

01Critical action visibility. A primary action not visible without scrolling pins to the bottom of the view.
02Split panel ratios. 70 / 30, both with a 320px minimum, scrolling inside the panel.
03Mobile split. Below the breakpoint the split becomes a tab switcher, Workflow and Document.
04Default table state. Side navigation collapses by default. The table needs the room.
05Radio as activator. One pattern, everywhere.

The impact

The problem was only visible in behavioural data, so the fix is judged the same way: task completion against the 80% baseline, time to first action, clicks per approval, and decisions submitted with a note.

62% reduction in task abandonment, against an 80 percent baseline

68% faster time to first action on an item

4 clicks removed from a standard approval

154 components shipped as a documented system

The conclusion

The Docwize team brought me back as a fractional designer for their next product, the Oliver AI sync platform.

That engagement was agreed immediately after the Inbox feature went into development. Since the build, I have not heard back.

Next case studyNext case studyNext case study

Rebuilding document review into a single, calm workflow for legal teams.