Casey Drummond
All work
Case study 02 · Onboarding · Activation · Design systems

Self-serve onboarding & activation

Genomic-cloud workflows had steep learning curves and fragmented onboarding for B2B research teams. I led the interaction architecture, data-visualization design and usability testing that turned them into an intuitive, self-serve developer platform.

Role
Sr. Product Designer
Human factors & interaction architecture
Company
Illumina
Genomic cloud platform
Users
Genomic scientists, biotech developers,
researchers, sequencing teams
Tools · Timeline
Sketch, Axure RP, Jira
20-day runway
Confidentiality notice: Product names, logos and identifying details have been replaced or obscured, consistent with my confidentiality obligations. “Omnia” and “LIZARD” are placeholder names, and visuals may differ from the released product.
Self-serve developer platform landing page on laptop and phone
+42%More customers using key features after self-serve sign-up launched
−35%Less time from sign-up to a customer’s first successful result
+28%More people finishing core tasks from start to end
20 daysFrom first research to ready-to-build designs, on schedule
01 · The challenge

Powerful science, hard front door

Scientists came to analyze genomes, not to learn cloud infrastructure.

My focus: dense analytics dashboards and conversational layers that remove onboarding and access friction.

How I think

I match fidelity to the question: decide cheaply, confirm with real data. In 2019 that meant paper first. Today AI gets me to realistic prototypes faster, but the rule still holds.

02 · How I worked

From sticky notes to shipped

Each step answers a question the previous one raised. Here’s what I did, why I chose it, and what it changed.

Step 01

I cut scope before I drew anything

What I did

Prioritized user stories with stakeholders using MoSCoW.

Why this step

We had a 20-day runway. Agreeing on what not to build was the fastest way to protect quality.

What it changed

A focused MVP: sign-in, report access and dashboard sharing.

Whiteboarding the free-trial and first-run flowWhiteboard from a working session on the free-trial flow: sticky notes, trial and grace-period rules in red, and a sketched first-run dashboard showing monthly activity and empty runs and analysis states
Step 02

I whiteboarded with engineers in the room

What I did

Mapped the critical flows (sign-in, report access, dashboard sharing), then whiteboarded the console architecture with the team.

Why this step

With 20 days and a lean team, agreeing on one structure together avoided rework later. Trial rules set the frame: about 60 days plus a 30-day grace period, so the first-run screen had to show usage limits and warn before they ran out.

What it changed

An AWS-style console: core services, tutorials and support in one place, from sign-up to first deploy.

Step 03

I tested on paper first

What I did

Built paper prototypes of the key flows and put them in front of users.

Why this step

Paper is the cheapest thing to throw away, and people critique it more honestly than polished screens.

What it changed

Paper sessions validated the key layout assumptions; minor content changes went in before the grey wireframes.

My paper sketch of the landing page, Dec 2019Pencil sketch in a notebook of the signed-out landing page: a welcome headline, Request a demo and See pricing buttons, and core APIs and services in four columns; product names are blurred
Grey wireframe mid-fi hi-fiThree stacked versions of the Omnia Analytics Services landing page, evolving from a plain greyscale wireframe to the final design
Step 04

I raised fidelity one layer at a time

What I did

Wireframed the landing and report views in greyscale, then layered in content and brand once the structure was agreed.

Why this step

Greyscale kept feedback on structure and content priority, not on color and branding.

What it changed

Stakeholders settled content priority and element visibility early, then added content updates as fidelity rose. Styling waited until the core offer was clear.

Step 05

I mapped the whole journey, not just sign-up

What I did

Mapped Discover, Evaluate, Decide, Onboard and Use & maintain with pain points at each stage.

Why this step

Onboarding friction didn’t live on one screen. It started before sign-up and continued long after it.

What it changed

It surfaced access fatigue and the missing ability to share dashboards, two findings no single screen review would have caught.

User journey map across discover, evaluate, decide, onboard and use and maintain stages
Pages of the usability test moderator’s guide
Step 06

I scripted every usability session

What I did

Wrote a moderator’s guide and ran 9 moderated sessions with developers across 4 countries.

Why this step

Different countries and moderators produce noisy results. One script made the sessions comparable.

What it changed

Five clear findings, from stability gaps to access fatigue, each tied to a platform decision.

Step 07

I saved hi-fi for client validation

What I did

Built interactive hi-fi prototypes in Axure RP and Sketch for the sign-in, landing and report pages, plus the mobile dashboard.

Why this step

Clients react to real data, not boxes. Hi-fi was for confirming decisions, not making them.

What it changed

Clients validated the design before build; the MVP shipped on schedule.

Hi-fi Omnia mobile dashboard showing month-to-date vCPU, FPGA and compute memory usage, and storageHi-fi Omnia mobile dashboard with a monthly usage chart and a usage history tableHi-fi Omnia mobile Service Health screen listing each platform service with a Normal status
A dead end I learned from

Showing hi-fi too early

Some stakeholders wanted a quick hi-fi screen to review. At the time, that would have taken longer and pulled feedback toward styling before the core structure was settled. I kept early reviews in greyscale and saved hi-fi for confirmation.

03 · Research

What the sessions revealed

Tailored & learnableUsers wanted an adaptable service with prominent metrics for at-a-glance status.
Stability gapsThe early release was too buggy, undermining confidence in a promising platform.
Onboarding frictionEmail-heavy registration and out-of-date docs frustrated new users.
Access fatigueForgotten passwords and separate sign-ins per system drove help-desk calls.
Sharing & continuityNo way to share dashboards; switching apps signed users out mid-task.
04 · The direction

“I re-architected the platform, not the science.”

Research exposed an infrastructure gap, not a capability one, so I tied each finding to a specific platform decision.

Self-serve developer consoleRebuilt fragmented APIs into one AWS-style platform: tailored and learnable.
Stability-first releaseHardened the early build and validated before shipping.
Frictionless onboardingStreamlined the path from sign-up to first deploy.
05 · Outcome

The MVP shipped on schedule

Validated by developers before build, delivered by a lean team on a 20-day runway.

“This is a major game changer that will allow us to renew and win more contracts!”
Product Owner, genomics platform
Shipped · desktopOne front door for every developerWebinars, docs, community and changelog sit one click from the console, closing the out-of-date-docs gap users reported.
Released Omnia desktop console on a laptop: webinar and community banners above a Resources section with Getting Started, Examples and Tutorials, Community and Changelog cards