Context

BD Rowa builds dispensing robots used in thousands of pharmacies across Europe. The touchscreen UI had been built by engineers, without a designer ever in the room.

Problem

Pharmacists found the system slower than dispensing manually. Onboarding burned through support calls. The interface broke down across languages and experience levels. And when something went wrong, staff had no idea how to fix it.

My Contribution

I co-led the redesign, owning the design system and core interaction model. My co-lead owned research synthesis. We partnered on fieldwork across Germany, Austria, and France.

Outcome

The Redesign V1 shipped in 2026.

• Support calls dropped,
• The BD Rowa design system is now the standard for all future features, and
• Customer feedback on speed and clarity improved measurably.

The users are pharmacy owners and pharmacy managers. They operate under time pressure, with walk-in customers waiting at the counter, often managing multiple machines alongside a broader pharmacy inventory system (the Warenwirtschaftsystem, or WWS).

Speed and trust are non-negotiable. A single delay at the counter changes the customer experience of the whole pharmacy.

Speed

Dispensing a medication through the UI was taking longer than doing it manually. Pharmacists were complaining about this directly. For a tool whose entire promise is speed, this is existential.

Onboarding

BD Rowa ships around 1,000 new installations per year. Each one came with a long tail of support calls from staff learning the interface. Customer support was becoming the product's bottleneck.

Language fragility

The platform runs across Europe. We observed that much of the pharmacy staff operating the machines were not native speakers of the language of the country they work in. Text-heavy interfaces forced them to rely on translations that often misled them.

When something broke, staff were stranded

The machine gave no meaningful diagnostics. When something went wrong, staff had no way to understand what had happened or what to do about it. Every incident became a service call. This was expensive for BD Rowa, disruptive for the pharmacy, and left staff feeling helpless in front of a machine they were supposed to be operating.

Deutsche 🇩🇪

"Wenn ich am Rowa bin habe ich direkt eine ganz andere Verbindung zu meinem Lager, als wenn ich vor dem WWS stehe."

English 🇬🇧

"When I'm at the Rowa I have a completely different connection to my inventory than when I'm standing in front of the WWS."

The Rowa is a short-term tool, not a planning system

Pharmacists use it to answer "what do I need right now?", not "what should I buy next quarter?" That lives in the WWS. Scoping the UI to short-term decisions made everything simpler.

Non-native staff make text a liability

Language was not just an internationalisation problem. Much of the workforce was operating in a second or third language.
The more text we put on screen, the more reliant users became on translation quality we could not control.

Users physically enter the machine, and they are afraid of it

During maintenance, staff enter the Rowa and fear being locked in or leaving tools behind. The UI had to actively protect them, the machine, and the stock.

Trust is a gradient, not a switch

Pharmacies kept high-value or fragile meds outside the Rowa. They didn’t trust it with critical stock. Trust isn’t designed in one release. It’s earned through visible reliability, so we focused on making that reliability clear, feature by feature.

Insight

We replaced text labels with recognisable iconography, condensed multi-step flows into single screens where possible, and used large touch targets so pharmacists could operate the machine without pausing to look.

What we considered and rejected

A configurable dashboard where each pharmacy could set their own layout. It tested well with owners but poorly with managers, who were the people actually using it daily. We kept the interface opinionated.

What we did:

• Replaced text with icons for key actions
• Standardised status signals for clarity across languages
• Kept text only where precision mattered.

Outcome

This made the same interface work for a native German pharmacist in Munich, a Portuguese-speaking pharmacy assistant in Vienna, and a French-trained manager in Lille, without three different UX paths.

We designed the self-diagnosis flow around a single idea: meet the staff where the problem is, and walk them through the fix.

How it works:

• The system pinpoints the issue, shows exactly where it is
• The UI surfaces the problem with a visual of where it is, no cryptic error
• Walks staff through the solution step by step, with simple, actionable instructions.

What we considered and rejected

A text-based troubleshooting log. It tested badly, because the same language fragility that plagued the main UI applied to error messages. A translated error that almost makes sense is worse than no message at all. We committed to visuals-first diagnostics.

What we designed:

• Explicit lockout and confirmation flows for physical access.
• Proactive checks before the machine moves.
• Transparent handling of sensitive stock.

The harder truth

We knew from the research that no design would convince pharmacies overnight to put their expensive stock inside the Rowa. That trust has to be earned across months of reliable operation..

In practice this meant:

• Worked closely with engineering to understand constraints,
• Built a backward-compatible component library.
• Prioritised high-impact, low-effort changes.

This constraint shaped the design system I built. Every component had to work within the realities of a platform that could not be rebuilt, only re-dressed.

The core insight

The biggest design decisions were about less, not more. Removing text, removing steps, removing configurability. When the product had to work for a tired pharmacist, a non-native-speaker assistant, and a new hire all on the same shift, restraint was the design.

On trust as a gradient.

The hardest thing I learned on this project was that you cannot ship trust. Pharmacies kept their most expensive stock outside the machine not because the Rowa was unreliable, but because they had not yet seen it be reliable with stakes that high.

No visual polish or reassuring copy shortcuts that. What a designer can do is make each small act of reliability legible, so that trust has something to build on. V1 is the first deposit in a long account.

What I would do differently

We scoped the redesign tightly around what engineering could support. That was the right call for shipping V1, but I now think we should have documented the changes we would have made with an unconstrained platform.

That backlog would have given BD Rowa's product team a clearer roadmap for architectural investment beyond V1.

What this project taught me

Designing for hardware-bound software is a different discipline from designing for the web. The UI has to respect the physical state of the machine, the physical space around it, the physical safety of the person using it, and the emotional weight of the stock inside it.

ROn systems embedded in someone's daily workflow, helping users resolve their own issues is not a feature, it is the basic deal the product has to uphold to earn its place.