FEATURE DESIGN
FEATURE DESIGN
⋅
DELIVERY OPERATIONS PLATFORM
DELIVERY OPERATIONS PLATFORM
Designing for the moment before a decision becomes irreversible.
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.
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
ROLE
UI/UX Designer
UI/UX Designer
SCOPE
SCOPE
SCOPE
End-to-end feature design
End-to-end feature design
TIMELINE
TIMELINE
2 weeks
2 weeks
TEAM
TEAM
2 designers
2 designers
STATUS
STATUS
Delivered to Client
Delivered to Client
NDA Notice:
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.
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
Background
A standard brief that turned into something more
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.
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.
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
Exploring the Problem
Two jobs hiding inside one brief
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.
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.
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.
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
Understanding the User
The person this was built for hadn't been hired yet
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:
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.
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
A Problem Within the Problem
Balancing the team wasn't the whole answer
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.
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 ?
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.
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
The Core Design Tension
How much should the system decide on its own?
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.
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
The Design Principle
One idea that shaped everything else
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 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.
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
Add New Agent
Show the projected workload before confirming.
Show the projected workload before confirming.
02
Enable/Disable Agent
Enable/Disable Agent
Show projected workload before enabling; show who absorbs the work before disabling.
Show projected workload before enabling; show who absorbs the work before disabling.
03
Delete Agent
Delete Agent
Require the workload to be reassigned before the final confirmation is even reachable
Require the workload to be reassigned before the final confirmation is even reachable
The Design
The Design
What was built, and why it landed here
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.
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
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?
The landing page here is designed to answer one question without the admin having to ask: is anything off?
Workload Management
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.
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
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.
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
Administrative Flow
01
Adding Agent
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.
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
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.
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
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.
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
Intended Outcomes
What this design was built to influence
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.
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
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.
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.
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.