Tagaddod's field teams collect used cooking oil from restaurants and households. Their work happens across customer visits, collection routes, and daily operational targets.
On-ground sales agents register and reactivate restaurants. B2B collectors collect oil from businesses, while B2C collectors visit households and exchange collected oil for gifts.
The roles were connected by one operation, but the tools supporting them were fragmented. Workers moved between applications and forms, searched elsewhere for missing information, and sometimes had to recover from failed submissions.
I initiated the project, secured approval from the Chief Product Officer, led the research and product design, validated the concept with workers, and handed the final information architecture and UI to product managers for engineering coordination.
Collectors relied on dedicated Collector applications. On-ground sales agents used one web form to register a restaurant, another to create an order, and a separate application that acted as a launcher for those forms. Managers also worked through the company's internal admin tool, which was used to manage operational records across the business.
The fragmentation became part of the job. Workers moved between tools, searched elsewhere for information that should have been present, and sometimes faced reliability issues while saving data. When something went wrong, they called technical support or their managers to keep moving.
From a distance, this could look like a collection of interface problems. In practice, it affected the operation itself. Every interruption sat between a worker and the task they needed to complete.
The operation between systems
The operation ran on 14 tools across 3 roles. Only 4 crossed a role boundary, and 1 reached all three.
On-ground sales
Acquire, reactivate, repair customer data, create orders
Branch, contact, price, and follow-up context lived in different places.
B2B collector
Plan the route, fund the trip, weigh, pay, and close
The digital order did not carry the cash, capacity, or physical proof needed to finish it.
B2C collector
Confirm households, exchange gifts, close and reconcile
When quantities or gifts changed, the collector became the bridge between customer, app, and warehouse.
Carried by B2B collector and B2C collector. A phone, a map, and the app they both open. None of it is specific to the work either one was doing.
Carried by all 3 roles
The one tool common to the whole operation was a chat app. Nothing that carried the work itself ever crossed all three.
Managers were the integration layer. They answered exceptions, checked screenshots, reconciled statuses, and moved information from one tool to the next.
The initial conversation was about improving existing applications and reducing the cost of maintaining them. I proposed a broader question: could we bring different field roles into one application without flattening the differences between their jobs?
After receiving approval from the Chief Product Officer, I treated the project as an investigation before treating it as an interface redesign.
The goal was not to place several old tools behind one menu. It was to discover whether the operation had a shared structure that could support current roles and future field work. Merging the applications also created another opportunity: the person closest to a task could act on it, even when that task did not traditionally belong to their job title.
This was already happening in the field, without any formal process behind it. A manager would call a collector and ask him to visit a restaurant on his route and register it, or to check on a business the team had not heard from in a while. The work was assigned over a phone call, carried out by whoever was nearby, and recorded later by someone else in a different tool. The operation was already treating roles as flexible. The software was the part still insisting they were fixed.
The application could not be understood from a screen inventory alone. I needed to see how decisions moved from managers to workers, how a restaurant became an order, and how an order became a completed collection.
The completed research log contained 11 moderated interviews: five collectors across B2B and B2C, one on-ground sales agent, and five people responsible for dispatch, sales, areas, and commercial coordination. I also conducted three day-long contextual inquiries, following a B2B collector, a B2C collector, and an on-ground sales agent through their real work. Interviews typically ran for 30–45 minutes; a field day averaged roughly eight hours.
Interviews gave me the language people used for their work, how they believed it should happen, and what their managers expected. App walkthroughs exposed specific usability and reliability problems. Shadowing revealed the work people had stopped mentioning because it had become normal: planning routes in their heads, waiting for cash, repairing contact data, keeping paper backups, and calling someone when the system could not carry an exception.
I coded the notes and observations, grouped the codes into themes, and compared the patterns across workers and managers. I then translated the themes into task flows and an object model. This kept a reported interface problem connected to the operational condition that produced it.
Method
Field evidence
Who was in the log
Observation days ran across B2B, B2C, and on-ground sales.
Capture the work
Make sense of it
Model the system
The maps separated two streams that happen at the same time. The first is the work required to create demand and collect UCO. The second is the monitoring and support that keeps that work moving when a price changes, a customer disappears, cash runs out, a vehicle fills up, or an application fails.
The B2B journey begins before an order exists. Leadership sets targets, an OGS agent plans a territory and acquires or reactivates restaurants, the customer verifies the request, commercial and dispatch teams build a viable trip, and a collector weighs, pays for, and closes the collection. The B2C study begins at the collection request: dispatch, gift custody, customer confirmation, routing, measurement, order closure, and warehouse reconciliation.
Two streams and the work beside them
Both streams end in a collected order. They do not start in the same place, and neither runs alone.
Stream 01
B2B: create demand, then collect UCO
The order is the handoff between commercial and operations
Set targets
Plan territory
Acquire or reactivate
Verify the order
Build and fund trips
Collect, weigh, pay
Verify fulfillment
Stream 02
B2C: execute an existing collection request
Demand generation sat outside this study
Receive agreed orders
Assign trips
Check gifts and route
Call and navigate
Measure and exchange
Close each order
Return and reconcile
Runs throughout
Monitoring and support
Both streams, all day, unscheduled
This changed the unit of analysis. An order was not one card in an app. It was a handoff across people, money, vehicle capacity, customer availability, physical measurement, and evidence. A technically completed form could still describe an operationally incomplete job.
Completed orders could return after refresh, live orders sometimes appeared only after clearing application data, and order history could disagree with what the collector had completed. A worker could not simply pause the route. They repeated work, sent screenshots as proof, reinstalled the app, or continued without certainty.
A collector could receive the wrong phone number, branch, location, or agreed price. A sales agent might need the current restaurant contact while completing a step, yet have to retrieve or correct it through WhatsApp, Slack, a sheet, or another form. The interface presented the action without reliably carrying the context needed to complete it.
A B2B collector planned around factory unloading, restaurant time windows, cash availability, truck capacity, live orders, and the probability that a customer would answer. A B2C collector balanced household availability, unreliable locations, gift custody, and quantity disputes. Experienced workers adapted the sequence constantly; the route in the application was only one input.
Sales acquisition, restaurant reactivation, collection orders, and collected oil all contributed to shared operational goals. That finding gave the project its structure.
The manager interviews made the other side of the system visible. Sales and OGS leaders monitored new customers, requests, orders, collected volume, average price, month-to-date progress, and performance by agent and zone. Dispatchers watched whether collectors had unloaded and started, which orders were completed or reported, whether a route still fit the vehicle and available cash, and why a trip had not closed.
They were not only monitoring people. They were managing constraints and exceptions: a price outside the agreed range, an absent restaurant contact, a Fawry branch without cash, a broken collection pump, a live order added after planning, or a suspicious pattern of duplicated orders. Because the systems did not join these signals, managers reconstructed the state of the operation from Metabase, spreadsheets, the company's internal admin tool, WhatsApp, phone calls, and personal judgment.
Thematic analysis made the recurring causes visible across roles. A failed close and an inaccurate archive belonged to a reliability theme. Wrong contacts, branches, prices, and locations belonged to data integrity. Route workarounds, cash delays, custody reconciliation, and unanswered support groups revealed responsibilities the product did not yet represent.
From field signal to product requirement
| Coded evidence | Theme | What the product must carry |
|---|---|---|
| Completed orders returned after refresh; archives disagreed. | Reliability and trust | Offline-safe state, visible sync, and an audit trail |
| Locations, phone numbers, branches, and prices were often wrong. | Context and data integrity | One versioned customer, branch, contact, and location record |
| Collectors planned routes in their heads around time windows. | Field judgment | Editable route plans that respect timing, capacity, and live work |
| Cash, gifts, barrels, pumps, and vehicle load could block a trip. | Custody and readiness | A pre-trip resource ledger with explicit handover and return |
| WhatsApp groups carried issues, but ownership and response were unclear. | Coordination | Structured exceptions with an owner, status, and next action |
| Workers carried loss risk while managers reconstructed fulfillment. | Accountability and incentives | Evidence, attribution, earnings, and progress on the same work item |
The shared spine was not a screen. It was the relationship between a worker, an operational goal, the work that advanced it, and the resources and evidence required to finish safely.
Across regions and roles, work was organised around targets. A region could pursue a quantity of collected oil, a number of newly registered restaurants, or the reactivation of inactive restaurants. Those goals were then translated into work for the people on the ground.
Collectors usually received a defined list of orders for the day. Sales agents often received a broader outcome and decided how to reach it. The jobs were different, but both could be understood through the same chain of intent and action.
Different roles were not the problem. The absence of a shared operational model was.
The interface frames below come from the product prototype and use sample values rather than live customer or employee records.
I used a compact object model to turn the research into product architecture. Rather than beginning with screens, I identified the stable things in the operation, their relationships, and the actions people could take.
The first model connected Worker, Target, Task, and Action. Mapping the final system expanded it with Trip, Earnings, and Custody. Those additions were not feature categories. They represented conditions already shaping the work: grouped execution, compensation and incentives, and the money, gifts, equipment, or containers a worker needed to hold and reconcile.
One model for different kinds of field work
Roles configure the starting experience. Objects and their relationships make work portable across roles.
Workerhas and works towardTargets
TargetcontainsTasks and/or direct Actions
TripgroupsTasks and Custody
Taskis completed throughActions
Actioncontributes progress toTargets
Workerholds and receivesCustody and Earnings
Core object glossary
Calls to action belong to objects
Attributes such as priority, due time, location, vehicle, quantity, currency, status, and progress make each work type configurable without creating a new application.
This was enough OOUX to make the system legible without turning the design into an academic exercise. The model gave product and engineering a shared language while keeping the worker experience concrete. Each object carried its own attributes and actions: tasks had type, priority, due time, location, and status; trips had zone, vehicle, capacity, and progress; custody had type, quantity, value, and return status. New work types could be configured from those parts instead of requiring another application.
Some targets arrived with a list. A collector opened the day and saw the orders that needed to be completed. A sales agent could receive a list of restaurants to reactivate. In both cases, the target contained defined tasks.
Other targets described an outcome without prescribing every step, such as acquiring a number of new restaurants. In that case, the worker needed direct access to actions and the freedom to decide how to reach the goal.
This distinction prevented the new application from forcing every role into the same flow. The structure was shared, but the work remained role-specific.
Assigned work
Collect these restaurant or household orders today
The system provides the work. The worker sequences, completes, or reports it.
Open-ended work
Acquire new restaurants in this zone this month
The system provides the outcome. The worker decides where and how to act.
Expected extensions
Modelled, not tested
Transfer custody
Move assigned money, equipment, or containers from point A to point B and confirm the handover.
Resolve a field problem
Visit a specified restaurant, investigate an assigned issue, and record the outcome and next action.
The research and usability testing covered collection and on-ground sales. The object model also suggested a broader class of field work, but these extensions remained product hypotheses rather than validated outcomes.
For example, a manager could assign a worker a task to transfer custody from point A to point B. The task would carry the origin, destination, custody type and quantity, due time, and the evidence required to confirm the handover. Another task could send a worker to a specific restaurant to investigate and resolve a specific problem, then record the outcome and any next action.
In this broader framing, the product is an application for on-ground work organised around targets. A target defines the outcome, a task assigns a concrete piece of field work, actions record how it was completed, and custody is attached when the worker must carry or transfer company resources.
The old tools assumed that each kind of work belonged to one job title. An on-ground sales agent would visit a zone to find newly opened restaurants and collect leads. A collector could pass the same restaurant during a collection route, but the Collector app did not give them the sales actions needed to do anything with that opportunity.
The merged application changed the relationship between roles and actions. A collector could create a request for a customer instead of passing the lead to another team. In the other direction, an on-ground sales agent with access to a vehicle and a nearby warehouse could create an oil collection order and complete the collection immediately.
Separate applications
A worker's job title determined which application they opened and which actions were available, even when they were already in the right place to complete another task.
One operational application
The worker's role shaped their home experience, but it did not become a hard boundary. Shared actions could be used when the situation and the worker's capabilities made them relevant.
This flexibility did not remove the meaning of a role. Collectors and sales agents still had different priorities, targets, and default workflows. The difference was that the product no longer treated a job-description label as a limit on what a person could contribute to the operation.
One home, shaped by role. Each worker would enter the same application but see the priorities, tasks, and actions relevant to their job.
Context at the point of action. Customer and branch details should appear where the worker needs them, not in another tool.
Visible progress. Targets should make the relationship between daily work and operational goals clear.
Reusable actions. Registration, order creation, and collection confirmation should become building blocks rather than isolated forms.
I moved from architecture to interactive prototypes and tested them with field workers across approximately two rounds.
The central question was not whether the interface looked new. It was whether a worker could recognise what mattered and know what to do without a long explanation.
The home screen became the main focus of iteration because it had to bring role-specific actions, assigned work, and progress into one clear starting point. Workers needed to understand what required attention and what they could do next without having to learn the underlying model.
Feedback led to adjustments that improved the visibility and comprehension of the home experience. The final design made the concept understandable before the system was formally explained.
Visual to add
Home-screen evolution
The information architecture and UI design were delivered in two phases.
Phase 01 consolidated existing work. The Collector app became a shared operational application that supported collectors and on-ground sales actions. The target model was intentionally left out of this first release.
This created a practical bridge from the old tools to the new system. Teams could migrate existing workflows before adopting a new way of organising work.
Phase 02 introduced targets. The shared application could now connect operational goals to tasks, actions, and visible progress.
Visual to add
Two-phase rollout
The clearest outcome was adoption. Collectors and on-ground sales agents moved to the new application as part of their daily work.
An on-ground sales agent described the new version as easier and less buggy. Collector feedback followed the same direction. Managers also reported receiving fewer application-related calls from workers.
Outcome
Task completion was understood to have improved, but a reliable post-launch completion rate was not available. This is a directional signal, not a quantified claim.
Across approximately two and a half months, I initiated the opportunity, framed the brief, and secured approval from the Chief Product Officer.
I planned and conducted the interviews and field shadowing, analysed the evidence, modelled the operational architecture, designed the UI, built prototypes, and led worker validation.
I then handed the information architecture and final designs to product managers, who coordinated the next stage with engineering.
The most important design decision was choosing the right unit of design. The old tools were organised around forms and departments. The new system was organised around workers, targets, tasks, and actions.
We did not make collectors behave like sales agents. We created a shared structure that could respect both jobs and still give the company one foundation for future field operations. The application could present a role-specific starting point while still allowing people to take on useful work beyond the traditional boundaries of that role.
The result was a shared foundation that workers could recognise and adopt, while leaving room for future field operations.
