A medication shortage management module designed for BD’s HealthSight Analytics platform, under a contract engagement covering the module end to end. It gives hospital pharmacy managers a single view of how long a short drug will last, where the remaining doses sit across the facility, what has already been done about it, and what can be substituted. Delivered as a fully interactive Axure RP prototype with conditional logic and persistent state, so scenarios could be tested against it like working software.
A medication shortage is not an inventory problem. It is a time problem with an inventory shape.
The drug is short nationally. Your facility has some doses, but they are scattered across dispensing cabinets, carts and the central pharmacy, and the system counts them as one number. You need to know how many days you actually have, where the doses physically are, what you can substitute, who has already been called, and what was agreed — and you need it before the next shift starts.
What existed instead was a stock number and a reorder date. Everything else — the location hunt, the phone calls, the substitution decision, the record of what happened — lived in spreadsheets, email and somebody’s memory.
Two minutes through the working prototype. Every control responds, every state changes — this is the prototype behaving, not a video of mockups.
Or open the prototype yourself and click through it. Password demofinal. It is a decade old and it still runs.
Four, and they are all about compressing a decision rather than displaying data.
The number a person can act on.
One number hides the useful answer.
The part that was not in the brief.
The answer next to the problem.
The module was not a standalone alert screen. It is the exception path through an existing optimisation workflow, which is what made it adoptable.
This was built in Axure RP, and the prototype behaves like the product — conditional logic, real data sets, state that persists as you move through it.
That is the point, not a footnote. A prototype that genuinely functions can be tested against scenarios: give someone a situation, watch what they do, see where they stall. You cannot do that with a clickable picture. Much of our testing on work like this ran against prototypes at this fidelity, which is how design defects got found before engineering wrote anything.
And it is still a live skill. Figma is where we work now, but regulated and enterprise environments still run on Axure, and plenty of teams have a decade of specifications sitting in it. Being able to read, extend and test in a legacy tool is worth more than pretending the industry moved on all at once.
An older project, and the method behind it is the one we still use.
Ask what the person is trying to decide and in what order they ask the questions, then build the screen in that order. Most enterprise dashboards show what the database has rather than what the decision needs.
The case history was not requested. It existed in phone calls and email because no tool held it. The highest-value feature in a workflow product is usually the one people are already doing by hand.
If it cannot respond, you cannot run a scenario against it, and you are testing opinions instead of behaviour. The tool matters less than whether the thing behaves.