Evreka Fieldwork.
Connecting the plan to the people in the field.
At Evreka, I designed systems for internal planning software used by Oscar Circulair. Working with developers and a project manager, I connected route planning, collector activity, working hours, ETAs, and communication into a coherent operational experience.
View design system- Role
- Product design & system design
- Period
- 2022–2024
- Product context
- Evreka · For Oscar Circulair
- Team
- Design, developers & project manager
Interface redesign for this case study · Sample operational data
A moving operation.
A shared understanding.
Planning agents coordinate collectors whose work changes throughout the day. They need to know who is working, what is happening now, which routes remain, and whether the next collection still fits the plan. A useful interface connects those questions instead of treating the map, timeline, and employee record as separate destinations.
Design the system.
I was responsible for system design across the planner experience: the relationship between routes, jobs, people, time, and communication.
Work through delivery.
I worked in a team with developers and a project manager, connecting operational requirements with interface and workflow decisions.
Support real operations.
The software is used as internal tooling at Oscar Circulair. Its scope includes Google Maps API routing, team timelines, ETAs, working hours, and employee communication.
What needs my attention, who can act, and what changes for the rest of the day?
What the current app makes visible
The supplied collector screenshots show a route list and Google Maps view, task details, attached access information, and the outcomes “Open taak”, “Geen Afval”, “Probleem”, and “Voltooid”. Long addresses and repeated metadata occupy much of the task view, while useful access instructions sit in a separate media view.
The redesign below carries those operational needs forward, with a clearer hierarchy and a connected planner view.
Design the relationships.
Then design the screens.
My system-design responsibility was to connect the planner’s overview with what collectors needed to do. The model below explains that relationship and makes the rules behind the interface inspectable.
Crew & working time
Who can perform the work, during which shift, and with which scheduled breaks. Availability is a planning constraint, not just profile information.
Route & ordered stops
A route groups work in a sequence. Selecting a route should preserve the same context across map, timeline, and stop details.
Service point & task
A collection task belongs to a service point with an address, access instructions, material details, and an outcome.
Progress & ETA
Scheduled times describe the plan. Actual activity describes what happened. ETAs express an estimate and should show when the information was updated.
Message & acknowledgement
Communication belongs to the affected crew, route, or task. Sending an instruction and receiving acknowledgement are different system states.
- One selectionChoose Crew 01 on the map and keep Crew 01 selected in the timeline and detail panel. The user should not have to rebuild context.
- Time has provenanceKeep planned time, latest estimate, and actual completion distinct. A stale location should not be presented with the confidence of a live update.
- Exceptions have an ownerA blocked stop needs a next action and someone responsible for resolving it. A coloured marker alone is insufficient.
- Changes have consequencesBefore publishing a reassignment, show the affected crew, remaining shift time, and changed stops. Keep the previous plan until the change is confirmed.
The model and rules are a retrospective explanation and a basis for the interface redesign.
From planning desk
to collection point.
A change made in planning becomes an instruction in the field. A collector’s update then changes what the planner needs to see. This journey map follows that loop.
Review outstanding routes, employee availability and working hours.
A route may fit geographically but exceed the available shift.
Bring route duration and crew capacity into the same planning context.
Assign a route and communicate the plan to collectors.
A sent update does not mean the crew has seen it.
Distinguish a draft, a published update and an acknowledged change.
Inspect current work, ETAs and reported issues.
A map pin alone does not explain the effect on the rest of the day.
Connect each exception to the route, next stop and remaining working time.
Review completed jobs, no-waste outcomes and unresolved stops.
A route can be finished while an individual collection still needs follow-up.
Keep route closure separate from task outcome and make unresolved work visible.
Read the complete journey
- Plan — Build a workable day
Review outstanding routes, employee availability and working hours. A route may fit geographically but exceed the available shift. Bring route duration and crew capacity into the same planning context.
- Dispatch — Give the crew a clear next step
Assign a route and communicate the plan to collectors. A sent update does not mean the crew has seen it. Distinguish a draft, a published update and an acknowledged change.
- Respond — Handle change in context
Inspect current work, ETAs and reported issues. A map pin alone does not explain the effect on the rest of the day. Connect each exception to the route, next stop and remaining working time.
- Close — Account for unfinished work
Review completed jobs, no-waste outcomes and unresolved stops. A route can be finished while an individual collection still needs follow-up. Keep route closure separate from task outcome and make unresolved work visible.
Make the next decision
easier to see.
Map-first control room
Strong geographic orientation, but capacity and unfinished work can disappear behind pins and filters. It asks the planner to remember time while looking at space.
Map + timeline + context
The map shows where, the timeline shows when, and a focused panel explains what needs attention. The tradeoff is information density, managed through a shared selection and progressive detail.
Find the task details.
- Repeated addresses compete with the stop name.
- Task outcome and the action to change it look similar.
- Access instructions require opening a separate media view.
Understand the next action.
- A short service-point name, ETA, and next step lead.
- A status label explains the current state; a separate action changes it.
- Relevant access guidance appears before collection starts.
Observation
The current task view gives substantial space to metadata while the action sits at the bottom.
Design change
Bring the next stop and access instructions forward, then group completion, no-waste, and problem reporting as explicit outcomes.
Validation
Check whether collectors can identify the next task and choose the correct outcome without confusing state with action.
A plan that can change
without losing its meaning.
The planner wireframe puts team capacity below the geographic overview and keeps the selected exception alongside both. Supporting details appear only when they help the next decision.
Collector flow: act, report, recover.
The mobile flow follows the job, with a clear way to report a blocked collection and return to the route.
“Problem reported” is not “problem resolved”. Keep the job visible until someone decides what happens next.
A shared language for
every operational state.
The component study brings the planning workspace together: route information, crew activity, task outcomes, and feedback share a consistent visual language.
States with meaning
Task badges, route markers, and alerts pair colour with a readable label, keeping progress and exceptions distinct.
Context that carries across
Route cards, tables, and detail panels connect the same crew, task, and ETA across different views.
Feedback at every step
Confirmation dialogs, notifications, and empty states explain what happened and what to do next.
One operational language.
Different views of the work.
The desktop composition prioritizes exceptions, then gives the planner enough route and shift context to judge the response. The mobile view prioritizes the next stop, access instructions, and a clear task outcome.
Service entrance unavailable. Collector is waiting for instructions.
Interface design study · Kadaster / PDOK geographic basemap and sample operational data. On small screens, scroll the detailed desktop view horizontally.
Map data: Kadaster / PDOK · CC BY 4.0. Portfolio interface studies with sample content.
Reusable patterns, with explicit states.
Progress is a sequence.
Ordered stops and current work use the same identifiers across screens. Completion updates the task while preserving the route context.
Outcomes stay distinct.
Both may close a visit, but they describe different collection results. Labels carry the meaning alongside colour.
Exceptions remain visible.
A blocked stop stays in the planner’s attention queue with the reason, affected crew, and a route back to the task.
Communication has feedback.
A route change is not silently treated as accepted. The planner can distinguish publication from acknowledgement.
Delivery considerations
Freshness: show the last update time and an explicit unavailable state when a location or ETA is missing.
Concurrent changes: check the latest route version before confirming edits; explain conflicts instead of silently replacing someone else’s work.
Map dependency: a service-point list and ordered stops remain useful when map tiles or routing estimates cannot load.
Responsive behaviour: keep the desktop’s dense planning workspace separate from the collector’s focused task hierarchy. Reuse state names and interaction rules, not the same layout everywhere.
Test the decisions
that carry operational risk.
The first useful test is a realistic planning scenario, not an A/B test of colour or button placement. These checks are a validation plan for the redesign.
- Find the risk. A collector is delayed and a shift is ending. Ask a planner to identify the affected route and explain what needs attention. Look for missed exceptions and confusion between planned times and ETAs.
- Change the plan. Reassign a remaining stop. Check that the planner reviews working hours, understands which tasks move, and knows whether the crew has acknowledged the change.
- Report from the field. Ask a collector to find access instructions and report a blocked collection. Observe wrong outcomes, unnecessary navigation, and confidence that planning received the update.
- Recover from uncertainty. Simulate a stale location, unavailable map, or competing edit. Check that the next action is understandable and the previous plan is preserved.
A shared route context and explicit exception states help planners make a correct decision without repeatedly switching views.
Primary evidence
Correct identification of affected work, unassisted task completion, and accurate explanation of the resulting state.
Guardrails
Wrong-crew assignments, work scheduled beyond a shift, missed acknowledgement, and accidental closure of unresolved tasks.
Decision rule
Resolve repeated state or assignment errors before expanding the design. Compare the split layout with a map-first alternative using the same scenarios; assess accuracy and confidence alongside speed.
Systems design for
work that happens outside.
The original work supported internal planning software used at Oscar Circulair. My contribution at Evreka connected operational workflows through system design, in collaboration with developers and a project manager.
The redesign makes that systems thinking tangible: one route context, a timeline grounded in working hours, explicit task outcomes, and communication that remains connected to the work.
I would document the state model and decision history alongside the screens from the start, then test changes with both planners and collectors. A cleaner control room is only useful if the instructions it creates are equally clear in the field.
Project context: Evreka ↗. Interface review based on current-app screenshots.