Reorganising complex back-office workflows around operational decisions
Role
Company
Timeline
UX Designer
Booksy
2021-2022
Scope of work
Workflow discovery · Internal tools · Data-heavy UX · Interaction design · Design systems · Engineering collaboration
CONTEXT
Booksy’s internal teams used a data-heavy back-office platform to manage customer issues, business accounts, appointments, payments, and fraud-related cases.
The project combined a visual redesign with changes to selected workflow logic. The goal was not simply to reduce interface complexity, but to reorganise the product around the decisions operational teams needed to make, so relevant information could be understood and acted on more quickly.
My role covered end-to-end workflow discovery, information architecture, interaction design, prototyping, reusable component design, and close collaboration with Product and Engineering.
CHALLENGE
How might we help operational teams navigate complex, data-heavy workflows and make faster, more confident decisions without removing the specialist information they rely on?
Support, Operations, and Risk teams worked with large volumes of customer, business, payment, appointment, and technical data.
The platform contained the information required to resolve cases, but its structure often reflected backend entities rather than the sequence of operational work. Related records were spread across multiple views, frequently used actions appeared in inconsistent locations, and users had to rely on memory to understand where to look and what to do next.
The challenge was to reorganise the experience around operational tasks and decision points while preserving access to specialist information. The solution also needed to support different roles and workflows without creating a separate interaction model for each team.
DISCOVERY
Discovery focused on how work was completed in practice, rather than how processes were formally documented.
I facilitated interviews and workflow-mapping sessions with Support, Operations, Risk, Product, and Engineering stakeholders. The work included:
stakeholder and user interviews;
contextual observation;
workflow mapping;
task analysis;
technical reviews;
iterative reviews of flows and prototypes.
This research exposed gaps between documented processes and the way operational teams actually completed their work.
One of the most important findings came from employees responsible for repetitive operational tasks. Because they handled the same part of the process every day, they had identified an outdated verification step in the contract-signing journey.
The step introduced unnecessary friction close to completion, but had remained largely invisible to stakeholders working across broader areas of the product. The finding reinforced the importance of involving users whose work may appear narrow but who often hold detailed knowledge of where operational processes break down.
Potential improvements were evaluated against task frequency, operational risk, user effort, decision complexity, business relevance, technical feasibility, and their potential for reuse across workflows.
SOLUTION
☞ Organise information around operational decisions
Selected views were reorganised around operational tasks and decision points rather than backend entities.
Customer, business, appointment, payment, and case information was grouped according to the questions users needed to answer when investigating and resolving a case. Primary context, supporting details, and available actions were separated more clearly to make complex records easier to scan and interpret.
☞ Create a predictable action model
Available actions depended on the current screen, case type, role, and permission level.
I introduced a reusable quick-actions bar that provided a consistent location for the most relevant operations while allowing its contents to adapt to the user’s context and permissions.
This improved predictability across the product without forcing different workflows into one rigid interaction model.
☞ Strengthen patterns for data-heavy workflows
Working within the existing design system, I refined and extended reusable patterns for:
tables;
filters;
statuses;
summaries;
action areas;
validation;
detail views;
context-dependent operations.
Some designs needed to extend beyond the existing design system because specialist workflows required forms and interaction patterns tailored to specific case types.
The designs were reviewed iteratively with operational users, Product, and Engineering to validate workflow assumptions and clarify edge cases, permissions, technical dependencies, and implementation constraints. This was particularly important because backend limitations directly shaped which interactions were feasible and which states, exceptions, and safeguards the interface needed to support.
OUTCOMES
Consolidated access to related customer, business, payment, and appointment information
Selected workflows reorganised around operational tasks and decision points
Reusable quick-actions model introduced for context-dependent operations
More consistent interaction patterns established for data-heavy internal tools
Clearer implementation scope defined for Product and Engineering
A wider process issue identified through research with operational users
REFLECTION
Internal tools create hidden operational costs when their structure reflects technical architecture more closely than the work users need to complete.
The most effective design decisions came from understanding how operational teams assembled context, where they repeated work, and which actions required the most interpretation before a case could progress.
The project also reinforced that organisational visibility does not determine the value of user insight. Employees responsible for repetitive tasks often develop the clearest view of process failures that remain invisible to stakeholders working across broader areas of the product.
