Can you improve our DocuWare workflows?

Yes – from the user's perspective. We map your processes (invoice intake, approvals, mail intake, files), check with your key users where workflows and configuration get stuck, and produce a functional concept that your DocuWare partner or your IT implements. We sell no licences and do not configure against your existing partner; we make sure that what gets configured is understood and used by the business department.

Are you a DocuWare partner?

No. Beabstracto is not a DocuWare partner, not a reseller and not commissioned by the vendor. Thiago Andrade was employed there as a UX/UI Designer from February 2023 to February 2026; Beabstracto is independent and advises without licence sales. This case describes experience from a permanent position, not a consulting engagement.

What do "pragmatic and hedonic quality" mean in practice?

Pragmatic quality asks: do users complete their task efficiently, safely and with few avoidable problems? Hedonic quality asks: does the product feel coherent, modern, trustworthy? We work with benchmarks oriented towards models such as the User Experience Questionnaire (UEQ) and Hassenzahl's distinction, and make both comparable before and after changes.

We are a software vendor, not a DMS user – is this a fit?

Especially then. Configuration-heavy modules, workflow editors, admin interfaces and design-system foundations are the core of this experience. We support product teams with research, benchmarks, prototypes and design-system work – as external UX capacity that works inside squads, not as an agency throwing designs over the fence.

We are facing a DMS rollout or the move to the web-based Workflow Designer. Where do you start?

Before configuration. We map the as-is processes, formulate the target state with the business department in a functional concept, test critical workflows with key users before go-live, and support training and hypercare. The move to a new Workflow Designer generation is the right moment to clean up legacy in the workflows rather than migrating them one to one.

Where does the content of this case come from?

From the publicly described profile of the permanent position. We do not publish internal benchmark values, customer names, team sizes or product internals. That is why you find qualitative before/after descriptions here instead of percentages.

DMS/ECM · DocuWare · 2023–2026

Making workflow configuration in a DMS understandable – and UX quality measurable.

For administrators and key users who configure workflows in a document management system, what counts is precision, predictable behaviour and clear feedback. Three years of UX/UI design as an employee at DocuWare: Workflow Designer, enterprise configuration, design-system foundations – and UX quality made measurable through benchmarks, rituals and OKRs.

Book an initial call How we approached it

Client: DocuWare (employer, permanent position)
Industry: Document management and workflow automation (DMS/ECM), B2B SaaS
Role: UX/UI Designer, permanent position – product design, research, design system, UX benchmarks
Period: February 2023 – February 2026, Munich
Systems: DocuWare Workflow Designer, enterprise configuration, Figma
Team: Several product teams (squads) with product management, engineering, QA, UX research and design

In short

DocuWare is a B2B SaaS platform for document management and workflow automation: companies use it to capture, process, route, archive and retrieve business documents – from invoice intake to audit-proof filing. Thiago Andrade, founder of Beabstracto, worked there from February 2023 to February 2026 as a permanently employed UX/UI Designer in Munich. Focus areas: usability of the Workflow Designer, configuration-heavy enterprise flows, design-system foundations (tokens, Figma migration, documentation), and UX benchmarks, quality rituals and OKRs that made UX quality measurable in a mature product.

Why this matters to you: whether a DMS is actually used by the business department is decided when workflows are configured and by whether users can complete their tasks with confidence. Beabstracto brings this experience to DMS/ECM rollouts on the customer side and to product teams at software vendors – independently, with no licence sales.

Starting point

What was the starting point? A mature B2B SaaS product with a large, heterogeneous user base – and, at its centre, a tool that is powerful and therefore demanding: the Workflow Designer.

Companies use DocuWare to capture and index business documents, route them through review and approval processes, archive them in a GoBD-compliant way and retrieve them. The typical case in the German Mittelstand is digital invoice intake: an invoice arrives, is indexed, passes through content review and approval – often under the four-eyes principle – and ends up in accounting and in the archive. Mail intake, contract files and HR processes work in a similar way.

The heart of this automation is the Workflow Designer. In it, administrators and key users model how a document moves through the company: which condition triggers which step, who decides, what happens with exceptions, when to escalate. A configuration mistake rarely shows up while clicking; it shows up later in operation – when a case is stuck in a loop or an approval reaches nobody.

The people who configure such flows are rarely software developers. They are IT leads, department heads and key users who look after the DMS alongside their actual job. They need precision, predictable behaviour and clear feedback – not more features.

The design task was therefore not to draw prettier screens. It was to help enterprise users understand document processes, configure workflows, handle exceptions and complete tasks efficiently – inside a mature product ecosystem where every change affects existing customers. There was a second mandate as well: helping the organisation mature its UX practice, with research routines, design-system standards, usability benchmarks and quality rituals across several product teams.

During this time, Thiago Andrade was a permanently employed UX/UI Designer in several squads and worked closely with product management, engineering, QA, UX research and other designers. This case is therefore not a consulting engagement by Beabstracto. It shows what experience the studio brings to its clients from three years inside a DMS vendor.

The problem

What was the problem? Less a single defect than an accumulation of friction in configuration-heavy flows. Interviews, usability studies and structured feedback sessions kept surfacing the same four patterns in the Workflow Designer – navigation, progressive disclosure, feedback and task completion – and behind them two organisational causes.

Losing your bearings inside the workflow
A workflow consists of steps, conditions, roles and exceptions. Anyone working deep inside a branch easily loses the overview: where am I, what have I already configured, what is still missing? Navigation had to carry the context instead of hiding it.
Everything at once instead of step by step
Configuration screens showed many options at the same time – including those that only matter later or in special cases. Convenient for experts, overwhelming for key users. What was missing was progressive disclosure: the necessary first, the possible on demand.
No clear feedback
Is the workflow valid? Was the change saved? What state is this step in? Where states were not visible, ambiguity arose – and ambiguity in a configuration tool means asking around, trial and error, writing a ticket.
Uncertainty at completion
Enterprise users need precision and predictable behaviour. When it remains unclear whether a task is really finished and what happens on save or activate, users hesitate – or they rely on support and partners instead of the product.
Inconsistent patterns across product areas
Across teams and years, spacing, sizing, radii, elevation and component behaviour had drifted apart. Each product area felt slightly different; users had to learn interaction logic more than once, and teams built similar things more than once.
UX quality as a matter of taste
Without a shared measure, design was decided by opinion. What counts as "good enough" was undefined – and therefore could not be prioritised against new features.

How we approached it

How did we proceed? From as-is analysis through benchmark and prototype to validation and quality rituals – always together with product management and engineering, and with the ambition of basing decisions on research and data rather than taste.

1
As-is analysis and research
Understand first, then design. Interviews, usability studies and structured feedback sessions with users showed where configuration flows stall – not as a wish list, but as observed friction: searching, hesitating, abandoning, asking. The synthesis became a shared problem definition with product management and engineering.
2
Setting up a UX benchmark
For improvement to be demonstrable, it needs a baseline. Together with UX research, benchmarks were defined, oriented towards established models such as the User Experience Questionnaire (UEQ) and Hassenzahl's distinction between pragmatic quality (can I complete my task efficiently and safely?) and hedonic quality (does the product feel coherent, modern, trustworthy?). This made it possible to compare the Workflow Designer before and after changes.
3
Concept and prototype
Based on the findings, user flows, wireframes and high-fidelity designs for navigation, progressive disclosure and state visibility took shape – as interactive prototypes shared early with product management, developers and QA. Technical limits of the existing system were treated not as obstacles but as constraints built into the concept.
4
Validation and decision
Prototypes were tested in usability tests and concept validations; structured UX reviews recorded the outcomes. The decisive move was bringing research insights, benchmark data and product decisions together – so that the team argued about findings, not opinions.
5
Design-system foundations
In parallel, the work went to the foundations: design tokens for spacing, sizing, radii, elevation and responsive behaviour, the migration to Figma, component specifications and documentation. In design critiques and system discussions with other designers, patterns shared by several product areas were aligned – and consistency became a shared responsibility rather than an afterthought of individual teams.
6
Quality rituals and OKRs
So that UX quality would not depend on individual projects, improvement rituals were established and UX audit checklists developed; benchmark results fed into OKRs as inputs linking usability and product quality. UX thus became a measurable quantity in the organisation's goal system – not an acceptance step at the end.

Outcome

What is the outcome? More understandable configuration flows, a more consistent product, and an organisation that measures UX quality instead of arguing about it. We do not publish internal benchmark values for confidentiality reasons; we describe the change qualitatively.

Aspect	Before	After
Orientation in the Workflow Designer	Context lost in deep branches; users search for their own position	Navigation carries the context; visible what is configured and what is still missing
Configuration screens	All options at once, including those for special cases	Progressive disclosure: the necessary first, advanced options on demand
Feedback and states	Unclear whether changes are valid and have been saved	States visible, feedback where the action happens
Task completion	Hesitating, trial and error, asking support	Predictable behaviour; users know when they are done
Design system	Spacing, sizing and components drifted apart per product area	Shared tokens, Figma library and documentation across squads
UX quality	A matter of taste, not prioritisable against features	Benchmarks, rituals and OKR inputs; comparable before and after changes

Workflow-heavy flows easier to use
The usability improvements in the Workflow Designer and in configuration flows started where research had shown the friction: navigation, progressive disclosure, feedback, task completion. Less ambiguity, more visible states, more understandable configuration.
A design system as lived practice
Token foundations, Figma migration, component specifications and documentation created the basis for more consistent product areas. Consistency moved from an afterthought of individual teams to a shared responsibility.
UX quality made measurable
Benchmarks, rituals and OKR inputs linked usability to product outcomes. Design quality was no longer a subjective opinion but a quantity that can be tracked over time and weighed against other priorities.
Better collaboration across squads
Sharing early, structured UX reviews and design critiques improved collaboration between design, product management and engineering – local product needs and shared patterns were balanced against each other instead of played off against each other.

What we learned

01
A DMS rollout rarely fails at the archive – it fails at configuration
Whether a document management system is adopted by the business department is decided when workflows are set up: invoice approval, mail intake, contract files. Those who understand processes first and configure afterwards – as-is analysis before the first click – save rework, tickets and frustration among key users. For rollout projects this means: process mapping, functional concept and key-user support belong in the project plan, not in hypercare.
02
Pragmatic quality first, hedonic quality not forgotten
In expert applications, what counts first is whether users complete their tasks efficiently, safely and with few avoidable problems. But a product that feels dated or contradictory loses trust – and trust decides adoption and usage. Both dimensions belong in the benchmark, and both belong in prioritisation.
03
Measure instead of arguing
A UX benchmark with a baseline turns design debates into decisions. It need not be academic; it must be repeatable and tied to goals the product team pursues anyway – for instance as an OKR input. The same applies to customers introducing a new system: those who measure before go-live can show after go-live what has changed.
04
Consistency is a substitute for training
Every interaction pattern users only have to learn once saves training time and support requests. Design tokens, documented components and shared patterns are therefore not a design luxury but a contribution to rollout costs and support load – at the vendor as much as at the user company configuring its own screens and workflows.
05
Share early, take technical limits seriously
In a mature product with existing customers, not every good idea can be implemented. Those who share concepts early with engineering, validate assumptions and build technical constraints into the concept deliver solutions that land – not drafts that age in the backlog. This holds in a software vendor's squads just as much as in a rollout project between business department, IT and implementation partner.

What we delivered

User flows
Wireframes
High-fidelity designs
Interactive prototypes
Usability test plans
Research synthesis
UX benchmark reports
Design system documentation
Design tokens and component specifications
UX audit checklists
Cross-team product patterns (cross-squad patterns)
UX quality inputs for OKRs

Frequently asked questions

Can you improve our DocuWare workflows?: Yes – from the user's perspective. We map your processes (invoice intake, approvals, mail intake, files), check with your key users where workflows and configuration get stuck, and produce a functional concept that your DocuWare partner or your IT implements. We sell no licences and do not configure against your existing partner; we make sure that what gets configured is understood and used by the business department.
Are you a DocuWare partner?: No. Beabstracto is not a DocuWare partner, not a reseller and not commissioned by the vendor. Thiago Andrade was employed there as a UX/UI Designer from February 2023 to February 2026; Beabstracto is independent and advises without licence sales. This case describes experience from a permanent position, not a consulting engagement.
What do "pragmatic and hedonic quality" mean in practice?: Pragmatic quality asks: do users complete their task efficiently, safely and with few avoidable problems? Hedonic quality asks: does the product feel coherent, modern, trustworthy? We work with benchmarks oriented towards models such as the User Experience Questionnaire (UEQ) and Hassenzahl's distinction, and make both comparable before and after changes.
We are a software vendor, not a DMS user – is this a fit?: Especially then. Configuration-heavy modules, workflow editors, admin interfaces and design-system foundations are the core of this experience. We support product teams with research, benchmarks, prototypes and design-system work – as external UX capacity that works inside squads, not as an agency throwing designs over the fence.
We are facing a DMS rollout or the move to the web-based Workflow Designer. Where do you start?: Before configuration. We map the as-is processes, formulate the target state with the business department in a functional concept, test critical workflows with key users before go-live, and support training and hypercare. The move to a new Workflow Designer generation is the right moment to clean up legacy in the workflows rather than migrating them one to one.
Where does the content of this case come from?: From the publicly described profile of the permanent position. We do not publish internal benchmark values, customer names, team sizes or product internals. That is why you find qualitative before/after descriptions here instead of percentages.