ANODA Discuss your product

Warehouse robot command center, desk to aisle

Vecna Robotics puts autonomous robots to work beside people in warehouses.We designed its CaseFlow Console, handheld app and Customer Alerts.

CaseFlow Console Live Map: robots listed with their state and battery beside the warehouse floor from receiving to shipping, with location-state filters; Customer Alerts on a tablet at 1024 by 768: active alerts by severity with type, time, robot, location, message and claim buttons
192
screens across the Console, the handheld and Alerts
3
products the Console, the WS50 handheld app and Customer Alerts
3
people from ANODA on the project

Vecna Robotics runs warehouse picking with autonomous robots and people working the same orders. We started with a UX and UI audit of the existing CaseFlow Console and went on to redesign it , with its live monitoring and analytics . Then came a dark update of the Associate app on a Zebra WS50 handheld and a new Customer Alerts module, all built on UI kits and a custom icon set .

What runs through CaseFlow

One chain, from setting up a shift to closing an alert:

  1. Setup

    • Shifts and times
    • Associates
    • Robots
    • Demands

  2. Operations

    • Robots
    • Demands
    • Associates

  3. Monitor

    • Shift progress
    • Associate performance
    • Exceptions
    • Live map

  4. Analytics

    • Exceptions
    • Heat maps
    • Robot activity

  5. Handheld

    • Sign-in and location
    • Scan the robot
    • Pick and confirm
    • Report a problem

  6. Alerts

    • Claim and release
    • Snooze
    • Reassign
    • History
Everything Readable
Every robot, mission and picker in view, without a wall of numbers.
Right now Over time
The live shift in Monitor, its patterns in Analytics, never mixed.
Desk Aisle
The full picture at a desk; one big, scan-first step at a time in the aisle.

A shift, read top to bottom

Found
Shift Progress holds robots, cases, demands and lines, their averages and three charts; with every number at the same weight, a site lead can’t tell at a glance whether the shift is on track.
Decided
Four counts first, each split into its parts; then the pace of the shift; then its hours as charts, cases on their own, demands and lines below.
For the user
A site lead sees whether the shift keeps up, and where it doesn’t, before opening a single table.
CaseFlow Console Shift Progress: robots 48, cases 228, demands 256 and lines 126 with their breakdowns, average cycle, picking and dwell times, then cases, demand and lines charts from 1 AM to 8 AM
After: Shift Progress in the Console; the figures are example data

  1. Which shift

    The page, the shift hours and a refresh.

  2. The shift in four counts

    Robots, cases, demands and lines, each split into its parts.

  3. Pace

    Cycle, picking and dwell times, units per line.

  4. Cases, hour by hour

    Picked against waiting across the shift.

  5. Demands and lines

    What’s done, in progress and new.

How the work progressed

The existing console and the people on the floor first, then the flows, then grey boxes, then the final screens and a file engineering could build from.

  1. Discovery

    What in the existing console got in the way, and who actually works the floor

    Artifact A UX and UI audit of the Console, and warehouse-associate personas and context of use

  2. User Flow

    How shifts, robots, demands and alerts connect, and what the handheld asks at every step

    Artifact Information architecture and user flows for the Console, the Associate app and Customer Alerts

  3. Wireframes

    Where each list, map and chart sits before any colour, over several iterations

    Artifact Wireframes of setup, live monitoring and analytics

  4. UI & UI kits

    One visual language for the Console in light and dark, and a handheld that reads in the dark

    Artifact Final Console, Associate and Alerts screens, UI kits, reusable components and a custom icon set

  5. Delivery

    What Vecna’s team needed to build each screen and state

    Artifact A screen map, clickable prototypes and a client-ready Figma handoff

Three places, one set of paths

Found
One task passes through a handheld, a web console and an alert queue, and a path that works in one place breaks in the next.
Decided
Each path was mapped before a screen was drawn: the picker’s sign-in to the first task, the check that the right robot has arrived, and who may act on an alert. Then each place got the menu its user needs.

  1. Handheld: sign-in to the first task

    Badge or credentials, a location, then the tasks, or an idle home when there are none.

    Open the full map
    WS50 user flow: splash, welcome, scan badge or sign in with credentials, loading, scan location, then the home screen with or without tasks, each step with its content and error pages

  2. Handheld: is this the right robot?

    A mismatch checks whether the picker may take that robot’s tasks, then offers a retry or a typed ID.

    Open the full map
    WS50 user flow: scan the robot at the location; if it doesn’t match the picker’s tasks, two kinds of wrong-robot error, no-tasks and invalid-ID errors, and manual robot ID entry

  3. Alerts: who may act

    Claim, release, a collision with someone else’s claim, and a request to reassign.

    Open the full map
    Customer Alerts user flow: has the user already claimed an alert, has someone else claimed this one, the warning pop-ups, the reassign request and its approved or denied notifications
The Console’s side menu with Monitor open (Live Map, Shift Progress, Associate Performance, Exceptions Handling), Operations and Insights, beside the WS50 home: Start New Task, All Tasks, Scan Robot, Update Location, Shift Analytics, End Shift or Take Break, About

A menu for each place

Left, the Console: Monitor, Operations and Insights. Right, the handheld: one big first action, the rest below it.

  • User flows
  • Information architecture
  • Screen map
  • Clickable prototypes

Ten jobs, from the aisle to the command center

The picker’s handheld first, then the Console a manager watches, then the alerts between them. Every name and figure on these screens is example data.

A task a gloved hand can finish

Found
A picker has to meet one robot at one spot, often in gloves and sometimes with little English; a screen full of options loses them.
Decided
One step per screen on the WS50: where to go, which robot to scan, what to pick and how many, then done. Each step has a big label, a scan-first action and a colour that says whether it worked.
WS50 screens: Scan Robot at Location with location Pick_Spot_2, robot CF1 and the order ID, then Processing with the scanned robot CF1
WS50 screens: Scan Pick Face pick2 waiting for the scan, then Confirm Quantity Picked, item 1 of 1, quantity 2
WS50 Task Complete screen in green: confirm release of the robot, task time 11m 18s

When a scan doesn’t match

Found
A wrong robot or a wrong pick face stops both the picker and the robot, and a vague error leaves the picker guessing.
Decided
Every error says what went wrong in plain words and offers the way back: scan again, type the robot ID or go home. A location error shows what was expected next to what was scanned.
WS50 error screens: Wrong Robot Scanned, the scanned robot doesn’t match your tasks; and Error, no robot found with the provided ID, with Retry Scan, Enter Robot ID Manually and Return to Home
WS50 screens: Enter Robot ID with CF1 and Confirm, then Location Verification Error, expected pick2, scanned pick123, with Retry Scan

Problems reported from the aisle

Found
A full pallet or fewer items than requested: the picker finds out first, and the Console needs to know at once.
Decided
The problem is reported from the pick itself: the reason, the quantity actually there on a stepper or the keypad, and a clear answer on whether a short pick is allowed.
WS50 screens: Skip pick, Pallet Full, with Confirm; then Enter Available Quantity, requested 6, with a stepper
WS50 screens: Enter Available Quantity with the on-screen keyboard, then Short Pick Allowed, requested 6, available 3, continue to perform short pick

Breaks that don’t lose the shift

Found
Picking is physical work; a break or the end of a shift shouldn’t leave a task or a robot hanging.
Decided
Ending the shift and taking a break are two separate choices, and the break screen shows the time away with one button to come back.
WS50 screens: End Shift or Take Break with End Shift and Sign Out and Start Break, then On Break, time elapsed 10 minutes, with End Break

Every robot, and what it’s doing

Found
A manager needs to spot the robot that’s stuck, and what it was doing, in a fleet of dozens.
Decided
State as a coloured chip on every row, current and last mission side by side, the queue as a number; each robot opens to its mission: status, customer, robot, associate, location and cases.
Console Robots table: robot IDs with names, state chips such as Stop, Initiation, Manual, About to Drive, Navigating and Offline, current mission, mission type, last mission, missions in queue and location
Console mission page for robot J151 Brandi: status in progress, priority 3, customer Walmart, the associate, location 32-049-052, mission type Wait for Interaction, 12 cases, 4 SKUs, demand type and created time

Robots and pickers on one map

Found
When an aisle is blocked, where robots and pickers are right now matters more than any table.
Decided
A live map of the warehouse with robots and associates on two tabs, each listed beside the map with its state and location, and a filter by location state.
Console Live Map with the Associates tab: associates listed with picking, en-route, idle, on-break and offline statuses and their locations, beside the warehouse map from receiving to shipping

Demands in the order they matter

Found
Orders arrive by priority and customer, and a list sorted only by time hides the urgent ones.
Decided
One demands table: status, priority, customer, the robot assigned, cases, SKUs and times, with sorting and filters for priority and customer.
Console List of Demands: demand IDs with statuses in progress, unallocated, completed and abandoned, priority, customers such as Walmart, Home Depot, Costco and Walgreens, the assigned robot, cases, SKUs and created and completed times

Exceptions handled while the shift runs

Found
A short pick or a full pallet reported from the aisle is useless if the Console shows only a code.
Decided
Each exception opens with what’s needed to act: type, reporter, pick face, demand, robot, resolution and the item, beside the missions it touches.
Console exception details: created time, type Short Pick, reporter, pick face location, demand and order IDs, status Reported, robot J151 Brandi, resolution Incomplete, item description, SKU, required and available quantity and retry attempts, beside the missions list

Patterns after the shift

Found
What went wrong once is an exception; what goes wrong every day is a pattern, and it hides in the live view.
Decided
Analytics kept apart from monitoring: exceptions by day and by type, and heat maps of picks by location and of robot activity across the floor.
Console Exceptions analytics: average exception picks per day from 1 to 14 May as a line chart, and the breakdown into short pick, cannot pick and pallet full as bars
Console Heat Map of picks at locations: 240 picks in total, the busiest locations listed with their pick counts, and the warehouse floor coloured from 0 to 80 plus picks
Console Heat Map of robots’ activity: 18 robots listed with their activity counts, the activity type filter open on 3D sensor false positives, and the floor coloured by activity

Alerts one person owns

Found
An alert two people act on at once gets handled twice, or not at all.
Decided
Claim before acting: a claimed alert unfolds into its message and actions; someone else’s claim stops you with who and since when, and a way to ask for it; and snoozing says what will happen.
Customer Alerts with a claimed critical alert expanded: navigation to charge location 32-049-052 is blocked, interaction required, with Release Alert and Unblock
Pop-up: This Alert Is Already Claimed by Madeline Grant since 21:05, with the alert’s details, Request reassign and OK
Pop-up: Snooze This Alert, moving it to the Suppressed tab until the snooze period ends, with the duration in hours, minutes and seconds

UI kits, not a design system

Found
Three places, light and dark at the desk, dark only in the aisle, and every screen needed the same answers for statuses, empty data and loading.
Decided
UI kits for the Console and the handheld, reusable components and a custom icon set, not a full design system: enough that a new screen was assembled, not drawn again.

One empty state, every module

When there is nothing to show, each module says so the same way, and says why.

  • Associate Performance with no data: empty figures, and the UPH and cases charts each showing No Data to Display, please add data to the system
    Associate Performance: No data yet for this shift.
  • Exceptions Handling with an empty table: No Data to Display, currently there is no exception in the warehouse
    Exceptions Handling: No exceptions in the warehouse.

Shift Progress while it loads

The screen from the top of the page before its data arrives: placeholders in the shape of what’s coming, so nothing jumps when it lands.

  • Shift Progress loading: grey placeholders in the shape of the counts, the pace and the three charts
    Loading

Light and dark Console

Console modules were drawn in both themes; the handheld runs dark only.

Exceptions Handling in the light theme: exceptions with time, type, reporter, location, demand, status, robot, resolution and cannot-pick reason
The same Exceptions Handling screen in the dark theme

Customer Alerts from desk to tablet

Kept
The table’s order: severity, type, time, robot, location, message and who claimed it, and the Active, Suppressed and Resolved tabs.
Changed
The side menu folds to icons at 1024 and behind a menu button at 768; the table keeps its columns and scrolls sideways instead of squeezing them.
Customer Alerts at 1440 pixels: the full side menu and seven active alerts with severity, type, time, robot, location, message and claim buttons or the name of whoever claimed them
1440 · Desktop Full menu, every column in view.
The same alerts at 1024 by 768: the side menu reduced to icons and long messages truncated
1024 · Tablet, landscape Menu as icons, messages shortened.
The same alerts at 768 by 1024: the menu behind a button in the top bar and the table scrolling sideways
768 · Tablet, portrait Menu behind a button, the table scrolls.

A handoff Vecna’s team could build from

Each product ended in organised client files rather than a folder of screens.

UI kits
Colours, type, buttons, inputs, messages and states for the Console and the handheld.
Custom icon set
Icons drawn for the Console’s menus, tables and maps.
Screen map
Every module’s screens and states laid out in order and linked.
Clickable prototypes
The Console flows and the handheld flows, clickable end to end.

Flows in the handoff

  1. UI audit of the existing Console
  2. Wireframes
  3. Console dashboard: robots, pickers, demands and exceptions
  4. Associate performance: patterns after the shift
  5. Customer Alerts: who may act on each alert
  6. Screen map and clickable prototype
  7. Text styles
Screen map for Associate Performance: four Console screens connected by labelled arrows, with a sticky note for the developers
Screen map: Associate Performance: the screen, its sort menu and its no-data state, linked in order.
Three WS50 UI kit pages on dark: buttons in default, disabled and pressed states, inputs and their states, and the icon set
WS50 UI kit: Buttons, inputs and icons for the handheld, in every state.

Where the product ended up

CaseFlow redesigned as one product across three places: a Console that sets up the shift, shows robots, demands, pickers and exceptions live and reads the patterns afterwards, in light and dark; a dark, scan-first handheld on the Zebra WS50 that walks a picker through each task, error and break; and Customer Alerts that one person claims, snoozes, hands over and resolves, with its history, on desktop and tablet.

Delivered to Vecna’s own team as UI kits, a custom icon set, a screen map and clickable prototypes; we didn’t design the robots’ own interface, and we don’t claim results for the warehouse.

screens across the three products
192
connected products: Console, handheld app, Customer Alerts
3
people on the ANODA team
3
Console themes
Light + dark

In the client's words

ANODA brought the console views into a shared design language. We appreciated the attention to dense operational information and consistent controls, giving the team concrete layouts to review across desktop and tablet use.

Rebecca Li Product Manager, Vecna Robotics

5.0

Afraid your people and your robots will drift out of step?

We designed CaseFlow so a manager at a desk, a picker in gloves and a robot fleet work from the same state of the shift. Bring us your product, and we’ll show you where the handoffs between them break.

Discuss your product Explore more case studies

What we brought to Vecna Robotics

The product

The interface and the work