Order Management 360

This project was part of the evolution of 360, HelloPrint's internal platform where agents manage customer orders — designed to replace the 13+ year legacy system (Presta).

When I joined, 360 already had an initial technical base, but it hadn't been adopted by the teams. In practice, agents continued using the old system to manage daily tasks.

The Problem

The platform did not reflect the real complexity of the operation.

• Lack of execution: 360 was primarily an information viewer — it let you see, but not act.
• Legacy dependency: Key tasks such as refunds, reprints, or complaints required going back to Presta.
• Disorganized information: The old system contained multiple tabs with redundant, often contradictory data.
• Fragmented processes: Critical flows like returns were managed outside the system entirely — in Excel and through manual emails.

As a result, two systems coexisted, generating inefficiency, errors, and a lack of traceability.

The Objective

Reduce dependency on the legacy system and move toward the progressive adoption of 360 as the primary order management tool — a complete resolution environment, not just a viewer.

My Role

Product Designer with Product Ownership responsibilities. I led the operational migration strategy and information architecture, defining functionalities in close collaboration with product, engineering, and business stakeholders.

To understand why 360 had not been adopted, I didn't limit myself to analysing the interface — I immersed myself in workflows and business rules accumulated over 13+ years to identify the exceptions, dependencies, and critical failure points that weren't visible at surface level.

I combined shadowing sessions, interviews, and process analysis to surface the main friction points:

• Lack of execution capacity: 360 didn't allow completing key tasks. Agents had no real incentive to switch tools when the new one couldn't replace the old one's capabilities.
• Information overload and complex navigation: The legacy system had 7 tabs with years of accumulated data. Agents constantly lost order context navigating between them.
• Opacity in errors: The monolithic system made it difficult to isolate failures. Engineering spent significant time locating problems within an unmodular codebase.
• Operational fragmentation: Critical processes like returns depended on Excel and manual emails — generating communication errors, delays, and complete loss of traceability.

From viewer to action console

Instead of redesigning screens, I redefined the product's role within the operation. The goal was not aesthetics, but enabling execution.

1. Centralisation of Actions

I integrated flows that previously forced a return to the legacy system: Refunds, Reprints, Complaints, Copy Order, Order Creation, and Upgrades/Downgrades. 360 went from passive viewer to active execution environment.

2. Information Synthesis

I reorganised information into 4 main areas: Info, Artwork, Delivery, and Complaints. Visual noise was eliminated and relevance was prioritised so agents could recover full order context instantly.

3. Improved Error Detection

I worked with engineering on a structure based on independent APIs. This allowed for easier failure isolation and a significantly more stable system.

4. Digitalisation of Logistics Processes

I designed the returns module, eliminating the dependency on Excel. This included integration with Paazle for automated labels and follow-up emails — centralising 100% of logistics data for the customer service team.

5. Decision Support

I integrated signals such as NPS, CSAT, and customer segmentation. The system could suggest the best resolution for each case, helping agents make more consistent decisions at scale.

6. Flows for Complex Orders (Bespoke)

I designed the quotes flow together with the high-value team. Complex quotes could now be managed and sent directly from 360, professionalising the process and removing an entire dependency on manual communication.

• Progressive adoption vs. complete solution: Total migration of the legacy system was not viable in the short term. → Instead of replacing everything at once, I prioritised integrating the most critical flows to generate immediate value and encourage progressive adoption.
• Business complexity vs. interface simplicity: The system had 13 years of rules, exceptions, and edge cases. → The challenge was not to simplify by removing functionality, but to reorganise it without losing operational capacity.
• Change of habits vs. long-term efficiency: Agents were deeply accustomed to the legacy system. → I avoided radical pattern changes and maintained certain familiar structures to facilitate the transition, even when they weren't the most technically optimal solution.
• Technical limitations vs. ideal experience: The legacy backend constrained some design decisions. → I worked with engineering to find viable solutions within the current system, prioritising incremental improvements.

The project's focus was not just on improving the experience — it was on changing user behaviour and reducing dependency on the legacy system.

• Progressive and directed adoption: 360 ceased to be a passive viewer to become the main management tool. High-volume flows (Complaints, Refunds, Returns) were executed primarily on the new platform.
• Efficiency through consolidation: Reduced the need to jump between multiple tools to process a single order — minimising context-switching and enabling faster, more direct workflows.
• Reduced cognitive load: By synthesising information and simplifying navigation, we reduced the learning curve for new agents. The system now guides the user instead of forcing memorisation.
• Automation of critical tasks: Agents can now manage processes like refunds independently in most cases, while approvals are still required for high-risk scenarios.
• System scalability: The modular structure laid the technical and product foundations for total migration of the remaining legacy system functionalities.