Original project visual
01 / Cube Storage
The challenge
Explain a dense robotic warehouse through a clear relationship between robot activity, picking ports and order state.
Reading the problem / Cube Storage
Movement needs to explain the order.
The storage simulation links robot travel, bin retrieval and visible order progress.
The storage-and-retrieval system is a simulation. Order progress and state transitions are part of the prototype experience.
How can people understand retrieval progress without interpreting robot motion alone?
Evidence: the project account and the attributed artifacts on this page. Process drawings and interaction studies are reconstructed explanations; numerical research or business results are included only where separately supported.
02 / Cube Storage
The approach
A deterministic robot simulation produces snapshots consumed by the 3D scene, order panels and KPI histories. A shared component system keeps controls and data presentation consistent across the operations suite.
03 / Cube Storage
My contribution
- Built the warehouse exterior, interior storage grid and interactive robot inspection.
- Connected simulated bin retrieval and port activity to order-stage tracking.
- Designed KPI panels, operational tabs and camera controls using the shared suite components.
The process / Cube Storage
A direction.
A way to build it.
A retrieval sequence needs a readable status model alongside robot movement.
A schematic of sequence and overlap, not a dated project schedule.
Follow the order
Identify the order and bin that give a robot movement its purpose.
Define retrieval states
Separate waiting, route planning, movement, blockage and completion.
Explore route and status views
Connect the simulated bin movement with a visible order-progress account.
Review interrupted retrieval
Explain when someone should wait and when the request needs revision.
How can people understand retrieval progress without interpreting robot motion alone?
An order becomes a bin request, a planned movement and a retrieval result. A viewer should be able to follow that progression without interpreting every robot animation. Explicit status connects the visible movement to the reason the system is moving at all.
Journey map / Cube Storage
See the whole task in context.
Choose a step to connect the person’s intent with the interface and the design decision.
Current intent
Receive an order
The storage-and-retrieval system is a simulation. Order progress and state transitions are part of the prototype experience.
- Interface context
- Order queue
- Review question
- What does the user need to know while a retrieval is still in progress?
Representative task sequence and recovery path, not a measured emotional curve or historical research map.
Behind the experience
The visible task depends on work behind it.
For Cube Storage, this map connects “Receive an order” to “Retrieve the bin”. Read across to follow the task, then select a layer to inspect the interface, design and delivery references behind it.
| Layer | Receive an order | Select a bin | Plan robot movement | Retrieve the bin |
|---|---|---|---|---|
| The task | Receive an order | Select a bin | Plan robot movement | Retrieve the bin |
| Visible interface | Order queue | Order queue | Bin & route view | Retrieval status |
| Design checkpoint | The storage-and-retrieval system is a simulation. Order progress and state transitions are part of the prototype experience. | Identify the order that started the retrieval. | Connect the selected bin to its planned movement. | Report the retrieval state independently of the animation. |
| Implementation reference | Identify the order and bin that give a robot movement its purpose. | Separate waiting, route planning, movement, blockage and completion. | Connect the simulated bin movement with a visible order-progress account. | Explain when someone should wait and when the request needs revision. |
| Recovery | Retrieval unavailable → explain the current state → revise the route or request | |||
A reconstructed delivery map: the implementation row summarizes design-process dependencies, rather than claiming to document the original backend architecture.
Anchor movement to a retrieval task.
Reconstructed comparison of design approaches. These are review studies, not a claim that both directions were historically tested or shipped.
What this direction changes
Anchor movement to a retrieval task
Explains why a robot moves and which order it serves.
Keep the request visible beside the route.
The order queue, bin-and-route view and retrieval status are reconstructed as linked surfaces. They distinguish a request waiting for action from a movement in progress and a completed retrieval. The diagrams explain the simulation’s state model, not a deployed warehouse control panel.
01 / Order queue
0102Order queue
Selected contextSelect a binOverview ↔ Detail
Select a bin
Identify the order that started the retrieval.
02 / Bin & route view
0102Bin & route view
Selected contextPlan robot movementOverview ↔ Detail
Plan robot movement
Connect the selected bin to its planned movement.
03 / Retrieval status
0102Retrieval status
Selected contextRetrieve the binOverview ↔ Detail
Retrieve the bin
Report the retrieval state independently of the animation.
Try the interaction
Cube Storage / Selection & context study
Cube Storage01 / 03
View 01
Order queue
Identify the order that started the retrieval.
Selected contextOrder queue
Identify the order that started the retrieval.
Starting context
Receive an order
Order and bin identifiers should remain easy to compare.
Give order IDs, bin IDs and retrieval states stable roles. Motion should supplement explicit status text.
Illustrative type-role specimenCube Storage
Receive an order.
Retrieve the bin.
HeadingBin & route view
24 / 30 px · regularBodyHow can people understand retrieval progress without interpreting robot motion alone?
16 / 26 px · regularLabelRetrieve the bin
12 / 18 px · regularStateRetrieval unavailable → explain the current state → revise the route or request
12 / 18 px · regularPortfolio-font hierarchy illustration; the source does not establish the exact client font or token scale.
Explain waiting as carefully as completion.
What does the user need to know while a retrieval is still in progress?
A retrieval in progress should retain the order and bin context. Motion alone cannot tell a user whether the system is acting on the expected request.
How is a blocked request distinguished from a completed or queued request?
Queued, blocked and completed requests need different language. Collapsing them into an inactive visual treatment would hide whether someone needs to wait or change the request.
Map each visible status to the retrieval sequence.
The storage-and-retrieval proof of concept connects robot movement with order progress. Handoff should identify which operation is queued, which transition is being simulated and what evidence the UI uses to show completion or a blockage.
An agent-supported update should preserve the relationship between order, bin and route. Review interrupted and unavailable retrieval examples alongside the successful sequence, using the simulation rather than inventing live operations data.
Cube Storage is an operations simulation; its movement and progress views should be read within that prototype boundary.
Accessibility & standards
Access belongs in the design.
For these operational workflows, prioritize readable status data, non-color alerts, accessible approval controls and a 2D alternative to spatial inspection.
WCAG 2.2 AA · EN 301 549 · APCA · WAI-ARIA · Platform guidance
Make spatial information available in another form
Provide a meaningful 2D or text route to tasks and data presented in 3D. Review keyboard, pointer and assistive-technology access to the surrounding interface.
Reduce visual and physical demands
Plan readable labels, non-color status cues, stable interaction targets and alternatives to precision gestures. Respect reduced motion and avoid relying on camera movement to communicate state.
Separate usability from safety assurance
Use ISO 9241-210 human-centred design principles and relevant platform guidance alongside WCAG 2.2 AA and EN 301 549 review. Industrial usability work is not evidence of safety certification.
Review scope & standards references
These are design references and review priorities, not a claim that this historical project passed a WCAG audit. Record criterion-level evidence, assistive-technology and device results, unresolved issues and retest outcomes before making a conformance statement.
APCA supplements the WCAG 2.2 contrast checks; it does not replace them. WCAG 3 remains a draft. EN 301 549 v4.1.1 is the latest published edition checked on 6 November 2026; its publication and its formal EU legal citation are separate matters. Confirm the applicable procurement or legal baseline with the client.
Outcomes & scope
What the work delivers.
- Browser simulation with sample orders. It demonstrates workflow engineering and visualization, without claiming integration with physical robots or a production warehouse control system.
Results are described within the documented project scope. Illustrative studies are identified separately from original project artifacts.
Review & next iteration
What needs to hold up in use.
Use these questions to review Cube Storage against the behavior the design is intended to support.
- 01
Can an operator find the order associated with a moving robot?
- 02
Is a blocked or interrupted retrieval distinguishable from progress?
Project-specific acceptance questions for a future review, not reported usability-test results.
Reflection / Cube Storage
What I’d carry forward.
A storage visualization is most useful when it explains an operation. The next prototype should keep robot movement connected to state, intent and an understandable recovery path.