Back to Home Page
Logistics
SUPPLY CHAIN SOFTWARE / UX AUDIT
Bringing coherence to logistics workflows
A cross-product audit, design-system foundations, and implementation guidance for a WMS/OMS implementation and support platform.
Valeriia Kovalenko — UX/UI evaluation and system direction
Client — Confidential company
Focus — Audit · Recommendations · Team handoff
Eight functional areas — Cross-product evaluation
Shared system foundations — Components, states, and language
Team-ready guidance — Specific tasks and review criteria
A platform around logistics implementation
The product and my contribution
A confidential company was developing an AI-enabled platform for implementation and operational work around warehouse management (WMS) and order management (OMS) systems. The product connected assessments, requirements, planning, configuration, validation, adoption, support, administration, agents, and warehouse simulations.
I evaluated the interface across eight functional areas and translated fragmented feedback into a structured improvement framework. My work combined section-level findings, prioritized team tasks, shared interaction recommendations, and design-system foundations.
The central challenge was not simply visual inconsistency. Users needed a clearer model for understanding an artifact, selecting a record, editing a configuration, running an action, and reviewing its result.
Reviewing the implementation lifecycle
Connecting tools that needed to work as one product
01. Assess needs
02. Define requirements
03. Plan delivery
04. Configure systems
05. Validate behavior
06. Prepare people
07. Support operations
Area | Coverage |
|---|---|
Project management | Project Plan, Task Board, sprints, estimates, workflow states, dependencies, and feedback. |
Requirements and design | WMS/OMS assessments, requirements, stories, traceability, and integration maps. |
Configuration and build | Live records, draft workspace, staged changes, environment comparison, extensions, scripts, reports, and labels. |
Validation | Data sets, purge preview, test cases, analytics, issues, and mobile-stream states. |
Adoption | Personas, SOPs, training, communications, surveys, readiness, and process drift. |
Support | Tickets, releases, deployments, scheduled jobs, monitoring, and operational detail. |
Administration | Users, roles, permissions, AI settings, quality, environments, documents, and feedback. |
Agents and simulations | Agent management, libraries, credentials, user pools, labor planning, research, and warehouse viewer controls. |
Turning repeated issues into shared rules
Fix the cause once, then apply it across sections
Similar problems appeared in many areas: misleading hover states, inconsistent selected states, detail appearing out of view, raw technical labels, competing actions, and overloaded forms. I grouped these into shared system recommendations and kept the section backlogs focused on their specific workflow needs.
Recurring issue | Rule I recommended |
|---|---|
A surface looked clickable but did nothing. | If a row, chip, card, or metric looks interactive, give it a meaningful action or remove that styling. |
Selected records had no adjacent context. | Keep the selected item highlighted and show its detail beside the collection. |
Long forms hid critical actions. | Use grouped sections or steps and keep primary controls reachable. |
Technical output dominated user-facing screens. | Use readable labels and structured detail; keep raw values available in an advanced view where useful. |
Errors used unrelated presentations. | Use a shared model for placement, severity, message structure, and recovery. |
Different views repeated the same task. | Keep alternate views only when they support a distinct workflow. |
Requirements: make the artifact flow explicit
From assessment answers to traceable delivery work
01. Run Assessment
02. Generate Requirements
03. Draft Stories
04. Review Traceability
05. Create Integration Maps
The capabilities existed, but the sequence was not sufficiently visible. I recommended a lightweight workflow model explaining how inputs feed the next artifact and what action the user should take.
Finding | Specific recommendation |
|---|---|
The inner “Design” page name was vague. | Rename it “Requirements & Traceability”, or use clearer destinations for distinct workflows. |
Assessment navigation had competing layers. | Separate assessment context, lens filters, section navigation, question content, and actions. |
Long answers had unclear save status. | Show Saved / Unsaved changes, last-saved feedback, and validation. |
The story empty state had too many equal actions. | Use “Draft stories from requirements” as the primary next step when requirements exist. |
Coverage was only a score or colored bar. | Explain calculation and missing links; open actionable requirement detail. |
Mapping actions were scattered. | Guide source selection → generate/import → review/edit → export or publish. |
Example empty-state direction
Draft stories from requirements
Use existing requirements as the source for the next stage of solution definition.
Secondary actions: upload a document, create a story manually, or export.
Project work: clarify the underlying object model
Plan, Board, and Sprints should not feel like separate task systems
The planning area mixed work views, settings, and repeated navigation. Users needed to understand whether the different views represented the same work items.
Recommendation | Implementation direction |
|---|---|
Use one vocabulary. | Standardize “Sprints” unless “Cycle” has a distinct product meaning. |
Clarify shared work items. | Reuse item IDs, filters, statuses, and terminology across Plan, Board, and Sprints where supported. |
Remove duplicated navigation. | Choose sidebar destinations or a parent Project Work page with internal tabs. |
Add unplanned work. | Give items without sprint assignment a predictable bucket. |
Surface estimates. | Include points in create/edit, cards, planning rows, and sprint summaries. |
Separate configuration from execution. | Move Work States, Estimates, Saved Views, and relation settings into a settings-style area. |
Improve the Gantt/table connection. | Synchronize rows and scrolling and highlight matching timeline content. |
Example: replace backend-style filters
Instead of raw JSON: Severity: P1 · Status: Open
Instead of blocked_by: “is blocked by”
Configuration: make operational impact visible
Differentiate inspection, draft work, and staged changes
Configuration tools supported live exploration, editing, staging, comparison, and deployment-related actions. Their differences needed to be visible at the point of use, not buried in explanatory paragraphs.
Live read-only · Draft workspace · Staged changes · Deployable
Recommendation | Specific direction |
|---|---|
Clarify task groups. | Organize Explore, Audit, Change Management, Compare, and Registry around user intent. |
Avoid conflicting names. | Rename the configuration “Design” tab to “Workspace” or “Draft Config”. |
Guide record exploration. | Make component → record type → records a visible sequence. |
Improve configuration tables. | Sticky key columns, column chooser, stable headers, explicit detail actions, and clear editable-cell states. |
Replace native prompts. | Use an app-native New Change Set form with labels, validation, and Create/Cancel. |
Explain significant actions. | Show target environment, affected objects, prerequisites, and confirmation for relevant operations. |
Guide comparison. | Choose Environment A → choose Environment B → run comparison; keep advanced commands secondary. |
Scripts, reports, and label tools needed the same clarity: explicit actions, meaningful previews, accessible toolbars, and recoverable errors. A rendering failure should explain what to fix while keeping technical details available separately.
Validation: scope, feedback, and recovery
A useful workbench should make the next step visible
Finding | Recommendation |
|---|---|
Test detail started empty despite available records. | Select the first visible test case by default and show meaningful no-data/error states when applicable. |
Issue totals appeared in several places. | Use one clear summary instead of repeating the same counts. |
List and Table modes repeated the same information. | Prefer the strongest default view unless alternatives support a distinct task. |
Validation did not clearly identify failed fields. | Highlight the input, show an inline message, and focus or scroll to the first failure. |
Run and Preview labels were vague. | Clarify scope with “Run Full Regression Suite” or “Preview records to purge”. |
New records were difficult to find. | Insert predictably, scroll to the item, or provide a direct confirmation link. |
Mobile stream errors conflicted with connection status. | Separate stream state from broader connection state and provide reconnect guidance. |
Shared error structure
What happened → Which field or operation needs attention → What the user can do next
I also recommended stable opaque table headers, consistent required/optional conventions, clearer dependency ordering, and fewer duplicate legends and inactive chart states.
Adoption: keep training and evidence in context
Support the move from system delivery to operational readiness
Workflow | My recommendation |
|---|---|
SOP editing | Keep the global shell and Training context; make the back action easy to find. |
Editor state | Use the correct New SOP, Edit SOP, or Duplicate SOP title. |
Role navigation | Treat the role list as a secondary panel, not a replacement for global navigation. |
Training badges | Shorten Quick Reference to Quick Ref where needed and use shared badge rules. |
Communications planning | Choose a strong primary view; keep Calendar/Timeline/Cards alternatives only when useful. |
Survey preview | Make the full card open preview; reserve small controls for secondary actions. |
Process Drift / People | Show selected-person findings beside the people list and keep the source row highlighted. |
These recommendations kept the focus on follow-through: finding the relevant procedure, understanding the current editing state, reviewing adoption evidence, and taking the next action without losing context.
Support and administration: one record-review pattern
Keep selection, evidence, and actions together
01. Select a record
02. Keep the source highlighted
03. Show adjacent detail
04. Review or edit
05. Confirm the result
Area | Specific recommendation |
|---|---|
Release review | Move detail from below the table into a right-side pane with readable content width. |
Job Scheduler | Use one selected job across table and timeline; preserve it through compatible filters and view changes. |
Environment Monitor | Open detail beside the monitor collection rather than pushing health content down. |
Support Tickets | Use the same list/detail behavior for existing-record review. |
Users and Roles | Replace oversized or nested modals with a guided side editor or management page. |
Permission matrix | Add search, per-section counts, bulk selection, selected summary, and review before save. |
AI settings and environments | Show dirty state, Save, Reset, validation, and Last saved feedback. |
Documents and feedback | Keep rows compact; show full content, preview, history, and actions in detail. |
I identified useful internal precedents in the publish/subscribe explorer, help area, and persona detail. Reusing patterns that already worked gave the recommendations a practical foundation.
Agents and warehouse simulations
Guide specialist setup without overwhelming the first view
Area | Specific recommendation |
|---|---|
Agent table | Group operational columns, align numbers, explain run history, and separate Run, Chat, Edit, and overflow actions. |
Content Library | Separate Create entry, Entries, and footer controls; use persistent field labels. |
Credential copy | Start with the purpose and place reference syntax after users understand the task. |
New Agent | Move long instructions out of the textarea placeholder into expandable help. |
User Pools | Use a predictable drawer, modal, or create page rather than a huge inline form pushing content down. |
Simulation setup | Use Basics → Actors → Data → Skills → Review. |
Labor planning | Make editable fields, removal actions, and calculated outputs clear. |
Warehouse viewer | Improve control size, spacing, focus, help, and responsive behavior. |
Research creation | Explain the expected output and use a result-based label such as Generate study plan when appropriate. |
The recommendations also called for identifying whether warehouse data or visuals represented a demonstration, placeholder, or user-specific environment. That context matters when users evaluate a simulation workspace.
Design-system foundations
A shared specification for designers and developers
I translated recurring visual and interaction issues into a compact target style guide. It covered the components and states repeated throughout dense logistics workflows, rather than adding isolated styling rules for each page.
Foundation | Recommended specification |
|---|---|
Font and hierarchy | Inter as the UI family; page title 28/36 px, section title 20/28 px, panel title 16/24 px. |
Operational content | Body 14/20 px and dense body 13/18 px, with distinct labels, helper text, captions, and status roles. |
Color tokens | Separate primary/secondary/tertiary text, surfaces, borders, focus, selection, and semantic states. |
Spacing and shape | A shared spacing scale, restrained radii, and limited elevation for floating surfaces. |
Buttons | Small 32 px, medium 40 px, large 44 px; clear primary, secondary, tertiary, destructive, disabled, and icon-only variants. |
Tables | Consistent row heights, opaque headers, numeric alignment, selected state, long-text handling, and action placement. |
Forms | Persistent labels, concise placeholders, helper text, consistent optional marking, validation, and reachable actions. |
Writing | One name per object, consistent case, clear action verbs, and useful domain abbreviations. |
I included accessibility requirements for contrast checks, focus, keyboard interaction, accessible names, and practical hit targets. The guide gave the team a common reference for applying and reviewing components.
Implementation guidance and review criteria
From recommendation to a clear team task
Each section contained issue locations, correction directions, local priorities, and implementation notes. The consolidated manual grouped repeated problems so they could be addressed centrally before local workflow changes.
Task example | Review criteria |
|---|---|
Refactor operational detail. | Selected object opens adjacent context; source stays highlighted; filters and supported views handle selection consistently. |
Clarify configuration states. | Environment and live/draft/staged context remain visible; disabled controls explain prerequisites. |
Restructure role editing. | Permissions are searchable and reviewable; Save/Reset and unsaved state are explicit; nested dialogs are removed. |
Make assessments actionable. | Inputs and outputs are clear; save feedback is visible; requirements and story next steps are understandable. |
Unify forms and errors. | Labels persist; failed fields are identifiable; copy explains recovery; long-form controls stay reachable. |
01. Define shared rules
02. Apply repeated patterns
03. Resolve workflow-specific gaps
04. Review behavior across states
The handoff included explicit instructions suitable for design, engineering, and AI-assisted refactoring, with the intended behavior described rather than left to visual interpretation.
What I delivered
A reusable correction framework for a complex logistics product
Deliverable | Value to the product team |
|---|---|
Eight section-level audits | Located issues within actual screens, states, and workflows. |
Consolidated implementation manual | Separated recurring system weaknesses from local exceptions. |
Prioritized design and development tasks | Turned feedback into specific work packages. |
Target style guide | Defined foundations for consistent visual and interaction patterns. |
Implementation and QA guidance | Made expected behavior and review criteria explicit. |
I connected a broad set of interface issues to one product direction: clearer logistics workflows, predictable interactions, shared design-system foundations, and practical tasks for the teams building the next iteration.
Client and product identity confidential