RM
Warehouse management portal — role-based views for distributed teams

Logistics · Operations · Amazon

Bringing Clarity to Warehouse Operations Across Distributed Teams

Though the system technically functioned, it placed a high cognitive and coordination load on individual stakeholders and teams.

Amazon
Company
Amazon
Problem
Warehouse operations at scale
Focus
Clarity · Operations

Context

This project focused on designing a centralized warehouse management portal used by multiple internal teams to track operations, quality checks, and warehouse performance. The product was part of a larger enterprise ecosystem, where data already existed across different systems — but was fragmented, inconsistent, and difficult to act on. My role was to bring clarity to this complexity by designing a system that could support day-to-day operational decisions across roles without overwhelming stakeholders.

Problem

Though the system technically functioned, it placed a high cognitive and coordination load on individual stakeholders and teams.

Data inconsistencies made it difficult to trust reports. Teams struggled to align because updates lived in different tools. Critical decisions were often delayed or revisited due to missing context.

The core problem was not the absence of data, but the absence of clarity, trust, and shared visibility across roles.

Understanding the existing scenario

Warehouse operations were managed through a combination of internal tools, spreadsheets, and manual processes.

Each team maintained its own records for quality checks, inventory, and variance tracking. Data was updated independently across systems, often at different points in time.

Access to information varied by role, but there was no unified interface that reflected the end-to-end state of warehouse operations. As a result, users relied on experience and informal communication to fill in gaps.

View-to-Role Mapping

View-to-Role Mapping

Approach

Goal : To reduce cognitive load while maintaining accuracy, traceability, and operational reliability.

I followed a structured, iterative design process grounded in domain understanding and cross-functional collaboration:

  • Understanding stakeholder inputs and existing operational workflows
  • Synthesizing pain points through affinity mapping
  • Defining user roles and core decision-making workflows
  • Mapping critical user flows and dependencies
  • Exploring interactions through wireframes
  • Designing high-fidelity interfaces using the existing design system
  • Supporting development through handoff and design QA

Secondary Research

Due to project constraints, direct primary user research was limited. To make informed design decisions, I focused on secondary research, drawing an understanding from stakeholder inputs, existing systems, and operational artifacts.

The aim was to build a shared understanding of the domain before proposing changes.

Personas (Derived)

Personas were derived from stakeholder inputs and observed workflows, rather than direct interviews.

They were used as alignment tools to represent:

  • responsibilities
  • decision-making needs
  • access levels
  • information frequency

Primary personas included Project Managers and Quality Check Officers, with secondary personas such as Regional QC Officers and Third-Party Managers.

These personas helped ensure the interface supported realistic operational needs without overgeneralizing user behavior.

System-Level Exploration & Brainstorming

Before moving into screens, I explored the problem at a system level to understand how information flowed across teams.

This included:

  • mapping key workflows across roles
  • identifying handoff points where information broke down
  • exploring alternative ways to structure visibility and access

This helped ensure the designed solution addressed core operational issues rather than surface-level UI problems.

Flow 1
Flow 2

Exploring high frequency workflows

During system analysis, I focused on a few high-frequency workflows that shaped the product structure:

  • Variance Testing
    Identifying gaps between planned and actual execution (For warehouse blueprints) A repetitive, manual task used by Project Managers and internal staff.
  • Quality Checks
    Tracking quality across units and handling damaged items through structured records. Used by Project Managers, on-site staff, and QC officers.
  • Managing User Access
    Controlling access for internal and third-party users to reduce risk and maintain data security.

These workflows informed decisions around dashboards, permissions, and audit visibility.

This project operated within several challenges, rather than constraints, that shaped design decisions:

  • Limited access to direct end users due to operational and time constraints
  • Existing backend systems and data structures that could not be changed
  • A predefined design system that needed to be followed
  • Multiple user roles with different access levels and responsibilities

[05]Key Decisions

Role-based views
Key decision

Role-Based Views Instead of a Single Unified Interface

Rationale
  • Although users accessed the same underlying data, their responsibilities and decision needs differed. A single view for all stakeholders risked increasing cognitive load and reducing clarity.
Impact
  • Faster access to relevant information
  • Reduced clutter for day-to-day tasks
  • Improved adoption across roles
Quality check access – zone mapping
01 / 02
Key decision

Making Quality Check Access Explicit and Context-Aware

Rationale
  • Quality checks involved multiple teams working across large physical spaces. Earlier workflows relied on informal coordination to decide which areas were open for inspection, leading to confusion and unnecessary exposure to sensitive project information.
  • To reduce ambiguity, access needed to be clearly defined, traceable, and aligned with on-site workflows.
Impact
  • Clear scope for on-site quality checks
  • Reduced coordination overhead between teams
  • Better control over what information was visible during site visits
Solutioning
  • An access-map workflow was introduced, allowing Project Managers to mark specific zones on the blueprint that required inspection. These zones were then reflected on the Quality Check Officer's mobile view, showing only the areas open for access along with navigation support.
Permission controls – approval workflow
01 / 02
Key decision

Granular Permission Controls for Internal and Third-Party Users

Rationale
  • The system needed to balance collaboration with data security. Broad access to third party stakeholders increased risk, while strict controls slowed operations.
Impact
  • Improved data security
  • Clear ownership and accountability
  • Safer collaboration with external teams
Solutioning
  • User approval workflows were intentionally designed as gated actions.
  • Third-party users remained in a pending state until explicitly reviewed and approved. To prevent errors, approval actions were disabled for records undergoing edits, ensuring that review and modification could not occur simultaneously.
Project dashboard
Key decision

Project Dashboards for Decision-Making

Rationale
  • Project Managers needed to assess project health quickly without navigating through multiple sections. Existing workflows required piecing together information across modules, increasing cognitive load and slowing responses.
  • The challenge was to surface what mattered most, without overwhelming the user with raw data.
Impact
  • Faster assessment of project status
  • Reduced need to navigate across sections
  • More confident, timely decision-making by Project Managers
Solutioning
  • Each project was given a dedicated dashboard that prioritized milestone progress, readiness scores, safety status, and order states. Related actions, such as accessing documents or drilling into modules, were kept within reach without breaking context.
Mobile on-site quality check experience

Mobile experience for on-site quality checks

Key decision

Mobile Experience for On-Site Quality Checks

Rationale
  • Quality Check Officers performed inspections on-site while moving across large warehouse areas. Desktop workflows were impractical in these conditions, and users needed focused access to only what was relevant during a site visit.
Impact
  • Enabled effective on-site inspections
  • Reduced reliance on memory or offline references
  • Maintained consistency between planning and execution workflows
Solutioning
  • A mobile experience was designed to support on-site workflows such as viewing assigned zones, navigating to specific modules, and recording quality checks. The interface prioritized clarity, limited actions, and quick validation, while configuration and planning remained desktop-first.

Outcome

Outcome
  • Project Managers were able to assess project health quickly through centralized dashboards, reducing the need to navigate across multiple sections.
  • Role-based views and approval workflows helped maintain data integrity while supporting collaboration with third-party teams.
  • Clear traceability across quality and variance workflows improved confidence during reviews and audits.
  • Standardized inputs and structured workflows reduced inconsistencies in operational data.
  • The clarity and scalability of the system led to a Phase 2 engagement with the same client.
Reflection

This project involved designing within real operational and system constraints. Limited access to end users and fixed backend structures required decisions to be made based on system understanding, stakeholder input, and observed workflows rather than ideal scenarios. Designing both desktop and mobile experiences clarified the need to separate planning work from on-site execution. Treating these as distinct contexts helped reduce complexity and supported more focused use during quality checks. If revisited, the work would benefit from more validation in live on-site conditions to refine edge cases and reduce friction during high-volume usage.