I Thought My Design Was Good. 25 People Proved Me Wrong.

A two-round usability testing journey using Figma + Maze, and what I learned the hard way.

Picture by Thai Duy Hoang

Here’s something no design class fully prepares you for: the moment you watch someone use your website and get completely, utterly lost on a page you thought was obvious.

That happened to me. And honestly it was the most valuable thing that could have happened.

This is the story of how I ran two rounds of usability testing on my website, what broke down, what I fixed, and why I’ll never skip user testing again.

What I Built and Why It Needed Testing

Gallery Fasilkom UI is a platform where students can showcase the projects they’ve built throughout their time in college — and where lecturers can review submissions before they go live. Think of it as part academic portfolio, part public showcase. It’s a space that gives student work the visibility it deserves, while keeping quality in check.

The layout felt clean. The navigation seemed intuitive.

Before pushing anything to production, I needed real people to walk through it. That’s where usability testing — a research method where real users are observed performing specific tasks on a product, such as a website or app — came in.

The Setup: Figma + Maze

For both rounds of testing, I used a Figma prototype as the test medium and Maze as the testing platform.

Why these two? Figma let me simulate a realistic, clickable prototype without writing a single line of code. Maze then tracked everything including task completion rates, time on task, click paths, misclick rates, basically all the data I needed to validate my design.

1st Round: Throwing My Design at 13 People

My first round involved 13 stakeholders, consisting of:

• 9 students — representing the primary end users
• 3 lecturers — representing the evaluator perspectives
• 1 admin — representing the operational side

The diversity was intentional. A design that only works for one type of user isn’t really a good design, right?

I expected minor friction. A few small tweaks at most.

This is what I got instead:

• Usability score for “Buat Karya” task (students): 52/100 — nearly half the students struggled to flow through what I thought was the simplest entry point
• Misclick rate on the same task: 49.5% — almost every other click was landing on the wrong element
• Average completion time: 70.1 seconds — for a task I assumed would take under 60

The heatmaps from Maze told an even clearer story. The SSO login page was the first problem. Users kept tapping the username and password fields, expecting to type something, but my prototype didn’t support input interaction. So they were stuck, clicking repeatedly on something that wasn’t responding, before eventually figuring out they just needed to hit the login button directly.

I had never thought to make the login fields interactive in the prototype. To me, it was obvious you’d just click login. To 9 out of 9 students, it wasn’t.

The lecturer flow was even more revealing: the “Review Karya & Berikan Catatan Revisi” task scored a usability score of just 45, with only 25% of lecturers completing it through the expected path. The review workflow that made perfect sense on my Figma canvas? In practice, people were wandering between pages, unsure of what to click next.

It wasn’t a user error. It was a design assumption I had never questioned.

It hurts, not gonna lie, but it was exactly the kind of insight I needed.

The Redesign

Having the insight of my faults, I went back to Figma and made targeted revisions. Here’s the core of what I changed:

• SSO login fields weren’t interactive, users repeatedly clicked the input expecting to type → Made fields auto-fill with dummy data on click, simulating a realistic login experience.
• Onboarding, project submission, delete request, and profile edit forms all had the same dead-field problem → Applied auto-fill interaction across all form pages so users immediately understand the fields work.
• The submit button on the project submission page read “Ajukan Perubahan” → Renamed to “Ajukan Karya”, which actually matches what the user is doing.

2nd Round: Getting My Rematch

For the second round, I tested with 12 stakeholders:

• 9 returning students from Round 1
• 3 new students who had never seen the design before

This combination was deliberate. The returning users could tell me whether the specific problems were actually fixed. The new users could tell me whether the design still works well without prior context.

Then, come the million dollar question:

Did it actually get better?

Across all four student tasks, here’s a glimpse of how far the numbers moved:

The Create Project task — the one that hurt the most in Round 1 — went from a usability score of 52 all the way to 96. Making the prototype forms interactive turned out to be a single change with an outsized impact.

But here’s what I want to be honest about: not everything was fully resolved.

The “Edit Project” task’s misclick rate actually went up slightly from 32.0% in Round 1 to 35.7% in Round 2. Maze heatmaps showed users were still clicking around the dashboard (filter buttons, search bars, even the profile icon) before landing on the right project. The core flow works, but the dashboard’s visual hierarchy still needs clearer signals to guide users directly to what they’re looking for.

That’s okay. Usability testing isn’t about achieving perfection in two rounds. It’s about making measurable progress and knowing exactly what to do next.

What Did I Learn?

1. Your mental model is not your user’s mental model.

I designed based on what made sense to me. What Round 1 showed me is that my assumptions about how users think were often wrong. It’s not because users are bad at navigating, but because I never communicated my logic clearly enough through the design itself.

2. Diversity in participants isn’t optional.

Having students, lecturers, and an admin in Round 1 surfaced completely different points. If I had only tested with students, I would have missed critical feedback from the other two parties. Since real-world products serve varied users, the test should also reflect that.

3. Data > Opinion.

Before Maze, feedback sounded like “I think this button should be bigger.” After Maze, it sounded like: “78% of users misclicked on this button before finding the right one.”

🌿Last but Not Least,

If you’ve built something — a website, an app, a prototype — and you haven’t put it in front of real users and watched them use it, you’re still just guessing.

Usability testing isn’t about proving your design is good. It’s about finding out how to make it better and doing it before the users encounter the problems you could have fixed.

Two rounds, 25 people, and dozens of misclicks later, I finally know better. Not because my current design is perfect, but because I know what works and what still needs work.