Onboarding five very different users onto one accident-recovery platform
Signup and intake flows for HelpAfterAccident.com: doctors, lawyers, patients, marketers, and influencers. Designed in a two-week internship sprint at GoMAXPAIN.
RoleProduct Design Intern
TeamMe + Senior Designer (mentor)
Timeline2 weeks
PlatformiOS + Desktop Web
ToolsFigma
5User personas
100+Screens designed
2Platforms (mobile + laptop)
4Intake models explored
2 wksConcept → handoff-ready
The Context
One platform, five front doors
HelpAfterAccident.com connects people injured in accidents with verified doctors and lawyers nearby, and gives those professionals a steady stream of matched patient leads.
The product only works if both sides of the marketplace show up. A doctor abandoning signup at step 6 isn't a lost user; it's a hole in the supply that patients feel. My internship project at GoMAXPAIN was to design the onboarding experience for every user type the platform serves:
DoctorLawyerPatientMarketing ProInfluencer
Each persona needed a flow that felt personal. Underneath, the system had to stay shared (same auth pattern, same components, same visual language) so engineering could build once and branch.
My role: design intern, working under a senior product designer who set the strategy and reviewed every round. I executed the flows myself, wireframes through high-fidelity states, and owned the screen-level decisions. Every checkpoint meant presenting the work and defending it in critique.
The Problem
Professionals don't finish long signups
Doctors and lawyers are hard to onboard. They're busy, they're skeptical, and we were asking for a lot: credentials, practice details, clinic hours, team members, payment preferences. Long professional signups bleed users at every screen.
The brief broke into three questions:
1
How short can "complete" feel?
A practice profile needs about ten steps of input no matter what. We couldn't cut steps, so they had to feel light.
2
How do five personas share one system?
A doctor sets clinic hours; a lawyer doesn't. Flows had to diverge after a shared trunk without forking the design system.
3
How do patients in crisis get through intake?
Patients arrive right after an accident, often hurt and rattled. Intake had to flex to whatever they could manage.
The Process
Two weeks, four checkpoints
Days 1-3 · Flow mapping & trunk designMapped the shared signup trunk: phone-first auth → OTP → profession select → identity → practice details. Phone-first (with Google/Apple fallback) because professionals respond faster to SMS than email, and the platform's match alerts are SMS-driven anyway.
Days 4-7 · Mobile iterations per personaBuilt the iPhone flows for doctor and lawyer first, since they're the most valuable users and the most likely to drop off. Every screen got an empty and a filled state, plus enabled and disabled CTA logic.
Days 8-10 · Desktop adaptation + patient intakeAdapted the flows to a split-screen laptop layout, then designed four patient intake models in parallel: one-click intake, self intake, digital intake with instructions, and phone intake conducted by a specialist.
Days 11-14 · Critique loops, V5 → V6, dashboardTwo full revision rounds with my senior. We marked the rejected directions and kept them on the canvas for comparison. Closed with the professional's post-signup dashboard, the day-one experience after going live.
One persona end to end: the lawyer onboarding flow, with every step in filled and empty states.
Key Decisions
The design calls that shaped the flow
1 · One question per screen, momentum over density
Rather than cram the practice profile into three dense forms, I split it into single-purpose screens ("What's your name?", "Where is your practice?", "Set your clinic hours"), each with one CTA. A "Take 2 minutes or less" promise up front sets the contract. The headlines also talk back: once Jane picks Doctor, the next screen greets her with "Hello, Dr. Jane." Small thing, but it makes ten steps feel like a conversation instead of a form.
The shared signup trunk. Every screen exists in empty + filled + disabled/enabled CTA states.
2 · Clinic hours: the iteration I'm proudest of
My first clinic-hours screen used a dropdown row per day. It worked, but it was cramped and fiddly on a phone. In critique my senior asked a simple question: how many clinics actually keep different hours every day? Almost none. The revised pattern uses tappable day chips, Mon to Fri pre-selected, with one opens/closes control. The common case now takes two taps. The odd schedule still works.
Initial iteration (left) vs. revised pattern (right). Designing for the common case first.
3 · Patient intake that flexes to capacity
Someone who was just in a car accident might manage a form. They might only manage a phone call. So instead of one intake flow there are four: one-click intake, self intake, digital intake with guided instructions, and phone intake run by a specialist, where the patient's only job is to pick up. The platform routes people by what they can handle that day.
Four intake models for four levels of patient capacity.
4 · Trust signals where skepticism peaks
Skepticism peaks at three moments. The first screen answers it with "Connect with over 5,000+ verified lawyers and doctors nationwide." Password creation answers it with rule checkmarks that tick live as you type. And before going live, a full "Review and finish" summary lets you edit any section. The final screen reads "You're live. Patients and clients in your area can now find you." Signup ends on a payoff rather than a dead end.
Ending on the payoff: the moment the professional's practice goes live.
5 · Desktop gets the same care
Professionals often sign up from the front-desk computer, so every mobile step has a laptop counterpart. The split layout keeps the brand illustration on the left and a focused form column on the right, and the two platforms read as one product.
Full mobile/desktop parity across the signup trunk.
The Outcome
Handoff-ready in two weeks
Complete onboarding for 5 personas across mobile and desktop: 100+ screens with empty, filled, and disabled states, delivered inside the two-week window.
Designed 4 patient intake models that gave the business a way to route patients by capacity.
Set the onboarding visual language (navy and pink palette, conversational tone, illustrated layouts) that the later persona flows adopted.
My senior designer and the GoMAXPAIN team approved the work for the HelpAfterAccident.com build.
Beyond onboarding: the professional's day-one dashboard with urgent matches and the patient queue.
What this project taught me: how to ship a coherent system at speed, and when to defend a decision in critique versus when to let it go.
Mentor's Evaluation
From my internship performance review
"Noibedya operates far beyond the typical baseline expected of an intern. Their workflow is characterized by professional rigor, technical compliance, and a strong eye for visual balance."
On systems thinking
"They don't just place pretty buttons; they analyze the structural dependencies of a workflow. They map out the why behind a layout before executing the what."
On designing for stressed users
"Instead of overwhelming a high-stress user base with walls of inputs, Noibedya utilized a progressive disclosure model... lowering cognitive load and preventing user dropout."
On developer handoff
"By structuring high-fidelity interactive flows complete with edge cases, empty states, and dynamic form validations, they minimized engineering friction and accelerated the development sprint cycles."
On autonomy
"They routinely anticipated edge-cases in the registration and intake funnels, presenting alternative flow layouts to management before bottlenecks could arise."
Looking back at the file now, the two-week pace left real debt. Naming it is part of the lesson:
Tokens-first, from day one
I kept shared element sheets as the source of truth. Next time I'd formalize them into Figma variables and component sets before screen production starts; that would have caught the small state drifts before critique did.
Bake in accessibility earlier
Some pink-on-white and grey disabled states need a WCAG contrast pass, and several touch targets run small. These are cheap to fix at the component level and expensive at the screen level.
Add progress indication
The one-question-per-screen pattern needs a stepper so users know how far is left. It's the first thing I'd test.
Archive with discipline
Rejected iterations lived next to live work. A clean archive page with a changelog would have made the file self-explanatory for engineers.
That self-audit habit, reviewing my own file the way a design lead would, is now how I close every project.
