Firstday Healthcare: NICU-level care for preterm babies at home
Overview
Task: Rework the platform's user flows, information hierarchy, and role-based permissions, and redefine the visual language and interaction patterns that support them.
Role: Product Designer
Tools: ⚙️ Figma, Pen & paper
The product
— Firstday Healthcare delivers NICU-level care for preterm babies at home: 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, the parents receiving it, and the business account owners who buy and administer it.
I. What's being designed
Firstday Healthcare web app serves eight roles. Five of them see this dashboard, with overlapping but not identical data. What differs is which sections they can see and which metrics appear inside them.
The layout being designed is a universal page structure that has to hold for every role. If it survives at full complexity, the reduced versions are guaranteed.
That requirement has two audiences, and both audiences want the same thing: a page whose structure does not change with who is looking at it.
‣ 1. Users share pages with each other. Colleagues in different roles sit in the same meeting, look at the same screen, and talk about it. The moment a shared section moves or is laid out differently per role, screenshots, training material, and support calls all fragment.
‣ 2. Developers build one page, not five. The layout is a single template. Role logic should be able to remove a block a role is not permitted to see, and do nothing else. If role logic has to rearrange, resize, or re-flow, the team is maintaining five dashboards.
The Customer Account Owner is the role used throughout this case study, for two reasons.
The first is practical: it is the role with access to everything. Designing the fullest version first means every other role is a subtraction from it rather than a separate design.
The second is commercial. The account owner holds the subscription decision, and this page is where that decision gets informed: whether the caseload is staffed, whether babies are coming back, whether the programs work. It is a working tool and the product's case for itself.
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, so it is stated before them.
Design for the ward at 3 a.m. on a ten-year-old monitor, and the boardroom takes care of itself.
Start with who is reading, and under what conditions.
→ 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, at least one person who needs this page cannot see it the way it was designed.
→ And the page does not stay on the screen. Dashboards get screenshotted, pasted into emails, and printed (often 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.
III. The premise: one page because memory is the bottleneck
The legacy product split the account owner's picture across two pages: live metrics on the dashboard and historical metrics behind a User Analysis page. Each page made sense on its own, but comparison required moving between them.
And comparison is exactly what the account owner needs to do.
This is more than an inconvenience — it is a cognitive constraint. The redesign therefore begins with a single decision: consolidate the account owner's dashboard items onto one page.
Working memory can hold only a small amount of information at once, and what it holds is fragile.
When users interrupt their reasoning to navigate the interface, they risk losing the mental context they have already assembled. Even brief delays or unnecessary interactions increase cognitive load and make comparison harder.
Moving to the analysis page creates exactly that interruption. By the time it loads, the dashboard numbers are no longer visible and must instead be recalled from memory. The comparison shifts from recognition to recall. Nielsen's sixth usability heuristic argues against exactly this pattern: interfaces should minimize memory load by keeping relevant information visible rather than expecting users to remember it across screens.
The accessibility baseline
That is the floor. Everything below is built on top of it.
‣ 1. Nothing is encoded by colour alone. Every status carries an icon, a word, and a colour. Colour is the fastest channel, never the only one. The same rule applies to navigation: the active item carries an underline as well as a colour change, which is one more cue than most products give it.
‣ 2. Touch targets meet 44px, via invisible hit areas. The visual density the design system asks for is preserved; the interaction layer underneath is generous. A tired hand does not need to be precise.
‣ 3. Headings are a real hierarchy. The legacy product used all-caps labels with no structural markup. Research has shown that all-caps text slows scanning by removing the distinctive word-shape cues that make skimming possible. A proper heading hierarchy. Sentence case.
‣ 4. Contrast ratios hold at all times. Text meets 4.5:1, interface elements 3:1, including the magenta navigation bar, where white labels sit on a saturated ground.
‣ 5. Rounding is stated on the page, never applied silently. The legacy product displayed 0.33 patients. People are counted in whole numbers, and the page says so in writing, as a rule, beside the table it governs.
One honest qualification
The consolidated page does not fit in a single viewport. Comparing the census against the chart still requires scrolling, and scrolling still moves numbers out of sight. Consolidation does not eliminate the memory cost. It reduces it substantially.
A scroll isn’t a navigation. The page does not change; only the window onto it moves. The census is still there, in the same place, one flick away.
Scrolling is also cheap. No load, no state to re-establish, no decision about how to get back.
So the claim is the narrower one: consolidation converts a navigation event into a scroll. It does not make every figure co-visible on every display, and the design should not pretend otherwise.
The legacy table at 1064px, above; the redesign at 720px, below. The measurements mark the same movement in each: the jump from a row's label to its first value.
IV. Design constraints
Constraint 1: the data runs on three clocks
The legacy product never had to say what time it ran on. Each page had separate time model, so the page itself was the label: the dashboard meant now, the analysis page meant the selected period.
Consolidation removes that free labelling.
The moment everything moves onto one page, the question becomes unavoidable: What time does this number belong to?
The answer is different depending on where you look.
Plan and billing → timeless. No filter touches it.
Patient census → live, as of the last sync.
Key performance data → the selected reporting period.
Three time models now share one surface. And none of them is self-evident.
Consolidation only pays off if temporal scope is rebuilt explicitly. The layout has to do that rebuilding: through where the controls sit, what the captions say, and how the sections are placed and grouped.
Constraint 2: grouped data and tables cannot be wide
Reading is not a smooth sweep.
The eye jumps, in movements called saccades, and pauses between jumps in fixations. Comprehension happens in the fixations. Within a line, the jumps are short — 7-8 characters.
The expensive movement is the return sweep: the long jump back to the start of the next line. Its accuracy falls with distance.
On long lines the eye undershoots. It lands mid-line, or on the wrong line, and pays a corrective saccade before reading resumes.
This is why readability research converges on a line of about 50–75 characters, with roughly 66 as the target (Baymard; Bringhurst). The pixel width that produces depends on the font and size, so the constraint is stated in characters, not pixels. The accessibility ceiling (WCAG) is 80.
The row is the unit
Tables are the acute case:
Each row must be read as one unit. The indicators table is not three independent columns; each row is a single unit of information. A label and two numbers, read together: fixate the label, jump to Active, jump to Inactive.
Stretch the same three columns to 1064px, as the legacy table did, and the jump becomes about 500px across empty space, toward five identical 48px rows separated only by hairlines. The longer saccade sets off a chain:
longer saccade → more landing error
more landing error → the eye arrives slightly high or low
from there, one of two things → a corrective saccade back to the intended value, or an accidental fixation on the adjacent row
the result → slower comparison, and occasional misreading
At 720px that jump is about 270px, and the row's own text anchors it along the way. None of this happens.
The legacy table at 1064px, above; the redesign at 720px, below. The measurements mark the same movement in each: the jump from a row's label to its first value.
The column is the unit
The census grid is bound by the same constraint. It is also the part of the page most easily mistaken for decoration.
The legacy dashboard presented six census metrics in two rows stretched across the full page width. The cards were paired across each row, but scanning them as a set was difficult. Collecting the numbers required long horizontal eye movements, and there was no dependable path through them.
The hypothesis was that the problem was not the cards but the structure imposed on them. These six metrics are not independent facts. The account owner's task has two phases: first, understand each category on its own; then compare the patient counts against the number of managing providers to judge whether the caseload is staffed.
Therefore, the layout has to support two reads: a vertical read within each category, and a horizontal comparison between them. One principle governs whether it can.
Users read the layout:
In a grid, reading order is designed, not inherited. Decide how the content should be read first, then make proximity, orientation and spacing reinforce it.
The legacy dashboard contradicted that principle. Although the content was intended to be read across each row, the whitespace organized it into vertical stacks. The gap between the columns measured 244 to 328px while the gaps between rows measured about 36px, a ratio of roughly 8:1.. The layout was already grouping the cards vertically. The redesign accepted that grouping and reorganized the information architecture around it.
The redesign follows the reading. The cards become two vertical categories, patients and programs & providers, so each category can be gathered as a unit before the eye crosses to weigh patients against providers.
That comparison is then made deliberately cheap. The census pulls in from 1168px to 720px, the column gap drops from 244–328px to 120px, and the patient-to-provider comparison jump shortens by about 58% (more than half). Narrow enough that comparing them is a glance.
The census stops reading as six cards and starts reading as one thing.
The legacy census at 1168px, above; the redesign at 720px, below. The outlines mark what each layout groups: pairs read across the row, then categories read down the column
Constraint 3: but the chart must be wide
Constraint two established that the table cannot get wider. The chart will not accept the same limit.
A chart is not read line by line. It is scanned spatially, so width is not whitespace — it is resolution.
Compress it and bar width becomes the limiting factor. At eight series per date group, the densest grain is already down to about seven pixels a bar at 1168px. That is the legibility floor. The chart needs the full width.
The table two inches above it cannot have it.
So the page holds a contradiction. The table must stay narrow to stay readable. The chart must stay wide to stay readable.
The question stops being how wide should the page be. It is how two incompatible widths can belong to the same layout without looking like a mistake.
That is the layout's problem, below.
V. The layout
Two section widths are already fixed, constraints two and three settled those: the census and the indicators table can’t be wide, the chart must be wide.
What remains is everything else: where the controls sit, what the captions say, what gets a border, and where the gated section goes.
Every number on the page is governed by a filter, or by none. And the layout has to show which, without saying it twice.
Four mechanisms carry that:
Placement → a control sits at the head of, or inside, the region it governs.
Labels → a control gets a visible label only when its value does not already name its dimension.
Captions → scope is stated once, then inherited downward.
Containment → where proximity cannot show what belongs together, a border does.
So the location filter heads the filtered region, while the reporting-period picker sits inside the performance card above the table and chart it governs.
Altamonte Springs NICU Level II names a place, so it needs no visible label. Jul 17 – Jul 23, 2025 names only a date range, and this page carries three, so it keeps one. This works because there is exactly one location filter; add a second dimension and the labels return.
Scope is stated only where it changes.
The census declares its own clock because it differs from everything below it. The table states its data rules. The chart says nothing at all — it sits inside the picker's border and inherits. If every section restated its scope, none would be claiming anything.
Constraint 4: one section is gated, the rest are shared
Five roles use this page. The filter, the census, and the performance data belong to all of them. Only the metrics inside differ.
One section does not.
Plan and billing is visible to three roles: a Firstday super admin, the customer's account owner, and the delegates that owner appoints.
A disappearing section is a layout problem, not just a permissions problem. Gated content has to be a self-contained section, never half of a shared one.
A shared section that loses part of its contents to gating has to reflow. That is a role-specific layout, and five dashboards to maintain instead of one.
Even done correctly, the block's placement has a cost: wherever it sits, everything below it moves for the roles that cannot see it. Those are the populous ones, the admins at every site.
The remaining question is where it belongs, and the layout section answers it.
The border does a second job
The performance zone is the only bordered region. It was introduced to bind the reporting-period picker to the table and chart.
It turned out to solve something else.
The table stays at 720px while the chart runs to 1168px. Without the border, the table reads as an orphaned narrow element beside a wide one. Inside it, the box becomes the wide element, and the whitespace reads as padding instead of a ragged edge. So, it also absorbs the width mismatch.
Everywhere else, proximity is enough.
Option A: gated section first
Placing Plan and billing above the location control makes every scope claim on the page unconditionally true. Nothing above a location filter is filtered. The label can say applies to all data below and mean it literally. No exception clause.
Structurally, this looked like the answer, and it held the design for some time.
It wasn't.
The problem was visual. Three sections run narrow before the page opens at the performance box: the account card, the filter, and the census. That is most of the page spent at 720px with a lot of unused width down the right.
The severity scales with viewport width. At 1280px the rhythm penalty is tolerable; at 1920px it dominates the page. Institutional desktops are overwhelmingly 1080p, so the wider case is assumed to be the common one.
The only way to fix that rhythm is to widen the census, which constraint two forbids. It was tried anyway. Widened, the census stops arriving as a group and loses its reading order, exactly as constraint two predicts. The rescue route is closed.
VI. Choosing the arrangement
Two layouts were built.
Option A places Plan and billing above the location filter. Constraint one established that this block is timeless: no filter touches it. The location filter can claim every number below it and be literally correct.
Option B places it at the end, below the filter. The block is still outside the filter's reach, so it has to carry its own scope label instead of inheriting one.
The performance card's border absorbs the mismatch between the table and chart widths. The alternating rhythm looks like an inconsistency until you can see the container holding it together.
Option B: gated section last
The Plan and billing block moves to the foot of the page. The filter's claim becomes narrower — filters the data below — while Plan and billing at the very bottom declares its own scope at its own boundary: Account level · Applies across all locations and reporting periods.
The page rhythm resolves, and roles without the block simply get a shorter page.
Option A at 1920px. The page runs narrow through the account card, the filter, and the census before it opens at the performance box.
The decision
The two options are not strong in the same dimension.
Option A has the stronger information architecture. Every scope claim on the page is literally true.
Option B has the stronger composition. It introduces one local exception: the filter no longer governs the final section, which declares its own scope instead.
The choice therefore comes down to where each cost is paid.
Option A's cost is global. The rhythm penalty is present on every screen, in every session.
Option B's cost is local. One section declares its own scope where the exception occurs. That is not a workaround. A section stating its own scope at its own boundary is the grammar every other zone on the page already uses.
Costs paid continuously outweigh costs paid once, locally, with an explanation attached.
Option B was selected.
The page therefore reads, top to bottom: location filter → patient census (720px) → key performance data (1168px, boxed) → Plan and billing (1168px).
That placement is what makes the role rule exact rather than approximate. With the gated block last, removing it changes nothing above it.
The page as built. One narrow section, then full width to the foot, with Plan and billing declaring its own scope at the end.
VII. The chart
Encoding
Eight series, four groups: providers, patients, patient flow, and programs.
Two groups contain a state pair — two states of one entity. State pairs share a hue and differ in lightness: the darker color is the parent, the lighter its twin.
The idea is inherited. The legacy charts already drew inactive counts as pale shades of the same color. A sound instinct, but without a legend nobody could learn the code.
The redesign keeps the idea and constrains it. Only true state pairs share a hue; different entities get different colors, or the encoding asserts a relationship that does not exist. The grouped legend teaches the rule, and its order always mirrors the bar order.
One consequence follows. A parent color must be dark enough to hold a lighter twin, so two mid-dark palette slots are reserved as parents before any hues are chosen.
Grain
The chart adapts its grain to the selected period: daily to about two weeks, weekly to three months, monthly to twelve.
These thresholds are derived rather than chosen. Eight series per group, a minimum readable bar, and a separation gap between date groups limit the plot to roughly twelve to fourteen groups. Beyond that, grouped bars stop being the right instrument.
The same calculation sets the twelve-month limit for custom ranges.
The same chart at three periods, from the working prototype: seven days, three days, and twelve months. The number of date groups sets the bar width, and the thresholds are derived from where that width stops being readable.
Reading exact values
Eight 7px bars can be compared, but they cannot be read.
Hovering anywhere within a date group reveals every series, with its swatch, label, and value, in bar order. The hit area is the whole column rather than the individual bars, so reading a value never depends on hitting a 7px target.
The panel is a convenience layer, not an accessibility mechanism. It disappears in print, and right now it is the only route to an exact value. That gap is named rather than ignored.
Geometry
Bars sit 2px above the axis. Corner radius scales with bar width — 4px at a 28px bar.
The goal is consistency. A fixed radius turns narrow bars into pills; a maximal radius turns short wide bars into lozenges. Scaling the radius keeps the chart looking like itself across every grain.
Color
All colors must stay distinguishable under fatigue, on bad hardware, in grayscale, and to a color-blind reader.
Four constraints shaped the palette.
‣ 1. Contrast. Text follows WCAG AA. Bars require 3:1 against the page, which the current build achieves with borders rather than darker fills. If a data table is added later, the borders become unnecessary.
‣ 2. Grayscale. The chart is routinely printed and photocopied. Each fill therefore occupies a distinct lightness rung, so the legend stays matchable without color.
‣ 3. Color vision deficiency. Bar order is constant and the legend mirrors it, so every series can be identified by position rather than color. Identity is therefore carried by two channels, not one. But a reader who has to count bar positions is not reading a chart. Candidate palettes were rejected if any two series became confusable under deuteranopia, protanopia, or tritanopia.
‣ 4. Visual weight. The navigation already spends the page's darkest color. The chart stays light so it supports the hierarchy instead of competing with it.
The palette is whatever survives all four at once.
The hover panel on Nov 21. The shaded band is the hit area: the whole date group, not the individual bars. Values are listed in bar order, so the panel reads in the same sequence as the chart.
These constraints pull in different directions. Contrast prefers darker fills; visual hierarchy prefers lighter ones; grayscale demands separated lightness values; color-blind safety limits which hues can share them.
The final construction resolves that tension: light, saturated fills with same-hue borders. The borders satisfy contrast, the fills preserve hierarchy, and the lightness ladder preserves grayscale separation.
The palette is organized around explicit lightness rungs and seeded from the product's existing color tokens rather than new accents.
The eight fills in bar order, each over the gray it converts to. Same-hue borders and legend position carry identity, so the fills stay light. Two shade-pairs share a hue and split on lightness: gray with pale gray, coral with pale coral. The rest hold their own rung. Sorted, the ladder runs 112 · 140 · 152 · 166 · 181 · 194 · 207 · 220.
Every candidate was simulator-tested under grayscale, deuteranopia, protanopia, tritanopia, and blur.
Governance
Color belongs to metrics, not positions. Metrics that can appear together never share a token — and the requirement is pairwise, since any two tokens might be the only two on some role's chart. New tokens are simulator-tested against the existing palette before adoption.
The eight fills under grayscale and the three forms of color vision deficiency. Bar order is preserved down every row, so each column is one series. The tightest pairs are gray against caramel in grayscale, and pale gray against seafoam under deuteranopia and protanopia; both stay separable because legend position and borders carry identity alongside the fill.
VIII. Limitations
This redesign shipped without direct access to users or product analytics. The arguments in this case study are therefore perceptual and structural rather than behavioral. They explain why a layout should be easier to read, not whether users actually behaved differently after launch.
This case study covers one page of a larger redesign. I chose it because it captures the kind of problem I enjoy solving and the way I go about it. If you'd like to see more of the work, or talk through any of the decisions, I'd be glad to.
