No screenshots: the product and its data are confidential. Everything shown here is a conceptual schematic of the design work.
Product design for an intelligent stock distribution platform used by retail companies to plan the rollout of new collections across their physical stores.
The project addressed the migration and complete redesign of the first-collection distribution flow. The platform generated distribution proposals based on market analysis, trends and multiple variables processed by complex algorithms. However, a key barrier existed: users didn't trust the generated proposal enough. In practice, many clients reviewed and modified recommendations piece by piece, reducing the value of automation and turning a time-saving process into a manual supervision task. The challenge was not just improving the interface — it was making a complex algorithmic decision understandable, configurable and trustworthy enough to be accepted.
The distance between what the system proposed and what the user accepted without touching it. Closing that distance was the brief.
Conceptual schematic. It shows the direction of the change in behaviour, not measured figures.
We worked on two complementary fronts: giving the user a control lever over the algorithm and making the reasoning behind its decisions visible. On one hand, we introduced a betting coefficient that allowed clients to increase the weight of specific products within the proposal — turning them into priority products with greater presence and distribution across physical stores. On the other, we redesigned the proposal screens to show much more clearly how the algorithm was making its distribution decisions. The goal was to transform an apparently opaque recommendation into a proposal the user could interpret, understand and validate.
Same algorithm, different relationship with it.
The diagnosis came before any proposal. The question was not how to improve the algorithm, but why the people using it corrected it every single time.
Interviews with key users
Interviews with the people working in the flow, to understand why they did not trust the system's proposals.
Recorded session analysis
Reviewing real sessions to see how the proposals were actually being worked with.
Friction mapping
Mapping the friction across the existing flow, where the pattern of systematic editing surfaced.
The vision exercise set the ceiling. MoSCoW, the alignment with stakeholders and the roadmap are what turned that ideal into a delivery plan instead of a wish list.
Vision exercise
An ideal version of the product, developed with no technical limits.
MoSCoW
Every improvement classified as must, should, could or won't have.
Stakeholder alignment
Goals and real constraints agreed with the people who own them.
Roadmap
A strategic plan for rolling the improvements out progressively.
Must have
The release does not work without it.
Should have
Important, but the release survives without it.
Could have
Worth doing if the margin allows.
Won't have
Deliberately out of this release — and on the roadmap.
The whole flow was designed at once, with no technical limits. Cutting back to what could actually be built was a second, separate decision — and the screens were laid out so the steps left out land in a place that already exists.
The dashed steps were designed alongside the rest, not added afterwards. Each one has its place reserved in screens that already shipped.
With the scope agreed, the work moved to defining the flow in detail and putting it in front of people before it was built.
Information architecture
Restructuring the information architecture and the navigation model to cut the cognitive load of the flow.
Designing the new flow
An iterative process: every round of design was reviewed and fed back into the next.
Working with product
Close work with the product manager to define requirements and functionality.
Component validation
With the design team, validating the user experience and the visual components.
Interactive prototypes
Prototypes that simulated the final experience so it could be tested for real.
Data Science & Engineering
Close work with the technical teams so the design decisions were viable and the data behind each proposal was actually available.
Design did not stop at handover: it was validated before the build, supported during it, and checked again once the screens existed.
Pre-development validation
Testing and validation with several internal teams, plus sessions with real clients.
Support during development
Working alongside the technical team while the screens were being built.
Post-development validation
Checking the quality of the design and the functional implementation of what shipped.
Full case study available on request.