AI · SaaS
PharmaServ
AI-powered omnichannel platform unifying sales and medical operations for pharmaceutical teams.
- Role
- Product Designer
- Timeline
- 2025 · 3 months
- Industry
- AI, SaaS
- Platform
- Web + mobile
Two products, many roles, one day in the field
PharmaServ is an AI-assisted engagement platform for pharmaceutical and life-science teams. It’s really two products sharing one data spine: Copilot, which helps medical reps plan and run meetings with healthcare professionals (HCPs), including e-detailing (presenting approved product content digitally), and Field Service, which handles the commercial side: orders, payments, pricing rules, leads and territory.
Around those two products sit very different people. Reps live on their phones between hospital visits. Managers sit on the web, setting KPIs, tracking the field force and reading performance. Marketing and medical teams upload content and plan campaigns. They all touch the same schedules, the same HCP records and the same visits, but each of them needs to see those records differently.
Everything is urgent, and everything is regulated
The challenge was never a shortage of data. It was giving each role enough hierarchy to see what needs their attention now, without losing the detail they’ll need when someone asks why.
A rep needs the next call, the address and the right content: fast, often one-handed, often between appointments. A manager needs to know whether the week’s plan is actually happening, who is behind and where to step in. Underneath both sits compliance: visits have to be verifiable (PharmaServ uses GPS geo-fencing for this), content has to be approved, and every interaction has to leave a record.
Mapping the roles before the screens
Before designing screens I mapped who does what, on which device, and what each role needs to see first. It became a simple matrix that shaped almost every later decision.
- Medical / sales rep
- Main surface: Mobile
- Needs first: Today’s calls, where to go, what to present
- Needs on demand: HCP history, orders, payments
- Manager
- Main surface: Web
- Needs first: Is the plan happening? Who needs help?
- Needs on demand: Visit-level detail, GPS proof, KPIs
- Marketing / medical
- Main surface: Web
- Needs first: Campaigns, events, content status
- Needs on demand: Engagement per HCP and channel
The schedule as the shared source of truth
The scheduling view is where the manager’s and the rep’s worlds meet, so it carried the most design weight.
- Reps as rows, days as columnsA manager scans down to find a person and across to see their week, the way they already think about the team.
- Compact call chipsInstitution, time and a colour for call type: dense enough to show a full week without scrolling sideways.
- Overflow that collapses“2 more schedules” keeps one busy rep from stretching the grid. The layout stays stable even when the data isn’t.
- Details in a side panelDepartment, call type, focus, objective and address open beside the grid, so the whole week stays in view.
- Verification on the visit“Track med rep” sits on the visit itself, one click from the thing being checked, not a separate report.
- Part of the existing stackSAP, Excel, Slack and Notion: the schedule has to sync with the tools teams already rely on.
Separate the shells, share the components. Reps and managers get different navigation and a different default home, but the same visit card, HCP card and status language everywhere. A rep who becomes a manager doesn’t have to relearn what “Promotional” or “Physical” means.
Progressive disclosure for regulated detail. The list shows what’s needed to act; the panel shows what’s needed to justify. That split kept screens readable without hiding anything a manager or an auditor might need.
AI as an assistant, not a narrator. Insights, prioritised leads, scheduling suggestions and forecasts work best attached to real records the user can open, check and override, not as free-floating summaries.
A component set built for density
Enterprise screens fail when every element shouts. The visual system is deliberately quiet: a restrained blue for primary actions, neutral surfaces, small consistent status colours, and type sizes tuned for tables and panels rather than marketing pages.
Most of the work went into the components that repeat hundreds of times (the call chip, the person row, the detail panel, the filter bar), because those set the rhythm of every screen.
Designing the boring parts well
The parts of this project I’m proudest of aren’t the hero screens. They’re the decisions that made dense screens calm: where the overflow goes, what opens in a panel instead of a page, which detail a rep sees first.
Enterprise users don’t need to be delighted every time they open the app. They need it to be trustworthy at eight in the morning with a full day of visits ahead.
Got a user problem?
Open to interesting product problems, collaborations and AI-driven ideas.
or write to obianujuohuegbe@gmail.com