The Pharmacy Software Panel is a web-based operational system designed around the day-to-day and network-level needs of pharmacies.
The file explicitly includes a Central Team experience alongside role structures for small, mid-scale and big-scale pharmacy operations.
This is not a single dashboard project. The design represents a complete operational ecosystem with multiple pharmacy sizes, multiple roles, granular permissions, data-heavy workflows and a central layer for network-wide visibility.
The challenge was not simply to digitize pharmacy tasks. The system had to represent how a pharmacy business operates as a connected network: products move through procurement and inventory, customers generate sales, deliveries fulfil orders, vendors supply medicines, finance tracks transactions, and central teams need visibility across pharmacies.
How might we create one system that is simple enough for a pharmacist or cashier to use every day, while still giving managers and central teams the data, controls and permissions needed to operate the business at scale?
One product. Three operating models.
The design explicitly explores three operating models: Small Scale Pharmacy, Mid Scale Pharmacy and Big Scale Pharmacy. The number of roles and responsibilities changes with operational scale.
Information is shared, but responsibility is not.
The design uses a shared product structure with role-aware access. Four permission states are explicitly represented: Full Access, View Only, Limited Access and No Access.
This model is especially important for pharmacy operations because information is shared, but responsibility is not. Inventory, procurement, billing, delivery and finance should not automatically expose the same controls to every employee.
The primary navigation shown in the design is compact: Dashboard, Sales, Purchase, Inventories, Integration, Settings and More. Additional operational destinations such as Pharmacies, Customers and Distributors are also represented.
A network control centre, not a single-store view.
The Central Team experience is designed around network-level visibility rather than a single store. The PRD content embedded in the design defines eight major dashboard areas.
From business health to operational risk to detailed transactions.
The design connects customer information, order information, products and downstream fulfilment. Customer details, customer reports, sales reporting and order-level information are represented in the product.
Purchase is connected to vendor/distributor management. The navigation includes Purchase, Purchase Requirements and Purchase Orders.
The design contains a dedicated Purchase Requirements flow with an Add Purchase Requirement action and a vendor-selection journey. The vendor flow includes choosing a vendor, comparing vendors and continuing with the selected supplier.
A notable product decision is that vendor comparison is not treated as a black-box recommendation. The design explicitly communicates the reason for the recommendation.
The flow also handles unavailable customer-requested medicines, making procurement a decision-support experience rather than a simple purchase form.
At the Central Team level, Inventory Intelligence provides a network-wide view of stock health; at the pharmacy level, inventory is an everyday operational workspace.
The design separates vendor-selection workflows from the broader distributor-management experience. The panel includes a Distributors destination, distributor records and distributor reporting.
The design includes Delivery Management as a major module and a delivery decision flow involving assignment and delivery method.
Represented as a dedicated module rather than being hidden inside Sales. This separation supports pharmacy-counter workflows where speed, clarity and transaction confidence matter.
A separate module in the information architecture, reflecting the distinction between operational transactions and financial control.
A broad reporting layer beyond the dashboard.
The design includes a broad reporting layer rather than relying only on the dashboard. The Reports area contains multiple report families.
Reporting includes product-wise margin, highest and lowest margin products, product/item reports, product search and product-type filtering.
Beyond core operations, the platform includes modules for customer engagement, people operations and system configuration.
The design repeatedly uses tables, search, filters, date selectors, category selectors, column controls, pagination and export actions.
The design contains recurring status and state patterns across modules.
The goal is to make state visible before the user commits to an action.
Reusable patterns suited to enterprise software.
The product uses reusable interaction patterns suited to enterprise software.
Consistency as a product-level requirement.
Because the product spans many modules, consistency becomes a product-level requirement rather than a visual preference.
The project can be represented as an end-to-end 0→1 process.
The resulting design is a scalable pharmacy software foundation that connects store-level execution with central-team visibility.
The design is best understood as an operating system for pharmacy business operations rather than a collection of admin screens.
I designed a multi-scale pharmacy operations platform from the ground up, connecting store-level workflows with central-team visibility.
The project demonstrates how I approached enterprise UX as a system-design problem: understanding roles, modelling permissions, structuring information, connecting workflows and creating reusable patterns that could scale across different pharmacy operating models.
Let's
design & build
something great.
