Go Back

FEATURE DESIGN

⋅

DELIVERY OPERATIONS PLATFORM

Designing for the moment before a decision becomes irreversible.

Designing for the moment before a decision becomes irreversible.

One feature within a larger control tower and how a two-sentence brief became a system for managing people, work, and the relationship between them.

ROLE

UI/UX Designer

SCOPE

End-to-end feature design

TIMELINE

2 weeks

TEAM

2 designers

STATUS

Delivered to Client

NDA Notice:

This project was completed under NDA. The company name, logo, brand colours, and screen designs have been modified. Domain-specific workflows, client references, and business rules have been generalised. This case study focuses on the product reasoning, system logic, and UX decisions behind the feature — not the company context.

Background

Exploring the Problem

Understanding the User

A Problem within the Problem

The Core Design Tension

The Design Principle

The Design

Intended Outcomes

Honest Reflection

Background

A standard brief that turned into something more

This feature was part of a larger project, an internal control tower for a delivery operations platform. There were 2 aspects to this, which were the Agents who handled the the larger burden of overseeing every order, and the Admin that handled exceptional scenarios while also monitoring the agents and their work. This case study covers one part of the admin's role.

This feature was part of a larger project, an internal control tower for a delivery operations platform. There were 2 aspects to this, which were the Agents who handled the the larger burden of overseeing every order, and the Admin that handled exceptional scenarios while also monitoring the agents and their work. This case study covers one part of the admin's role.

The Brief:

The Brief:

Require standard admin controls — add agents, remove them, enable or disable accounts, reassign work between agents

Require standard admin controls — add agents, remove them, enable or disable accounts, reassign work between agents

The brief seemed straightforward at first, but as I dug deeper into the problem, it became clear that the feature was not really about giving admins more controls. When agents become overloaded, things rarely fail in an obvious way. When tasks get missed, follow ups are delayed, and work starts slipping through the cracks. The real challenge was helping admins spot workload risk early enough to take action before it affected customers. That reframing is where the design work actually started.

The brief seemed straightforward at first, but as I dug deeper into the problem, it became clear that the feature was not really about giving admins more controls. When agents become overloaded, things rarely fail in an obvious way. When tasks get missed, follow ups are delayed, and work starts slipping through the cracks. The real challenge was helping admins spot workload risk early enough to take action before it affected customers. That reframing is where the design work actually started.

Exploring the Problem

Two jobs hiding inside one brief

The first thing I tried to map out was every action the brief described — add, remove, enable, disable, reassign and what each one touched. What I realized was that every single action had a workload consequence. Remove an agent and their workload need to go somewhere. Add one and existing work should shift to include them. Disable someone for two weeks and the remaining team absorbs the load.

The first thing I tried to map out was every action the brief described — add, remove, enable, disable, reassign and what each one touched. What I realized was that every single action had a workload consequence. Remove an agent and their workload need to go somewhere. Add one and existing work should shift to include them. Disable someone for two weeks and the remaining team absorbs the load.

That made the brief's framing incomplete. It described account management. What it actually required was account management and workload management, working together, because separating them meant the admin would be making consequential decisions without the context to make them well.

That made the brief's framing incomplete. It described account management. What it actually required was account management and workload management, working together, because separating them meant the admin would be making consequential decisions without the context to make them well.

The structural decision here was to have Workload Management sit within Agent Management, appearing only when it was relevant. Rather than expecting admins to actively monitor workload issues, the system would surface risks at the right time and guide them to where action was needed.

The structural decision here was to have Workload Management sit within Agent Management, appearing only when it was relevant. Rather than expecting admins to actively monitor workload issues, the system would surface risks at the right time and guide them to where action was needed.

Understanding the User

The person this was built for hadn't been hired yet

The bigger challenge was designing for a user who did not exist yet. There was no admin to interview or observe, as the role would only be filled after launch. Without access to real behaviors or workflows, the persona had to be pieced together from the information that was available:

The bigger challenge was designing for a user who did not exist yet. There was no admin to interview or observe, as the role would only be filled after launch. Without access to real behaviors or workflows, the persona had to be pieced together from the information that was available:

What emerged was a picture of someone new to the role, juggling multiple responsibilities and lacking the context to judge workload health on their own. They needed to know immediately whether something required attention, so the design focused on making workload status clear at a glance rather than relying on numbers that had to be interpreted.

What emerged was a picture of someone new to the role, juggling multiple responsibilities and lacking the context to judge workload health on their own. They needed to know immediately whether something required attention, so the design focused on making workload status clear at a glance rather than relying on numbers that had to be interpreted.

A Problem Within the Problem

Balancing the team wasn't the whole answer

The initial direction was straightforward: make sure no agent carries significantly more than anyone else. Build a way to redistribute work when the distribution gets uneven. That seemed like the core of what workload management needed to do. But working through the problem raised a harder question.

The initial direction was straightforward: make sure no agent carries significantly more than anyone else. Build a way to redistribute work when the distribution gets uneven. That seemed like the core of what workload management needed to do. But working through the problem raised a harder question.

What if the work volume increases to the point where every agent equally has more than they can handle ?

To solve this, a productivity index metric was introduced, tracking how many tasks an agent resolves in an hour. Over time, this metric would define a meaningful daily capacity threshold. When incoming volume sits consistently above it, the question for the admin stops being about redistribution and starts being about whether the team needs to grow. For the initial scope, the index is observational — the system hasn't built up enough history to set a reliable threshold yet. So the workload comparison uses team average as its reference line, with the expectation that it evolves as real data comes in.

To solve this, a productivity index metric was introduced, tracking how many tasks an agent resolves in an hour. Over time, this metric would define a meaningful daily capacity threshold. When incoming volume sits consistently above it, the question for the admin stops being about redistribution and starts being about whether the team needs to grow. For the initial scope, the index is observational — the system hasn't built up enough history to set a reliable threshold yet. So the workload comparison uses team average as its reference line, with the expectation that it evolves as real data comes in.

The Core Design Tension

How much should the system decide on its own?

Before designing any screens, the harder question was deciding how much of the workload assignment the system should handle and how much control should stay with the admin. Three directions were explored, but as each one was thought through, two of them revealed clear trade-offs that ruled them out.

Before designing any screens, the harder question was deciding how much of the workload assignment the system should handle and how much control should stay with the admin. Three directions were explored, but as each one was thought through, two of them revealed clear trade-offs that ruled them out.

The Design Principle

One idea that shaped everything else

The semi-automated approach created a specific need: if the admin was going to confirm a redistribution proposal, they needed to actually see the consequences of their changes before confirming.

The solution was a preview that showed exactly how workloads would change before anything was applied. Admins could see the impact of a redistribution, catch potential issues, and make adjustments before confirming it. Instead of asking them to trust the system, it gave them enough context to make an informed decision. Once that principle was established in the redistribution flow, it naturally extended to every other action in the feature.

01

Add New Agent

Show the projected workload before confirming.

02

Enable/Disable Agent

Show projected workload before enabling; show who absorbs the work before disabling.

03

Delete Agent

Require the workload to be reassigned before the final confirmation is even reachable

The Design

What was built, and why it landed here

These are the final screens, along with the thinking behind them. Every major interaction is here because it solved a specific problem or made a deliberate trade-off.

These are the final screens, along with the thinking behind them. Every major interaction is here because it solved a specific problem or made a deliberate trade-off.

Agent Management — Landing Page

Agent Management — Landing Page

The landing page here is designed to answer one question without the admin having to ask: is anything off?

The landing page here is designed to answer one question without the admin having to ask: is anything off?

Workload Management

Workload Management

The distribution chart and alerts panel work together to show the current state. The alerts surface issues such as an unassigned brand, an inactive agent, workload that drifted higher without anyone noticing. Here the admin arrives at a decision rather than a dataset.

The distribution chart and alerts panel work together to show the current state. The alerts surface issues such as an unassigned brand, an inactive agent, workload that drifted higher without anyone noticing. Here the admin arrives at a decision rather than a dataset.

Redistribution Flow

Redistribution Flow

The flow followed four simple steps: select brands, choose a receiving agent, review the impact, and confirm. Agents were automatically ranked by workload to guide better decisions, while a preview made the consequences of the redistribution visible before any changes were applied.

The flow followed four simple steps: select brands, choose a receiving agent, review the impact, and confirm. Agents were automatically ranked by workload to guide better decisions, while a preview made the consequences of the redistribution visible before any changes were applied.

Administrative Flow

Administrative Flow

01

Adding Agent

Adding Agent

Admin reviews projected workload distribution after entering details — how brands redistribute and whether the new agent's expected load sits at Normal, Moderate, or High relative to the team.

Admin reviews projected workload distribution after entering details — how brands redistribute and whether the new agent's expected load sits at Normal, Moderate, or High relative to the team.

02

Disabling an agent

Disabling an agent

Two options: until manually re-enabled, or until a specific return date for planned leave. A redistribution preview follows showing how the remaining team absorbs the load.

Two options: until manually re-enabled, or until a specific return date for planned leave. A redistribution preview follows showing how the remaining team absorbs the load.

03

Deleting an agent

Deleting an agent

If active workload exists, deletion is blocked. Admin resolves it first — reviewing and confirming redistribution — before the final confirmation screen is reachable. The action is permanent, so the sequence is enforced.

If active workload exists, deletion is blocked. Admin resolves it first — reviewing and confirming redistribution — before the final confirmation screen is reachable. The action is permanent, so the sequence is enforced.

Intended Outcomes

What this design was built to influence

The product hadn't launched when this shipped to development. These aren't the results but they are the questions the design was built to answer once it does.

The product hadn't launched when this shipped to development. These aren't the results but they are the questions the design was built to answer once it does.

Honest Reflection

What this version doesn't do, and what working on it taught me

Because the admin role hadn't been filled yet, direct user research wasn't an option. Instead, the persona was built from a combination of client conversations, operational context, task dependency mapping, and edge case analysis — a proxy research approach for when primary access isn't available. The tradeoff was that assumptions couldn't be validated against real behavior, which is why the design prioritised strong reasoning over confident conclusions.

Because the admin role hadn't been filled yet, direct user research wasn't an option. Instead, the persona was built from a combination of client conversations, operational context, task dependency mapping, and edge case analysis — a proxy research approach for when primary access isn't available. The tradeoff was that assumptions couldn't be validated against real behavior, which is why the design prioritised strong reasoning over confident conclusions.

One of the biggest lessons from this project was learning to make design decisions without having all the answers. With limited data and no real users to validate assumptions, the focus shifted to building strong reasoning behind each choice. Looking back, the preview model reflected that mindset by giving admins the same opportunity to make informed decisions before committing to a change.

One of the biggest lessons from this project was learning to make design decisions without having all the answers. With limited data and no real users to validate assumptions, the focus shifted to building strong reasoning behind each choice. Looking back, the preview model reflected that mindset by giving admins the same opportunity to make informed decisions before committing to a change.

Back To Home

Next Case Study

Productivity-first design for delivery field operations