01
Role first, feature second
A receptionist managing waiting rooms and a doctor triaging risk solve different problems. Designing for the role, not the feature, is what turns a database with a UI into software the team trusts.
Karaz Care · A multi-role platform for diabetes care
Designed Karaz Care, a multi-role healthcare platform. Live in 13+ countries managing 100K+ patients.
Client
Karaz
Industry
Healthtech
Category
Enterprise SaaS · Multi-role Platform
Role
Lead Product Designer
Timeline
4 months to v1, ongoing iteration since
Platform
Web · Multi-clinic
What I owned ·I led design end to end. Research, information architecture, user flows, wireframes, the design system, and the final UI across five role-based dashboards. I also managed two junior designers on the team.
100K+
Diabetes patients managed
Across the platform since launch
13+
Countries deployed
Including the Middle East
5
User roles designed
Doctor, nurse, admin, pharmacy, receptionist
The thinking
Four principles I would defend at every fork.
Diabetes care touches five different jobs in a clinic. Each role makes different decisions and needs different data. Before designing a single screen, I anchored the platform to four principles. Every fork in the road came back to these.
02
Triage over display
When clinicians see 100+ patients a day, the win is not more dashboards. It is a system that points at the few that need attention right now.
03
Reasoning over flags
A risk badge without the why is just another thing to interpret. Every flag explains itself in plain language, with the data that triggered it.
04
Scan first, drill later
A patient overview that lists every past lab is no longer an overview. Recent data, then a clear path to the full archive.
Scope of work
One platform. Five roles. Six modules.
Across the entire surface of the product — from research synthesis to design system.
Role-based dashboards
Jump to tabs ↓Doctor
Triage risk, decide treatment, log interventions.
Nurse
Track vitals, log interventions, hand off cleanly.
Admin
Run the clinic. Staff, patients, outcomes.
Pharmacy
Manage prescriptions, refills, adherence.
Receptionist
Waiting list, appointments, referrals.
Cross-role modules
Patient management
Risk triage, body assessment, glucose curves, AGP charts, full medical history.
CRMS module
CGM device replacement workflow. Sensor lifecycle, replacement queue, courier handoff.
Authentication & multi-clinic
Role-based access. Doctors at one clinic don't see another clinic's data.
In-app chat
Clinician-patient and care-team messaging. Threaded by patient, archived for compliance.
Notifications & scheduling
Role-aware alerts and calendar. A doctor sees risk escalations, a receptionist sees check-in delays.
Design system
Colors, typography, components, and icons. One library, used by every screen across every role.
The problem
Diabetes care was reactive and fragmented. Clinicians, nurses, receptionists, pharmacy staff, and admins all worked in separate tools. Patient data was stuck in handwritten logs and scattered reports. Karaz needed one connected platform where every role could see what mattered to them and act on it. A study of 384 patients over 3 months showed the real bottleneck. Not missing data. Too much raw data with no way to triage.
The five roles
A different decision for every role.
Tab through to see what each role sees and why.
Admin
Run the clinic. Staff, patients, outcomes.
The Admin dashboard answers questions doctors do not need to think about. How many patients are active. Which devices are connected. Which clinical outcomes are improving. One long view, scrollable end to end, kept separate from clinical work so admins can see the clinic as a whole. Scroll through the full admin view via the supporting shots below.
Inside the patient overview
One patient, one record, top to bottom.
The patient record is one long view, scrollable end to end. Daily activity and glucose readings sit near the top. Insulin distribution and risk scoring come next. Then connected devices, ending with the ambulatory glucose profile. Each section answers a different clinical question without making the doctor leave the patient.
Key decisions
Five forks in the road. Five calls I would defend.
01 / 05
Five role-based dashboards instead of one generic view
Five different dashboards, one per role. Doctor sees risk. Receptionist sees waiting rooms. Admin sees clinic-wide stats. Pharmacy sees medication queues.
A receptionist managing waiting rooms and a clinician triaging risk see fundamentally different data. Forcing them into one dashboard hides what each role actually needs. I split the platform into five dashboards, each tuned to the decisions that role makes every day.
Built role-specific dashboards instead of one generic view. Each role solves different problems.
02 / 05
Eight quick actions hidden behind one floating button
Call, message, refer, add intervention, medicine, diagnosis, test, attachment. All tucked behind one floating button.
The Patient Overview needed eight quick actions. Putting eight buttons on the page would crowd the data, which is what clinicians actually came for. I tucked them into a single floating button that fans out on click. Actions are used a fraction as often as viewing the data, so they should occupy a fraction of the visual weight.
Hid 8 actions behind one button. Viewing data matters more than triggering actions.
03 / 05
Three tabs over one long scrolling page
Three tabs split the patient record into Overview, Body Assessment, and Medical History.
A clinician seeing 100+ patients a day does not read a record top to bottom. They jump to one section, scan, and move on. One long scrolling page forces back-and-forth that wastes seconds on every visit. Three tabs match how the data is actually used.
Three tabs over one long scroll. Clinicians don't read top to bottom. They jump and scan.
04 / 05
Wrote the reasoning into every risk flag
Risk banner spells out the diagnosis, the CGM thresholds that triggered it, and what the data is asking for.
The High Risk banner could have just said "High Risk." Without context, it is just another dashboard the doctor has to interpret alone. Instead it reads in plain language: "This patient is Hypoglycemia because patient is Type 1 diabetic and has CGM metrics TIR ≥ 70 and TBR ≥ 3%." The why turns the screen from a data display into a decision tool.
Wrote the why into every risk flag. A flag without a reason is just noise.
05 / 05
Pushed back on dumping every lab result on the overview
Recent lab results on the overview, with a View All link to the full archive.
The client and PM wanted every past lab result visible on the patient overview. I argued no. An overview that lists everything stops being an overview. We shipped recent results only, with a View All link to the full archive. The page kept its scanability, and clinicians could drill in when they actually needed history.
Pushed back on showing every past lab. An overview that lists everything stops being an overview.
The design system
One library. Every screen. Every role.
Five dashboards across one product means five places where inconsistency would have shown up immediately. A unified design system — colors, typography, components, icons — kept the platform coherent through every release. Engineers shipped faster because the spec was explicit, and new screens stayed visually accountable to the rest of the product.
How I worked with the client
Engagement model
Retainer. 4 months to v1, ongoing iteration after launch.
Communication
Daily standups on Slack. Direct line to the engineering lead and the client team.
Tools
Figma, ClickUp, Slack
Deliverables
Research synthesis, Information architecture, User flows, Wireframes, Design system, 5 role-based dashboards, CRMS module, Ongoing iteration
What this means for similar projects
Enterprise health tools fail when they treat all users as one. A receptionist, a pharmacist, and a doctor solve different problems. Designing for the role first, not the feature first, is what turns a database with a UI into software the team actually trusts.
- Top Rated on Upwork
- 100% Job Success
- $80K+ earned
- 8+ years
Open to senior remote roles.
Full-time employment or long-term contract. Senior Product Designer or Senior UX Designer. Reach me on LinkedIn or by email.
Or email hey@shahriarsultan.com