Back

Firstday Healthcare: NICU-level care for preterm babies · 01

Overview

Industry: Healthcare · digital health

The scope: Rework the platform’s user flows, information hierarchy, and role permissions, and establish the visual language and interaction patterns to support them.

Role: Product designer (enterprise SaaS, role-based workflows and permissions across provider, admin and hospital account levels)

Team: Agile engineering team · sole designer · worked directly with the founder and product lead, and the CTO

Type: Client work · shipped

The context

  • Firstday Healthcare delivers NICU-level care for preterm babies: continuous vital-sign monitoring, plus 24/7 access to neonatal providers.
  • The software behind it is a multi-tenant SaaS platform serving three audiences in one system: the neonatal providers delivering care, admins managing care delivery, and hospital leadership (Customer Account Owners) purchasing and overseeing the service.

I. What’s being designed

The work covers both care delivery and the operations behind it: the core workflows neonatal providers use to deliver care, alongside the tools account owners and admins use to manage providers, patients, and hospital locations authorized for the Firstday Healthcare plan.

II. Who reads this, and under what conditions

Accessibility here is not a compliance pass applied after the visuals. It is a constraint that determines what the visuals can be.

Start with who is reading, and under what conditions: design for the ward at 3 a.m. on a ten-year-old monitor, and the boardroom takes care of itself.

  • The users are hospital staff. Many are on night shifts, when fatigue measurably degrades contrast sensitivity and colour discrimination. They read the page fast, between other tasks. This is a glance, not a study.
  • They read it on institutional hardware: standard-issue 1080px panels, uncalibrated, narrow gamut, mounted under ceiling lighting nobody chose, viewed off-axis by someone standing rather than sitting. A colour that separates cleanly on a designer’s calibrated display can collapse on a ward monitor at an angle, under glare, at 3 a.m.
  • Roughly one in twelve men has some form of colour vision deficiency. Across a clinical team, it’s likely at least one person perceives colours differently than they were designed.
  • And the page does not stay on the screen. It gets screenshotted, pasted into emails, and printed in grayscale, often photocopied afterwards.

So the page has to survive its worst rendering conditions, not its best. That is not a stretch goal, it’s the normal case.

The accessibility baseline

That is the floor. Everything below is built on top of it.

The following is only a fraction of the decisions documented throughout the project, highlighting how those principles shaped the design.

  1. Contrast ratios hold at all times. Text meets 7:1, placeholder text 4.5:1, and interface elements 3:1.
  2. Nothing is encoded by colour alone. Statuses carry a word and a colour, often with an icon. Interactive states use additional changes in form, treatment, or position. Colour is the fastest channel, never the only one.
  3. Click targets meet 44px, via invisible hit areas. That is WCAG’s AAA level, well above the 24px AA minimum. It was chosen because users who are on the go or tired aren’t as precise, and space allowed it. It also works for touch, so the same components can be reused on touch interfaces. The visual density of the interface is preserved, but the interaction layer underneath is generous.
  4. Heading hierarchy is built into the design system. Headings introduce sections through structural markup, not just visual styling: levels <h1> to <h4> run in descending sequence without skips, with one <h1> per page, improving both scannability and accessibility. It replaced a legacy treatment of all-caps labels, missing headings, and sections held apart by inconsistent styling.

III. Aligning hierarchy with responsibility

The existing product had no clear account-management hierarchy. There were no Customer Account Owner and Delegate roles, so responsibilities that belonged at the customer-account level were distributed across operational roles. The missing layer was introduced:

  • The Customer Account Owner became responsible for the customer account. The role sits with customer leadership. They make decisions about the organization’s budget and which Firstday Healthcare plan it needs. But they should not have to manage every operational task themselves.
  • Delegates were introduced to distribute that responsibility. The Customer Account Owner can authorize Delegates to manage the customer account on their behalf, without transferring ownership of the account itself.

That same responsibility model informed individual permissions. For example, adding and authorizing hospital locations participating in the program was moved from Admins to the Customer Account Owner and their Delegates. Admins understand the operations of their own hospital, but they do not necessarily know which locations fall within the customer’s billing relationship. The Account Owner does.

Enter password

This case study is password protected. You’ll find the password on my resume.