.h
resume / cv
product design · ux research · mobile & web

Safety Hub
Command Center
& Dashboards.

Two phases over twelve months on a construction SaaS product. Phase 1: user feedback became PM requirements, I turned those into a design brief and built a mobile command center for job-site safety. Phase 2: a new requirements doc became a UserTesting study, a first iteration, synthesis, and a guess-free dashboard system on web and mobile.

Design Lead Mobile & Web UX Research Usability Testing Multi-Phase Construction SaaS
duration
12 months
2025 – 2026
my role
Design Lead
Mobile-first
platforms
iOS · Android
+ Web
phases
2
Command center → Dashboard cards
research
UserTesting
unmoderated study
collaborators
PM · Researcher
+ Engineering
.01 — where it started

User feedback in.
Requirements out.
Design brief next.

The project didn’t start with a Figma file. It started with user requirements and raw feedback from safety managers on active job sites. The PM translated that into structured requirements. My job was to turn those requirements into a design brief — and then into a mobile command center that made sense in the field.

01

User requirements & raw feedback

Safety managers needed faster access to scattered safety tools — incidents, observations, inspections, hazards — from one place on mobile.

02

PM requirements

The PM consolidated feedback into product requirements: one command center, overview cards per safety module, scannable stats and drill-through paths.

03

Design brief

I translated requirements into a mobile design brief — information hierarchy, card grammar, navigation depth, and what “done” looked like for Phase 1.

04

Safety Hub

Exploration through iteration to a validated command center with flows into every safety module.

01 — fragmented access

Safety data lived in separate corners of the product

Incidents, observations, inspections, toolbox talks — all existed as separate modules. For a safety manager arriving on site at 7am, getting the full picture meant visiting four different areas of the app before walking the floor.

02 — no signal surfacing

The product didn’t triage. The user had to.

There was no view that answered: what’s open, what’s trending, who are the repeat offenders. Managers were doing the mental assembly work on top of a product that should have done it for them.

03 — mobile-hostile data

Dense dashboards designed for desktops

Safety work happens on-site, on mobile, often in glare, wearing gloves, with 30 seconds to spare. The existing data views weren’t designed for those conditions.

.02 — my role

What I actually owned.

I owned the translation layer between requirements and design across both phases — writing the brief, designing the command center, planning the study, running synthesis, and delivering cross-platform dashboard cards.

↗

Requirements → design brief

In Phase 1, I took the PM’s requirements and wrote the mobile design brief that defined command center structure, card grammar, and navigation depth. In Phase 2, I received a separate requirements doc for five dashboard cards and turned it into a research-backed design process.

▦

UX research: plan, test, synthesize

Phase 2 was mine end-to-end. I converted requirements into a UserTesting unmoderated study — wrote the plan, designed the first iteration prototypes, ran the sessions, and led synthesis into a guess-free redesign.

▯

Mobile-first command center

Led all Phase 1 mobile design: command center architecture, overview cards per safety module, drill-down flows from category to process to individual reports. Every screen answered status, trend, and next action at a glance.

☉

Cross-platform dashboard cards

Phase 2 extended to web and mobile in parallel. After synthesis, I designed the guess-free card system for both surfaces — same data, different density and layout decisions for each platform.

.03 — phase 1 · mobile command center

From requirements
to a working command center.

Phase 1 was mobile-only. Starting from the PM’s requirements and my design brief, I explored what belonged in the command center, iterated on how data should surface, and mapped a single navigation pattern across every safety module.

01 — exploration

Early concepts: what belongs in Safety Hub?

First explorations tested how to surface safety features as scannable list items — emergency contacts, safety checks, trip sharing, and module-specific entry points. The question wasn’t layout yet; it was what managers expected to see when they opened the app.

Phase 1 exploration — Safety Hub module list
02 — dashboard iterations

Adding data: safety scores, incidents, and status.

Once the command center structure was defined, I explored how to layer data onto it — safety score trends, open incident counts, critical items, and equipment status. Multiple iterations tested graph placement, card density, and how much a manager could absorb in one scroll.

Phase 1 dashboard iterations — safety score and status cards
03 — navigation flows

One pattern, every module.

I mapped a consistent three-tap path from the command center into hazards, observations, incidents, inspections, and safety checks: status and counts at the list level, detail only when something needs action. Deeper modules extended the same logic — inspections grouped by site, project, then unit; safety checks by category, process, then report. Managers see status at the top and act at the bottom, never the other way around.

Phase 1 navigation flows — pattern across safety modules
.04 — phase 2 · dashboard cards

Requirements in.
Study out.
Guess-free designs.

Phase 2 started with a new requirements document for five dashboard data visualization cards. I turned those requirements into a UserTesting unmoderated study, designed a first iteration, ran the tests, synthesized the findings, and redesigned everything into a guess-free version on both web and mobile.

01

Requirements doc

PM handed off requirements for five dashboard cards covering claims, hazards, incidents, hours lost, and attendance.

02

Study plan

I converted requirements into a UserTesting unmoderated study — tasks, success criteria, and comprehension questions for each card.

03

First iteration

Designed the initial card set from requirements and built prototypes for the study.

04

Test & synthesize

Ran unmoderated sessions with construction professionals, then organized findings by failure pattern in a synthesis doc.

05

Guess-free redesign

Redesigned all five cards so users didn’t have to infer, calculate, or guess what they were looking at.

.the research study
12
Construction professionals
in unmoderated UserTesting study
5
Dashboard cards tested
(all of them, not just the “risky” ones)
4/5
Cards redesigned after synthesis
before development handoff
2
Platforms delivered
web and mobile in parallel

The study tested one question per card: can a construction safety manager understand what this is showing, and what to do next, without guessing? I wrote the plan, ran synthesis, and organized findings into three failure modes — not by card, but by the type of comprehension breakdown. That structure is what made the redesign decisions specific instead of generic.

finding 01 — don’t make users do math

Hours lost should be a number, not a calculation.

what participants did

The first iteration showed “time lost to injury” as projected vs. actual work hours. Participants stared at the chart without answering — they were trying to subtract in their head. They expected to see hours lost directly.

“I’d expect lost hours or days due to incidents — not projected vs. actual work.”

— UserTesting participant
guess-free fix

Direct monthly bar chart showing hours lost. Title matches the unit. The number is the message — no derivation required.

finding 02 — seeing isn’t solving

Status without context is just noise.

what participants did

The hazard assessment gauge showed open items clearly, but labels were misread — “project total” meant different things to different participants. They understood something was wrong but couldn’t decide what to do.

guess-free fix

Semicircular gauge with clarified labels, timeframe context, and percentages paired with raw counts. Status and action path in one glance.

finding 03 — right data, wrong frame

If the title doesn’t say injury, users read billing.

what participants did

The claims card was read as contractor billing because “injury” didn’t appear in the title. The attendance chart required subtracting two bars to get a ratio — arithmetic nobody should do at 7am on a job site.

“This looks like it’s tracking money. Is this contractor payments?”

— UserTesting participant, on the claims card
guess-free fix

Injury context made explicit in naming. Trend sparkline for at-a-glance direction. Attendance replaced with a single percentage bar — attended vs. total, stated plainly.

One card passed without changes. It became the benchmark for the guess-free redesign. Every other card was measured against it: direct labelling, matched title-to-unit, a single dominant number.

guess-free deliverable

Five cards. Two platforms. Zero guesswork.

The final designs applied every synthesis finding across web and mobile — same card grammar, platform-appropriate density.

web — safety dashboard
Phase 2 guess-free web safety dashboard
mobile — safety dashboard
Phase 2 guess-free mobile safety dashboard
.05 — what this demonstrates

Skills in practice,
not in theory.

This wasn’t a sprint or a single feature. It was a sustained year of design leadership on a complex enterprise product — research-heavy, cross-platform, multi-phase, and shaped by real user behavior.

01

Requirements to design brief to screens

Phase 1 started with user feedback and PM requirements — I wrote the design brief and designed the mobile command center from scratch. Phase 2 started with a separate requirements doc — I converted it into a research plan, tested a first iteration, and redesigned based on synthesis. In both phases, I was the person who translated requirements into design decisions.

02

End-to-end UX research ownership

Phase 2 research was fully mine: study plan, UserTesting setup, first-iteration prototypes, unmoderated sessions, synthesis doc, and redesign. Findings were organized by failure mode, not by card — which turned a list of problems into a design brief with three clear principles.

03

Cross-platform design execution

Phase 1 was mobile-only. Phase 2 delivered the same five dashboard cards on web and mobile simultaneously — same data grammar, different density and layout per surface. Not a resize; two genuinely different design problems solved in parallel.

04

Multi-phase systems thinking

The command center architecture from Phase 1 — category overview, process drill-down, report detail — informed how Phase 2 cards were structured. Status at the top, action at the bottom. That hierarchy carried from mobile navigation into dashboard data visualization across both platforms.

.06 — reflections

What I’d carry forward.

Write the brief before you open Figma.

Phase 1 worked because I translated PM requirements into a design brief first — defining hierarchy, card grammar, and navigation depth before any screens existed. That brief became the reference point for every iteration decision that followed.

Turn requirements into a study, not straight into pixels.

Phase 2 could have gone straight from requirements to final designs. Instead, I built a UserTesting study first. That one decision — testing before committing — caught comprehension failures in four of five cards that looked fine on paper.

Synthesis structure determines what gets fixed.

Organizing findings by failure mode (“users had to do math,” “labels were misread,” “title didn’t match content”) instead of by card turned a research report into a redesign brief. The way you organize what you learned shapes what people can act on.

Guess-free is a design standard, not a polish pass.

The guess-free redesign wasn’t a visual cleanup — it was a comprehension standard. Every card had to pass one test: can a manager understand this in 10 seconds without inferring anything? That principle applied equally to web and mobile, even though the layouts were completely different.

.more work

2023–2024 · SaaS · Design Lead

Meridian — Smart Scheduling & Personal Brand

view case study

2026 · Construction SaaS · Product Designer

Qualifications Management — Safety Credentials & Compliance at Scale

view case study