From Fragmented Tools to a Coherent Service

Redesigning the Document-Processing Service Under Regulatory Pressure

From Fragmented Tools to a Coherent Service

Redesigning the Document-Processing Service Under Regulatory Pressure

A large financial organisation faced a hard deadline to digitally archive all client documents. The archiving software the organisation had purchased soon proved too rigid for how documents actually moved through the business in practice, and files began to go missing: being misfiled, and as such for all practical purposes unrecoverable.
A service that can't reliably retrieve its own records exposes an organisation to forced payouts, regulatory scrutiny, and reputational damage.

My contribution

I owned the redesign of the document archiving service — from understanding the people affected by it, to the interface itself, to validating it under real conditions.

Interviewed processing staff, compliance officers and IT stakeholders to understand where the whole workflow broke down
Analysed error reports and observed staff at multiple locations to identify root causes of misfiling
Designed the drag-and-drop upload interface, real-time validation, and smart metadata form based on these findings
Ran multiple rounds of usability testing (paper prototypes, interactive prototypes, and a live beta) to validate the design against real working conditions
Collaborated with engineering on technical constraints (e.g. duplicate-detection performance) to keep the design realistic to build

Interviewed processing staff, compliance officers and IT stakeholders to understand where the whole workflow broke down
Analysed error reports and observed staff at multiple locations to identify root causes of misfiling
Designed the drag-and-drop upload interface, real-time validation, and smart metadata form based on these findings
Ran multiple rounds of usability testing (paper prototypes, interactive prototypes, and a live beta) to validate the design against real working conditions
Collaborated with engineering on technical constraints (e.g. duplicate-detection performance) to keep the design realistic to build

Results achieved

business impact

Measurable results for the organisation.

Document filing time

60 %

less time

needed

Document filing time

60 %

less time

needed

Amount of documents filed

150 %

increase

in throughput

Amount of documents filed

150 %

increase

in throughput

Compliance deadline

4

schedule

months

ahead of schedule

ahead of

Compliance deadline

4

schedule

months

ahead of schedule

Error rate

87 %

reduction

(from 2% to 0.26%)

Error rate

87 %

reduction

(from 2% to 0.26%)

Return On Investment

8

months

to positive ROI

Return On Investment

8

months

to positive ROI

Annual Cost Savings

€ 680K

680 K

€

Reduction

less labour,

no rework, faster processing

operational impact

Improvements in processes, content.

Time per document

73 %

faster

down from 8-12 min to 2-3 min

Time per document

73 %

faster

down from 8-12 min to 2-3 min

Documents per person per day

180 %

increase

up from 40-50 to 120-150

Rework required

89 %

Reduction

down from 450/week to 50/week

Rework required

89 %

Reduction

down from 450/week to 50/week

USER impact

The benefits users experienced directly.

User satisfaction (SUS Score)

5/5

grade a

rated 'Excellent'

User satisfaction (SUS Score)

5/5

grade a

rated 'Excellent'

We don't dread our work anymore"

IN FOLLOW-UP CONVERSATIONS

the whole team agreed the fear of losing a document had gone — the system, not their vigilance, now catches the mistakes

The Challenge

A large financial organisation faced a hard deadline that meant operational and legal disaster without a solution — but the deadline was only the symptom. The underlying service that moved a document from a filing cabinet to a compliant digital record had never been designed as a whole. It had simply accumulated.

The organisation faced a hard deadline that meant operational and legal disaster without a solution — but the deadline was only the symptom. The underlying service that moved a document from a filing cabinet to a compliant digital record had never been designed as a whole. It had simply accumulated.

The Business Reality

3.2 million client files stored in steel cabinets across 4 locations
€2.4M in annual storage and retrieval costs (rent, staff, transport)
18 months for a full digital migration — non-negotiable
€500K in estimated compliance fines if the deadline was missed
Operational risk: no paper backup meant total dependence on a digital service that didn't yet function as one

3.2 million client files stored in steel cabinets across 4 locations
€2.4M in annual storage and retrieval costs (rent, staff, transport)
18 months for a full digital migration — non-negotiable
€500K in estimated compliance fines if the deadline was missed
Operational risk: no paper backup meant total dependence on a digital service that didn't yet function as one

Reframing the Service Challenge

Wrong question: "How do we digitise documents faster?"

Right question: "How do we design a service that prevents errors — while respecting the expertise staff have built up over decades and make the whole process easier?"

This reframe was the pivot point of the whole engagement. It moved the brief from a feature-and-speed problem to a service-architecture problem, and from "fix the screens" to "redesign the system of people, process, and technology around the document."

Wrong question: "How do we digitise documents faster?"

Right question: "How do we design a service that prevents errors — while respecting the expertise staff have built up over decades and make the whole process easier?"

Design Principles

Guiding Design Principles

Four principles guided every decision — at the level of the service, not just the interface:

Prevention Over Detection — build reliability into the service architecture, before problems ever reach a screen;
Minimise Cognitive Load — one journey, one mental model, regardless of how many systems sit behind it;
Progressive Disclosure — surface only what's needed at a certain moment in the journey;
Respect Existing Expertise — design the service around how experts already work, not around a theoretical ideal user.

Prevention Over Detection — build reliability into the service architecture, before problems ever reach a screen;
Minimise Cognitive Load — one journey, one mental model, regardless of how many systems sit behind it;
Progressive Disclosure — surface only what's needed at a certain moment in the journey;
Respect Existing Expertise — design the service around how experts already work, not around a theoretical ideal user.

But the real problem wasn't the deadline — the existing digitisation service was fundamentally broken as a system, not just as an interface.

Project overview

My role

Service Designer • UX Researcher • UI Designer

Duration

8 months

team

1 Business consultant

1 Project manager

3 Back-end Developers

2 Front-end Developers

2 Processing staff members

SCOPE

• New archiving tool

• Archiving governance and operational processes

Operational painpoints

An impossible math problem

3.2 million paper files, an 18-month deadline, and staff who could only process a document every 8–12 minutes — at that pace, the deadline was simply out of reach

Experience didn't scale

Even the most skilled staff member could only get through a limited number of files a day. Onboarding someone new to that same level would take months — so hiring more people wasn't a real fix.

A mistake could make a file disappear forever

Once a document was uploaded with the wrong metadata, and its paper original had already been filed away elsewhere, there was no reliable way to find it again — turning a small data-entry slip into a permanently lost client record.

Lost files meant real financial Risk and possibly legal exposure.

Missing documents put the organisation at risk of compliance fines of up to €500K, plus the operational cost of an unresolved client case with no paper backup to fall back on.

The system relied on people, not process.

Because knowledge of how to avoid these risks lived in a few experienced staff members' heads rather than in the system itself, the organisation's ability to hit the deadline safely depended on a handful of individuals — not a repeatable process.

Research

Before designing anything, I spent three weeks embedded across the full service — front-stage (staff-facing tools) and back-stage (databases, compliance checks, IT infrastructure) — to build an accurate picture of how a document actually moved through the organisation.

Research ACTIVITIES

12 in-depth interviews with processing staff (experience ranging from 6 months to 23 years)
40+ hours of workflow observation across 3 different locations, tracing documents front-stage to back-stage
Stakeholder interviews with compliance, IT and management to understand constraints upstream and downstream of the visible workflow

12 in-depth interviews with processing staff (experience ranging from 6 months to 23 years)
40+ hours of workflow observation across 3 different locations, tracing documents front-stage to back-stage
Stakeholder interviews with compliance, IT and management to understand constraints upstream and downstream of the visible workflow

Root cause analysis

There was a broken service: Six Systemic Breakdowns

01.

Fragmented Touchpoints Across the Journey

02.

No Fail-Safes Built Into the Service

No Fail-Safes Built Into the Service

03.

neglect of Human needs Inside the Service

neglect of Human needs Inside the Service

04.

Tacit Knowledge Never Made It Into the Service Design

Tacit Knowledge Never Made It Into the Service Design

05.

Redundant Work Built Into the Service Flow

Redundant Work Built Into the Service Flow

06.

Inconsistent Service Standards

Inconsistent Service Standards

Root cause analysis

01.

Fragmented Touchpoints Across the Journey

This was the single biggest source of service failure — not a UI flaw, but a broken handoff between systems.

Staff had to move a single document through 7 disconnected touchpoints:

This was the single biggest source of service failure — not a UI flaw, but a broken handoff between systems.

Staff had to move a single document through 7 disconnected touchpoints:

1. Desktop scanner software

2. File conversion tool

3. Manual file naming (external step)

4. Database application

5. Metadata entry (manual work)

6. FTP client

Verification system

Verification system

3.2 million client files stored in steel cabinets across 4 locations
€2.4M in annual storage and retrieval costs (rent, staff, transport)
18 months for a full digital migration — non-negotiable
€500K in estimated compliance fines if the deadline was missed
Operational risk: no paper backup meant total dependence on a digital service that didn't yet function as one

3.2 million client files stored in steel cabinets across 4 locations
€2.4M in annual storage and retrieval costs (rent, staff, transport)
18 months for a full digital migration — non-negotiable
€500K in estimated compliance fines if the deadline was missed
Operational risk: no paper backup meant total dependence on a digital service that didn't yet function as one

Impact:

• Average time per document: 8-12 minutes

• Staff lost track of which step they had already completed — a service with no single, coherent journey

• Manual data entry introduced the risk of errors.

Why this happened:
The systems had grown organically over the years, each solving a local problem. Nobody owned the service end-to-end.

The systems had grown organically over the years, each solving a local problem. Nobody owned the service end-to-end.

why this happened

Average time per document: 8-12 minutes;
Staff lost track of which step they had already completed — a service with no single, coherent journey;
Manual data entry introduced the risk of errors.

Average time per document: 8-12 minutes;
Staff lost track of which step they had already completed — a service with no single, coherent journey;
Manual data entry introduced the risk of errors.

impact

Root cause analysis

02.

No Fail-Safes Built Into the Service

There was no way errors could be prevented.

The consequence:

There was no way errors could be prevented.

The consequence:

• The original paper document had already been filed away → hard to retrieve.

• Correcting errors was exponentially more expensive the later they surfaced.

• Metadata errors could stay hidden forever.

The original paper document had already been filed away → hard to retrieve.
Correcting errors was exponentially more expensive the later they surfaced.
Metadata errors could stay hidden forever.

This wasn't a design flaw in any single screen — it was an architectural accident in how the service was assembled.

Root cause analysis

03.

Neglect of Human needs Inside the Service

Root cause analysis

03.

Neglect of Human needs Inside the Service

This is what struck me most:

I'm terrified every single day that I'll lose someone's file. Once it's in that database and the metadata is wrong, it is like looking for a needle in a haystack. We never find it again."

Peter, Document Processing Specialist, 21 years of experience.

Staff were the human layer of a service responsible for irreplaceable legal documents. A single mistake could mean someone's mortgage records or insurance claim data disappearing.

This psychological burden lowered morale born out of sheer anxiety — a service that was failing the people delivering it, not just the people it was meant to serve.

Staff were the human layer of a service responsible for irreplaceable legal documents. A single mistake could mean someone's mortgage records or insurance claim data disappearing.

This psychological burden lowered morale born out of sheer anxiety — a service that was failing the people delivering it, not just the people it was meant to serve.

Root cause analysis

04.

Tacit Knowledge Never Made It Into the Service Design

Experienced staff had learned workarounds and shortcuts — but none of it was ever formalised into the service itself.

Consequence:
The service depended on a small group of experts rather than on a designed, repeatable process

Experienced staff had learned workarounds and shortcuts — but none of it was ever formalised into the service itself.

Consequence:
The service depended on a small group of experts rather than on a designed, repeatable process

Root cause analysis

05.

Redundant Work Built Into the Service Flow

All the metadata already printed on the paper document had to be manually re-entered into the database — pure waste designed into the journey.
The information already existed — the service just was never designed with the idea that it would one day needed to be integrated into a bigger system.

All the metadata already printed on the paper document had to be manually re-entered into the database — pure waste designed into the journey.

The information already existed — the service just was never designed with the idea that it would one day needed to be integrated into a bigger system.

Root cause analysis

06.

Inconsistent Service Standards

There were over 20 metadata fields and all were mandatory although only 5 of them were truly vital. Staff - after reporting this and nothing changed - just started filling in random data in the mandatory data fields so could continue with their jobs. This led to inconsistent data quality across locations and staff.

Key findings

Through service blueprinting and error analysis, I arrived at three critical insights:

03.

Institutional Knowledge Was a Structural Bottleneck

02.

The Service Only Detected Errors — It Never Prevented Them

01.

Cognitive Overload Was a Service Design Failure, Not a User Failure

03.

Institutional Knowledge Was a Structural Bottleneck

Key findings

Through service blueprinting and error analysis, I arrived at 3 critical insights:

03.

Institutional Knowledge Was a Structural Bottleneck

02.

The Service Only Detected Errors — It Never Prevented Them

01.

Cognitive Overload Was a Service Design Failure, Not a User Failure

03.

Institutional Knowledge Was a Structural Bottleneck

key findings

01.

Cognitive Overload Was a Service Design Failure, Not a User Failure

Context-switching between 5-7 disconnected touchpoints destroyed concentration.
Staff lost track of what step they'd completed, what came next, and whether they'd already entered something — leading to duplicate uploads and irrelevant metadata.
This wasn't a training problem; it was evidence the service itself lacked a single coherent journey.

Context-switching between 5-7 disconnected touchpoints destroyed concentration.

Staff lost track of what step they'd completed, what came next, and whether they'd already entered something — leading to duplicate uploads and irrelevant metadata.

This wasn't a training problem; it was evidence the service itself lacked a single coherent journey.

key findings

02.

The Service Only Detected Errors — It Never Prevented Them

The service made it structurally impossible to catch errors early. Once uploaded, correction was expensive. This shifted the burden of reliability onto individual staff ("be extra careful") instead of building reliability into the service architecture itself.

The service made it structurally impossible to catch errors early. Once uploaded, correction was expensive.

This shifted the burden of reliability onto individual staff ("be extra careful") instead of building reliability into the service architecture itself.

key findings

03.

Institutional Knowledge Was a Structural Bottleneck

Peter could process 30 documents a day. New employees took weeks to reach the same speed — because the service depended on tacit, undocumented expertise rather than a designed, teachable process. This knowledge gap capped how fast the organisation could scale.

Peter could process 30 documents a day. New employees took weeks to reach the same speed — because the service depended on tacit, undocumented expertise rather than a designed, teachable process.
This knowledge gap capped how fast the organisation could scale.

Key findings

Through service blueprinting and error analysis, I arrived at three critical insights:

03.

Institutional Knowledge Was a Structural Bottleneck

02.

The Service Only Detected Errors — It Never Prevented Them

01.

Cognitive Overload Was a Service Design Failure, Not a User Failure

03.

Institutional Knowledge Was a Structural Bottleneck

key findings

01.

Cognitive Overload Was a Service Design Failure, Not a User Failure

key findings

02.

The Service Only Detected Errors — It Never Prevented Them

key findings

03.

Institutional Knowledge Was a Structural Bottleneck

Service Transformation Strategy

Instead of isolated UI fixes, I redesigned the full service ecosystem — aligning front-stage staff experience with back-stage systems, compliance rules, and infrastructure constraints.

01.

Automating the Back-Stage

Intelligent File Handling

02.

Redesigning the Front-Stage Entry Point

Drag & drop

Drag & drop UI component

03.

Encoding Service Rules

Smart Metadata Hierarchy

04.

Building Prevention

Real-Time Validation Into Every Touchpoint

service transformation Strategy

01.

Automating the Back-Stage: Intelligent File Handling

The problem

drag & drop INTERFACE that accepts most common file types

Staff spent 40% of their time on file-format issues — conversions, validation, renaming — none of which required human judgement.

my approach

drag & drop INTERFACE that accepts most common file types

Move this entirely into the service's back-stage, invisible to staff:

Moved this entirely into the service's back-stage, invisible to staff:

•. Accepts all common formats (PDF, DOCX, JPG, email MSG attachments)

• Automatically converts to archival-quality PDF/A

• Generates OCR text for searchability

• Validates file integrity before acceptance

strategic advantage

drag & drop INTERFACE that accepts most common file types

Staff time is reserved for the one step that genuinely needs human judgement — accurate metadata — not technical conversion work a system should own.

service transformation Strategy

02.

Redesigning the Front-Stage Entry Point

interaction model

drag & drop INTERFACE that accepts most common file types

For the User Interface I choose for a Drag & drop component:

I created a new User interface based on the simple interaction of Drag & drop. Dropping one or more files in the drop area automatically converted them into high quality PDF files.

The interface also included a real-time preview area, so users could see the converted file immediately and rename it accordingly (if needed) — removing the need to open files in separate applications just to figure out what they contained.

I created a new User Interface based on the simple interaction of Drag & drop. Dropping one or more files in the drop area automatically converted them into high quality PDF files.

The interface also included a real-time preview area, so users could see the converted file immediately and rename it accordingly — removing the need to open files in separate applications just to figure out what they contained.

1. It matches a physical, real-world mental model;
2. It shows relationships and state changes immediately;
3. It collapses multiple steps into one fluid action.

I created a new User interface based on the simple interaction of Drag & drop. Dropping one or more files in the drop area automatically converted them into high quality PDF files.

I created a new User Interface based on the simple interaction of Drag & drop. Dropping one or more files in the drop area automatically converted them into high quality PDF files.

Dropping one or more files in the drop area automatically converted them into high quality PDF files.

I created a new User interface based on the simple interaction of Drag & drop. Dropping one or more files in the drop area automatically converted them into high quality PDF files.

I created a new User Interface based on the simple interaction of Drag & drop. Dropping one or more files in the drop area automatically converted them into high quality PDF files.

service transformation Strategy

03.

Service Rules Into a Smart Metadata Hierarchy

This was the strategic core of the redesign — turning an undocumented, tacit set of rules into an explicit service policy.

title here

drag & drop INTERFACE that accepts most common file types

The Reality of 21 Metadata fields:

● 5 legally mandatory
● 7 auto-derivable from document content or the database
● 9 "nice to have" but rarely used

My Design Solution:

● Mandatory Fields: always visible
● Auto-Filled Fields: shown but greyed out, so staff can see what the service is doing on their behalf and if needed they were editable— trust!
● Optional Fields: collapsed under "Additional fields"

● 5 legally mandatory
● 7 auto-derivable from document content or the database
● 9 "nice to have" but rarely used

My Design Solution:

service transformation Strategy

04.

Building Prevention Into Every Touchpoint

service transformation Strategy

04.

Touchpoint

Building

Every

Prevention Into Every Touchpoint

Building Prevention Into

This was the heart of shifting the service from error-detection to error-prevention.

Every field validates as you type:

This was the heart of shifting the service from error-detection to error-prevention.

Every field validates as you type:

My Governance Model:

1. Content ownership

Peer review

3. Periodic audits

4. Feedback loop from Support

1. Content ownership

Peer review

3. Periodic audits

4. Feedback loop from Support

Content OWNERSHIP

Content OWNERSHIP

•. Every article / topic gets a clear owner.

• The owner is responsible for accuracy and quality.

• 15% of their time allocated to content management.

•. Every article / topic gets a clear owner.

• The owner is responsible for accuracy and quality.

• 15% of their time allocated to content management.

PEER REVIEW

PEER REVIEW

•. New or updated articles must be approved by a peer.

• Review checklist: “matches the template?”, “written in the customer’s language?”, “no duplicates?”, "up to date?"

• Right category/sub-category?

•. New or updated articles must be approved by a peer.

• Review checklist: “matches the template?”, “written in the customer’s language?”, “no duplicates?”, "up to date?"

• Right category/sub-category?

PERiodic Audits

PERiodic Audits

• Each article got an expiry date

• Expiry date flagged outdated articles

• When audit was due the content owner received an automated notification.

• If audit was not performed within a certain period the article would be invisible until audit.

• Each article got an expiry date

• Expiry date flagged outdated articles

• When audit was due the content owner received an automated notification.

• If audit was not performed within a certain period the article would be invisible until audit.

Feedback Loop from Support

Feedback Loop from Support

•. A weekly meeting was set up to discuss which topics generated the most questions.

• This feeds directly back into content priorities.

• When audit was due the content owner received an automated notification.

• If audit was not performed within a certain period the article would be invisible until audit.

• A weekly meeting was set up to discuss which topics generated the most questions.

• This feeds directly back into content priorities.

• When audit was due the content owner received an automated notification.

• If audit was not performed within a certain period the article would be invisible until audit.

service transformation Strategy

04.

Building Prevention Into Every Touchpoint

service transformation Strategy

04.

Touchpoint

Building

Prevention Into Every Touchpoint

This was the heart of shifting the service from error-detection to error-prevention.

Every field validates as you type:

My Governance Model:

1. Content ownership

Peer review

3. Periodic audits

4. Feedback loop from Support

Content OWNERSHIP

•. Every article / topic gets a clear owner.

• The owner is responsible for accuracy and quality.

• 15% of their time allocated to content management.

PEER REVIEW

•. New or updated articles must be approved by a peer.

• Review checklist: “matches the template?”, “written in the customer’s language?”, “no duplicates?”, "up to date?"

• Right category/sub-category?

PERiodic Audits

• Each article got an expiry date

• Expiry date flagged outdated articles

• When audit was due the content owner received an automated notification.

• If audit was not performed within a certain period the article would be invisible until audit.

Feedback Loop from Support

•. A weekly meeting was set up to discuss which topics generated the most questions.

• This feeds directly back into content priorities.

• When audit was due the content owner received an automated notification.

• If audit was not performed within a certain period the article would be invisible until audit.

Service Design Process: a Deep Dive

Exploring Alternative Service Models

I explored three fundamentally different ways of structuring the service:

Concept 1: A Guided wizard

A strict step-by-step service flow. Little flexibility.

This feels like the system doesn't trust me. Why can't I just fill in the fields I need?"

Lesson learned: Experts want control over how they move through a service. Don't force a rigid journey on people who already know the terrain.

Concept 2: All fields visible

All 47 fields exposed on a single screen — a service model with no scaffolding.

Test Result: New employees were overwhelmed — didn't know where to start, couldn't distinguish mandatory from optional fields.

Lesson learned: A service still needs to guide newcomers, even while giving experts freedom.

All 47 fields exposed on a single screen — a service model with no scaffolding.

Test Result: New employees were overwhelmed — didn't know where to start, couldn't distinguish mandatory from optional fields.

Lesson learned: A service still needs to guide newcomers, even while giving experts freedom.

Concept 3: Adaptive Service Model

The service adapts to who is using it:

Beginners: guidance, helpful tooltips, mandatory-field indicators
Experts: all fields available, minimal guidance

Beginners: guidance, helpful tooltips, mandatory-field indicators
Experts: all fields available, minimal guidance

Test Result: Promising — validated the core service model, though upload feedback and validation timing still needed refinement.

Testing & Iteration

Three Rounds of Service Validation

Round 1: Paper Prototype

(4 staff members)

Validated the core service journey
Revealed the wizard model was too restrictive
Identified the need for progress tracking within the journey

Validated the core service journey
Revealed the wizard model was too restrictive
Identified the need for progress tracking within the journey

Round 2: Interactive Prototype

(8 staff members)

Tested actual interaction patterns at each touchpoint
Found the drag-and-drop entry point too subtle
Identified validation-timing issues

Tested actual interaction patterns at each touchpoint
Found the drag-and-drop entry point too subtle
Identified validation-timing issues

Round 3: beta trial

(30 days, 6 staff members)

Measured real processing time across the full service
Identified edge cases and error patterns
Collected satisfaction data

Measured real processing time across the full service
Identified edge cases and error patterns
Collected satisfaction data

Critical Learnings

learning

Trust in a Service Requires Progressive Validation.

Early beta users double-checked automatic conversions — converting files manually, then uploading them, defeating the purpose of the automation entirely.

Root Cause:
Versions of the service had made errors, and that history didn't disappear just because the system changed.

My Solution:
A "View Processing Details" feature — underneath every conversion, a clickable link to the processing log, showing exactly what the service had done on the user's behalf.

After staff had verified accuracy 2-3 times, they stopped double-checking. Trust in a service is earned incrementally, not declared.

Implementation & Launch

Engineering Collaboration

I delivered to the engineering team the artefacts needed to build the service, not just the screens:

Detailed interaction specs with state diagrams
A component library (exact spacing, colours, behaviour)
Edge-case documentation (40+ scenarios) grounded in the service blueprint

Detailed interaction specs with state diagrams
A component library (exact spacing, colours, behaviour)
Edge-case documentation (40+ scenarios) grounded in the service blueprint

Technical Constraint & Solution:
Real-time duplicate detection across 3.2M records was too slow for the back-stage infrastructure. I adapted the front-stage experience from instant feedback to a "checking..." state with a 2-second debounce — preserving the feel of the service while respecting the system's real constraints.

Phased Service Rollout

Instead of a big-bang launch, we rolled out the redesigned service in stages:

Phase 1 (weeks 1-2): 3 advanced users, new documents only
Phase 2 (weeks 3-6): 12 users, a mix of old and new documents
Phase 3 (week7+): Full teams, all document types

Phase 1 (weeks 1-2): 3 advanced users, new documents only
Phase 2 (weeks 3-6): 12 users, a mix of old and new documents
Phase 3 (week7+): Full teams, all document types

Benefits:

Problems caught early, before they propagated across the whole service
Built internal champions who could train others — embedding the new service model socially, not just technically
Rapid iteration based on real-world use

Problems caught early, before they propagated across the whole service
Built internal champions who could train others — embedding the new service model socially, not just technically
Rapid iteration based on real-world use

Round 3: beta trial

(30 days, 6 staff members)

Measured real processing time across the full service
Identified edge cases and error patterns
Collected satisfaction data

Measured real processing time across the full service
Identified edge cases and error patterns
Collected satisfaction data

Critical Learnings

learning

Trust in a Service Requires Progressive Validation.

Early beta users double-checked automatic conversions — converting files manually, then uploading them, defeating the purpose of the automation entirely.

Root Cause:
Versions of the service had made errors, and that history didn't disappear just because the system changed.

My Solution:
A "View Processing Details" feature — underneath every conversion, a clickable link to the processing log, showing exactly what the service had done on the user's behalf.

After staff had verified accuracy 2-3 times, they stopped double-checking. Trust in a service is earned incrementally, not declared.