Context

External product designer on an ongoing engagement with Leroy Merlin Portugal, brought in November 2025 to update the visual design of a self-service invoice kiosk ahead of its planned web expansion.

Problem

The product existed to reduce the 3,973 monthly contacts to customer support related to invoice requests. A technology pilot had run successfully in one store. But design had been scoped for visual updates only, and the product was being treated as ready to scale. The actual state: a 12.8% error rate on invoice requests with no error UI, no loading feedback, and no behavioral differences planned between the kiosk and the web version.

Role

Sole external designer. My first deliverable was a risk diagnosis presented to business, product, and engineering stakeholders, not a prototype or a visual update. After the presentation, I was responsible for redesigning the request flow, specifying error states, and defining the behavioral differences between the kiosk and the web version.

Key Decisions

Diagnosis before design. I built a risk analysis before presenting any visual work, instead of delivering the visual update as scoped. The risk was that the client would read this as scope expansion or delay. The reason: the product had structural gaps that a visual update would not address, and launching without resolving them would invert the product's objective. A product that generates support contacts rather than reducing them is not in production. It is a liability.

Internal precedent over external benchmarks. To define what a successful web version could look like, I used the equivalent product already live in the Spanish market, rather than external competitive references. The tradeoff: an internal reference sets a specific bar instead of allowing a clean-sheet approach. The reason: internal precedent carries institutional weight that external benchmarks do not. It shifts the conversation from "here is what others do" to "here is what we already know works."

Context-specific behavior, not platform adaptation. The kiosk and the web version share a flow but not behavior. The clearest example: the kiosk includes an inactivity timer because a shared physical device in a public space must clear sessions automatically. The web version does not, because a user who leaves a browser tab open and returns later should not be forced to re-authenticate. I specified these as separate behavioral models rather than adapting a single model for two surfaces, because the contexts of use are structurally different, not just technically different.

Error states as a launch condition, not a backlog item. Production data showed that 12.8% of invoice requests returned an error from an external service, with no UI state defined for that failure. An authenticated user who sees no invoices and receives no instruction does not complete self-service. They contact support, which is exactly what the product exists to prevent. I specified error states with a recovery path for each failure scenario and framed this as a pre-launch requirement, not a post-launch improvement.

Result

The diagnosis shifted the product's status from pending visual update to pre-launch risk review. Behavioral specifications for two surfaces were documented before development began, giving engineering clarity on decisions that tickets do not cover. The rollout was reframed from a single-channel deployment to a multi-access-point strategy, incorporating the Spanish product's distribution model as the reference. The design scope expanded from visual alignment to structural specification, and the engagement has continued into the web development phase.

What Remains Open

The web version is in development. Regulatory approval is pending as a prerequisite for the launch. The rollout sequence, which access points go live first and in what order, is still being defined. What the work established is the behavioral and error-state infrastructure that the launch will depend on. The adoption data will exist after the launch. The engagement continues.