In my first week at Razer, I created my own Razer ID account. Before I had received a brief or opened Figma, I noticed something: I hesitated at the password creation step. I had not yet confirmed my email — I had not made any real commitment to the platform — and I was already being asked to invest effort in creating a password for an account I had not decided to complete. That moment of friction became the hypothesis I spent the internship testing: that the flow’s sequencing, not its visual design, was causing users to abandon.

Razer ID is the unified onboarding system used across Razer’s global product ecosystem — every device, every service, every purchase passes through it. Friction in the creation flow means fewer accounts completed, fewer users retained, and a first impression of the brand that works against everything downstream. Given a blue-sky brief, my goal was to identify the structural cause of that friction and redesign the flow to address it.

The existing Razer ID creation flow placed too many decisions in front of users too early, creating unnecessary cognitive load at the point of first commitment. Drop-off and hesitation during the verification step indicated a structural problem with the flow’s sequencing — not just its visual design. A user who has not yet verified their email has no reason to invest effort in choosing a username and password. The flow was asking for commitment before establishing trust.

Rather than relying on a single user group, I planned and ran moderated usability testing sessions with participants drawn from five internal departments — marketing, HR, software development, and the UI/UX team — to surface a diverse range of mental models and expectations. Sessions combined qualitative observation with quantitative task-completion tracking, ensuring findings were both behaviourally grounded and defensible to stakeholders across three iterative rounds.

Users were most likely to abandon the flow when asked to create a username and password before their email had been verified. Resequencing these steps — asking for email first, completing verification, then proceeding to account setup — significantly reduced early friction and improved perceived clarity of the process. This became the structural principle that every subsequent design iteration built on.

After Round 1 testing, I made one structural call that shaped every iteration that followed: move email verification to Step 1, before any other account detail is requested. This was not a visual change — it was a sequencing change. The reasoning: a user who has verified their email has made a commitment. A user who has not has every reason to abandon. Every subsequent design approach I tested built on this resequencing. The question shifted from “should we resequence?” to “how do we best handle what comes after verification?”