VNR Holding — internal operations system

There was no spec, so the spec came first

VNR arrived with operational pain, not product requirements: data here, stock there, the public site and staff accounts each handled in its own tool. The first deliverable wasn't a screen. It was the requirements document. I sat with how the business actually runs day to day and translated fuzzy needs into scoped modules: data management, inventory, an admin for the landing page, HR and accounts. Each with a reason to exist and a place in the build order. Prioritisation followed one question: what does the team touch every single day? That shipped first.

Four domains that had to feel like one product

Data, inventory, a landing-page admin and HR/accounts are four different mental models, and the trap is shipping four small apps stapled together. The structural work was a single navigation that holds them all, with shared patterns for lists, detail views and everyday actions, so a habit learned in one module transfers to the next. For a pharmaceutical operation the payoff is practical: stock and data stop drifting apart once they live behind the same door, and updating the public site becomes one more routine task inside the same system, not a separate ritual with its own login.

Designed for the person who never got training

The users here aren't product people, they're the staff who keep a pharmaceutical business moving between phone calls. So the UI's quality bar was set by the least technical person in the room: plain labels over jargon, flows that follow how the paperwork already moves, nothing that assumes a manual was read. The measure of success for an internal tool is quiet: no training overhead, no shadow spreadsheets creeping back. If someone can finish Monday morning's work in it without asking a colleague how, the design did its job.