Back to Work

Oracle SCM Smart Operations

Mobile Production
Reporting

Real-time material consumption reporting for factory operators — designed to work in gloves, in noise, in motion. No desktop required.

Timeline
3 Months
Role
UX Designer (Co-Lead)
Tools
Figma
Company
Oracle SCM Smart Operations
Mobile Production Reporting — feature overview

01 — The Problem

Tethered to the Desk

Oracle's Operator Workbench (OWB) is a comprehensive desktop application that lets operators report operation completions, issue and return materials, and report scrap. Powerful — but entirely stationary.

This created a real business gap: 30% of industrial manufacturers deploy mobile devices for production reporting. Operators were commuting to terminals between every task, breaking their workflow and introducing latency into the production record.

Production Operator persona — Josefina Miranda

Production Operator persona — responsible for running equipment and reporting material transactions.

The Goal

Empower factory operators to report material consumption in real-time at the point of work — eliminating the "commute" to a stationary desktop terminal entirely.

The Existing Desktop Experience

Operator Workbench: Report Materials Flow

OWB Step 1 — Work Order Details
Step 1 — Work Order Context
Operator navigates to a work order and reviews details before initiating material reporting.
OWB Step 2 — Report Materials
Step 2 — Report Materials
A dense data-entry form with multiple fields — designed for a mouse, keyboard, and large monitor.
OWB Step 3 — Material fields
Step 3 — Component Details
Lot, Serial, and LPN fields all visible simultaneously — information overload on a small screen.
OWB Step 4 — Submit
Step 4 — Submit Transaction
Confirmation and submission — a multi-step process that keeps operators away from the assembly line.

02 — The Conflict

Navigating the Ambiguity

The most significant challenge wasn't the UI — it was alignment. Three compounding obstacles threatened to derail the project before design could begin.

1
The Documentation Paradox No standard Requirements Doc existed — only fragmented bullet points and partial flows. Requests for clarity yielded massive, multi-page Excel spreadsheets with nested logic that often contradicted each other. No clear source of truth.
2
The Timezone Gap The PM team was based in India while the UX team was in PST — a strictly limited 1-hour window each morning to sync. Unanswered questions during this window caused cascading project stalls.
3
The "Stop-the-Line" Intervention After low-fi wireframes were rejected for not aligning with unwritten requirements, the team escalated — facilitating an alignment meeting to force a "Source of Truth" agreement and a live walkthrough of OWB business logic.
Initial low-fidelity wireframe explorations

Initial lo-fi wireframes built from fragmented documentation — rejected for not matching unwritten requirements.

Requirements documentation

An example of the fragmented requirements documentation — dense, nested logic that frequently contradicted other docs, with no clear source of truth.

03 — The Pivot

It's Not a Smartphone

Three weeks in, a review with the VP of Manufacturing Engineering revealed a massive oversight. The initial assumption: "mobile" meant a smartphone interface.

This was wrong.

Users weren't using iPhones — they were using rugged barcode scanners (Zebra/Honeywell). Bulky, industrial devices with small screens and physical keypads. The frame needed to be wider and shorter. And this wasn't a mobile view of OWB — it was a standalone application launched from the Oracle Fusion page.

The Discovery

This single insight shifted the entire UX philosophy — from "responsive web" to "industrial-first native app." Every design decision that followed was filtered through one question: does this work in a factory, with gloves, in low light, under noise?

Rugged barcode scanners — Zebra and Honeywell devices

The actual hardware: Zebra and Honeywell rugged scanners with physical keypads and small screens.

04 — Design Principles

Industrial-First Thinking

Initial "mobile site" mocks were abandoned in favor of three principles shaped by the physical environment — gloves, loud noise, motion, low light.

Three mobile design principles
01

Singularity of Purpose

Operators work in high-stress environments. The UI focuses on a single active task at a time — no clutter, no unnecessary navigation — to reduce decision fatigue.

02

Progressive Disclosure

Rugged scanners have limited screen real estate. Instead of showing all input fields at once, the system detects what each material requires and reveals only those specific fields.

03

Scan-Driven Navigation

Tapping a screen with gloves is difficult. The hardware's built-in scanner drives the UI — scanning a material automatically selects it and triggers the next logical input field.

05 — Component Exploration

The Anatomy of a Scannable List

Multiple iterations of the Redwood List Item component were explored to find the right balance between data density and instant glanceability on a small screen.

List exploration 1 — early iteration

Early exploration — all fields visible simultaneously, overwhelming on small screens.

List exploration 2 — tabbed view

Tabbed To Report / Completed split — better task separation but added navigation overhead.

List exploration 3 — final direction

Progressive disclosure approach — fields appear contextually as the operator scans.

List item component anatomy

Final anatomy of the scannable list item — three annotated zones for primary ID, status, and quick actions.

Hierarchy of Information

Primary Line: Material Number — the unique identifier operators look for first.

Secondary Line: Transact Quantity + Unit of Measure — exactly how much is needed, no extra tap required.

Status as Visual Shorthand

Pending (Grey): Work still to do.
Ready (Green): All data captured — serial, lot, LPN confirmed.

Operators can scan a long list and instantly see what remains without reading every row.

06 — The Solution

A Scannable, Reactive UI

The Redwood Design System was leveraged to create a high-density, efficient reporting experience. The happy path is entirely scan-driven — operators rarely need to type a single character.

State 1 — Material field in focus, Submit disabled

State 1 — Pre-issued materials listed with status badges. Submit disabled until all reported.

01

The Intelligent List

Pre-issued materials are displayed with clear Ready vs. Pending status badges for quick scanning in low-light factory environments. The material scan field is in immediate focus — no extra taps to begin.

State 2 — Material scanned, required fields revealed

State 2 — Scanning a material highlights it in the list and reveals only its required fields.

02

Scan-to-Reveal Logic

Once the operator scans a material barcode, the system detects what that specific material requires — Lot, Serial, LPN — and surfaces only those fields. No decision fatigue, no blank fields to ignore.

State 3 — All materials ready, Submit enabled

State 4 — All required fields filled. Badge flips from Pending → Ready. Submit activates.

03

Progressive Completion

As each material is scanned and its fields completed, the badge changes from Pending to Ready. The Submit button activates only when every material is accounted for — a built-in quality gate.

Detail Drawer — full-screen editor for complex entries

The Detail Drawer — a full-screen editor for split quantities and locator edits, accessible via the Edit icon.

04

The Detail Drawer

The primary "Happy Path" stays lean and scan-driven. For rare cases — like splitting quantities or editing locators — a full-screen drawer provides a complete editing surface without cluttering the main list. Complex tasks accessible but out of the way.

Final Issue Material UI — full flow

Final Issue Material UI — the complete scanning flow from list to submission.

07 — Additional Flows

Beyond the Happy Path

The core scanning flow handles the majority of transactions — but two additional flows round out the full operator experience.

App Launch and Organization Switching flow

App Launch & Organization Switching — selecting an organization on first launch to set the work context.

Ad-hoc Material Issue flow

Ad-hoc Material Issue — issuing materials not pre-listed on the work order, including split quantity and LPN capture.

08 — Impact

Results at the Assembly Line

By navigating initial stakeholder misalignment and the hardware pivot, the team delivered a product built for the factory floor — not adapted for it.

½
Transaction Time
Eliminating the desktop commute cut transaction completion time in half
0
Training Errors
Scan-to-Reveal logic meant new operators completed complex transactions without errors
RT
Real-time Data
Exceptions caught at the assembly station instead of hours later at a desktop terminal
Quote from Lead Manufacturing Engineer

"The proactive field injection is a game-changer. We no longer have to train operators on which materials require a Lot vs. a Serial number — the UI just tells them what to do next."

09 — Reflection

What I Learned

A project that tested not just design craft but alignment, communication, and the willingness to challenge assumptions — even three weeks in.

01
Design as Diplomacy
This project was a masterclass in navigating ambiguity. The most important tool isn't always Figma — sometimes it's a shared spreadsheet and a "Stop-the-Line" meeting that unblocks the entire project. Communication is a design skill.
02
Hardware Dictates Software
Designing for a rugged scanner with a physical keypad differs fundamentally from designing for a smartphone. Understanding the physical environment — gloves, low light, loud noise — before committing to UI patterns is critical and non-negotiable.
03
The Power of Constraints
The limited screen real estate of Zebra/Honeywell devices actually made the product better. It forced the team to strip away "nice-to-haves" and focus on "must-haves" — resulting in a cleaner, faster experience than the original desktop OWB.
04
Know Your User's World
The VP review that revealed the scanner hardware was humbling but invaluable. Assumptions about the user's physical environment — device type, lighting, protective gear — are as important to validate as assumptions about their mental model.
Next Case Study
Parallel Operations
in Work Definition
Oracle SCM Manufacturing
View Case Study