Case study · 01
A clinic CRM, built from scratch
The web platform clinics and gyms run their business on, from client records and lab orders to prescriptions, billing and email campaigns, designed from zero one module at a time.
Context
The client is a health-tech company that provides metabolic testing to clinics, gyms and wellness centers. Those businesses don't buy health data for its own sake. They buy the ability to run a service around it. The web platform is where that service runs. Staff use it to manage client records, lab orders, prescriptions, pricing and billing, scheduling rules and email campaigns, and a client-facing dashboard mirrors what they see. There was no product to redesign, no design system to inherit and no reference inside the company. Everything was designed from a blank canvas while the product kept shipping.
The problem
No off-the-shelf CRM understood lab panels, biomarker reference ranges, retest cycles or prescription logic. Clinics needed to take a client from first walking in to registered, tested, scored, prescribed, scheduled, billed and followed up without leaving one system. Each business also had to configure that system around its own services, prices and rules, because a cryotherapy studio, a physician's office and a gym don't operate the same way. Underneath it all was one hard constraint: a large amount of health-critical and business-critical information had to stay usable by a non-technical clinic employee.
- A client's health picture was split across disconnected screens, with scores in one place and biomarkers in another, so staff had to piece it together by hand.
- Multi-step pipelines like lab orders, payments and approvals were opaque, and some failures, such as a lab-report upload that couldn't be read, happened silently.
- Clients slipped through the gaps: invitations never turned into registrations, questionnaires stayed half-finished and retests never got booked.
Approach
Map the business, not the screens
We started by following one client through the whole journey: invite, test, scores, prescription, payment and follow-up. Each module became responsible for one stage of that loop, so the information architecture came from how a clinic actually works, not from a feature list.
Explore in the open
Complete flows were laid out end to end on large boards, with alternatives side by side. For example, three different scheduling models were compared before one was chosen. Interaction logic was written next to the screens, so the design file also worked as a behavioural spec for engineering.
Design every state
Whole areas of the file are given over to non-happy paths: empty, loading, error, hover and banner variants for each flow. Empty states also act as onboarding. Every builder opens with three short Getting Started cards that explain its model before anything has been created.
Systemize, then restructure
Repeated patterns were collected into a component library, from inputs with documented validation behaviour to status chips, calendars and score rings. That library now serves more than a dozen white-label brands. Once the product had grown, we reorganized the information architecture. A persistent workspace now holds the business, and each client opens in a tab, like a browser tab, so staff can work on several clients at once.
Key decisions
Tables as the backbone, de-densified
Client lists, lab orders, biomarkers, prescriptions and lab panels are all tables, because they are records to manage, not to browse. Search, alphabet jump-rails, category filters, colour-coded status chips and row-level hover actions keep lists of 100+ rows scannable. Cards are kept for content people browse, such as services and walkthrough videos.
A complete status vocabulary
The lab-order pipeline covers ordering, clinic approval, payment authorization, sample collection, lab analysis and final approval or rejection. We gave it eleven named states, each with a coloured chip in the table and a matching contextual banner on the order. Logistics, payment and clinical review now read as one scannable list instead of a black box.
Rule builders that read like sentences
Clinics can automate which services a client is prescribed and which emails they receive. They do this by combining ALL and ANY conditions on questionnaire and test data, with no code involved. Every rule shows a plain-language summary, so it stays readable long after it was built. The same pattern runs through every builder: a short stepped wizard to create, then a table to manage.
Outcome
The platform now covers the full operating loop in one system. A clinic can onboard a client, review their test results, order and track lab work, prescribe services, price and bill them as one-off payments, instalments or subscriptions, and automate the follow-up emails that used to depend on someone remembering. The merged health overview puts scores, the metrics behind them and supporting biomarkers in a single view, and one design system carries the product across every partner brand. The figures above describe the scope of the design work. We don't publish usage data for this client.
Client names and screens are kept confidential; illustrations are abstract recreations.
What we learned
Dense screens were not the hardest part. The operations behind them were: lab logistics, payment states, subscription versions and approval workflows all had to become something a front-desk employee can run. A consistent pattern language made that possible. Once wizard-to-table builders, chip-based pipelines and sentence-like rules were settled, each new module became a matter of assembly instead of invention.