83 Bar · Nov–Dec, launched February

Putting clinical trial patients in the loop.

Card-based architecture as the answer to reusability-vs-specificity. Mobile-first, security-first. Built for patients whose relationship with the word "clinical trial" is already complicated.

Sole Product Designer 1.5 months NDA

Study Tracker home screen — a phone showing the patient's progress through a 7-step study with a card-based checklist

The Study Tracker home screen. Card-based progress through every step of a study — one place where patients see what's done, what's coming, and what changed.

83 Bar's recruitment work brings patients into clinical trials, but the relationship doesn't end at sign-up — patients move through tasks, kits, and protocol checkpoints over weeks or months. Without a dedicated tool, that journey lived in emails, phone calls, and the patient's own anxious guesswork.

The Study Tracker app was built to give patients a real-time view into their study — what's done, what's coming, what changed — and to let them communicate directly with the team running it. The design challenge was doing this across a wildly varied patient population, at a mobile-first form factor, against a six-week clock.

The Problem

Trial patients tolerate uncertainty better than they tolerate silence.

Patients need to be in control of the process in real-time, to easily receive and deliver information to stakeholders, and to facilitate communication.
Project brief

Translating that into design problems: patients couldn't see their own study progress without contacting an agent. Communication was asynchronous in the worst sense — slow, one-directional, and easy to lose. Protocol changes happened, but patients often heard about them later than they should have. And users were technically varied — the app had to work for someone confident with a smartphone and someone who isn't.

Strategic Considerations

Three architectural decisions made before the first screen.

Reusability vs. specificity — the card architecture answer

83 Bar runs many studies, and a custom-designed app per study would have been unmaintainable — but a generic app risked feeling impersonal for each study's specific protocol. I argued for a card-based architecture: the app's structure stays constant across studies, but each study fills the cards with its own steps, language, and assets. That decision is what made the app reusable across clients without bespoke design work.

Platform priority — mobile-first, not mobile-adapted

Patients use phones in waiting rooms, at home, on the move — but they fill out longer protocol questionnaires and read updates on desktop. The default would have been to design desktop-first and adapt down. I pushed for mobile-first because the moments that actually mattered for patient confidence — checking status, getting protocol updates — were mobile moments. Desktop is for the deeper sessions.

Security as a phase-one design problem, not a phase-two retrofit

Two-factor authentication was non-negotiable given the data sensitivity. I designed the auth flow against patterns the persona already trusted — banking-style 2FA — rather than introducing custom auth that would have read as friction. Treating security as a design problem from the start meant it didn't become a launch-blocker later.

Design Decisions

Four decisions that defined the product's architecture.

Card-based study process — each step of a study lives in a card: current, upcoming, completed. Patients see where they are and what's next without scrolling through a wall of text. New study, different cards, same architecture.
Two-factor authentication designed to feel familiar — similar to banking apps the persona already used. Security without friction.
Kit-in-process screens for the moments when a physical test kit is in transit, with status that updates without the patient having to refresh or contact someone.
Mobile-first with desktop parity — the mobile experience carries the trust-critical moments; desktop carries the longer review and data-entry sessions.

Patient progress view — seven cards showing completion percentage for each study step, from eligibility through gift card delivery — The card-based progress view. Each step of a study lives in its own card with a completion percentage and clear state.

Kit-in-process screen showing a three-step indicator — En Route, Received, Processed — with the current state at Received — Kit-in-process screen. Status updates as the physical kit moves through the lab pipeline — removing the most common reason patients had to call support.

Two-factor authentication screen offering a security code via text message or email, styled like a familiar banking 2FA flow — Two-factor auth, designed against patterns the persona already trusted. Security as a phase-one design problem.

Outcome

Launched in February. The architecture proved its thesis.

Patients stopped operating in the dark

The card-based progress view replaced the email-and-phone-call loop that used to dominate patient-side communication, giving patients a single place to see where they were in a study.

The architecture proved reusable

The same card system powered subsequent studies without bespoke design work — the practical test of the "build once, deploy across studies" thesis baked into the structure from the start.

Two-factor authentication didn't become a friction point

Designing the auth flow against patterns the persona already trusted meant the security layer landed without dragging on adoption — which, for a patient population that self-describes as not very tech-savvy, was the real test.

Kit-in-process screens removed a category of inbound questions

Patients waiting on physical test kits previously contacted support to check status. Surfacing that status in-app meant those questions stopped reaching the team.

The 1.5-month timeline forced me to ship before doing usability testing with the most vulnerable users. That's now my top accessibility priority for v2 — but I should have negotiated harder for the time.
From the project retrospective

What I'd Do Differently

Negotiate harder for accessibility testing time.

The card structure works well for the typical persona. I haven't yet validated it works for someone using a screen reader or one-handed input — and I shipped without that knowledge. That gap is now a structured next step, but I should have pushed for a one-week extension in the original timeline to include those users in the validation pass.

Additional artifacts — wireframes, prototypes, validation session notes — available on request.