{"id":4515,"date":"2026-08-05T13:46:10","date_gmt":"2026-08-05T17:46:10","guid":{"rendered":"https:\/\/blog.mozilla.org\/ux\/?p=4515"},"modified":"2026-08-05T14:07:57","modified_gmt":"2026-08-05T18:07:57","slug":"let-your-designs-fail-for-the-right-reasons","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/ux\/2026\/08\/let-your-designs-fail-for-the-right-reasons\/","title":{"rendered":"Let your designs fail for the right reasons"},"content":{"rendered":"

How AI-assisted native prototypes changed what usability testing could show me.<\/h3>\n

 <\/p>\n

If you’ve ever simplified an interaction just to make a prototype manageable, you’ve probably felt the tension between what you designed and what the prototype could actually support. The risk is that when a design fails in usability testing, you can’t always tell why. Was the experience itself the problem, or was it really the prototype getting in the way: a missing connection, a laggy transition, a path you didn’t build?<\/p>\n

I ran into this while working on Report Broken Site for Firefox Android, and it led me to a different way of prototyping: building directly inside the real app with AI (Claude), so the test reflects native fidelity rather than a simulation of it. That’s when I started worrying just about the design failing, and not the prototype.<\/p>\n

\"Four-step

Feature: Report Broken Site<\/p><\/div>\n

 <\/p>\n

Reaching limits of walled prototypes<\/h2>\n

In tools like Figma, prototyping requires anticipating every possible interaction and defining it explicitly. For the user to feel the true experience, each path needs to be connected, each transition set, and each variation accounted for. As complexity grows, it tends to increase the cost of maintaining it: screens multiply, connections become fragile, and animations become tedious to maintain.<\/p>\n

At some point, you\u2019re no longer designing the experience. You\u2019re managing the prototype.\u00a0<\/b><\/p>\n

\"Animated

E.g. Changing the animation for one node, requires updating it everywhere manually.<\/p><\/div>\n

To cope, we simplify the prototype. We reduce the number of paths, guide users through predefined flows, and limit what they can do on the prototype. The result is what I\u2019ve started thinking of as a walled prototype<\/b> \u2014 like a walled garden: a bounded space where users can move, but only within the paths we\u2019ve pre-defined.<\/p>\n

Some designers might argue that Figma\u2019s recent additions of variables and advanced logic solve this problem. However, even with these tools, the designer is still building and managing the prototype. Figma prototypes simulate a system; it is not the system itself or a part of it. These prototypes have been useful, but they have also shaped the participant testing experience in ways that haven\u2019t always been obvious.<\/p>\n

 <\/p>\n

\"Zoomed-out

When the logic of a feature is handled by manual connections, the canvas quickly turns into spaghetti of fragile dependencies.<\/p><\/div>\n

Prototypes shape participant behavior<\/b><\/h3>\n

This becomes especially noticeable in usability testing. Test participants tend to recognize when they are interacting with a prototype, and that awareness can change how they behave. They may hesitate to explore, follow the perceived intent of the task, or tap around when they get stuck.<\/p>\n

For example, to keep a prototype manageable, I might only make a few issue types selectable. But then participants are doing two things at once: deciding what they want to do and guessing what the prototype will allow. Their feedback can become shaped by the prototype\u2019s limits, not just the design \u2014\u00a0 like a visitor to the walled garden checking which paths are actually open to them.<\/p>\n

That constraint can be useful in early concept testing, where a narrower path helps focus the conversation. It becomes more limiting when we are trying to understand how the full experience behaves.<\/p>\n

Research and practice have long acknowledged that prototype fidelity<\/a> and testing setup<\/a> can influence participant behavior. But in practice, many workflows still rely on constrained, screen-to-screen simulations.<\/p>\n

I\u2019ve often wondered:<\/p>\n

How a user\u2019s perceived experience might change if they weren\u2019t encountering the feature in the isolation of a walled prototype?<\/i><\/b><\/p><\/blockquote>\n

 <\/p>\n

From walled to native fidelity prototypes<\/h2>\n

Designing and prototyping is often described in terms of fidelity \u2014 from low-fidelity sketches to high-fidelity designs ready for dev handoff. That framing focuses on how closely we represent the product, but not necessarily how the experience itself behaves.<\/p>\n

As building realistic interactions becomes easier using AI, it may now be possible to move beyond simulating flows in Figma and towards observing how people actually behave. So, alongside designing it in Figma, I built the feature directly into a local version of the Firefox Android app using Claude. It wasn\u2019t straightforward at first, but even the friction of getting it working revealed things I wouldn\u2019t have seen in a Figma prototype.<\/p>\n

When I did this, I noticed there were no predefined paths to manage or fragile connections to maintain. The experience felt more continuous, allowing users to move more freely, not just within the feature, but within the app itself. I started thinking of these as prototypes with native fidelity<\/b> \u2014 native to the app, native to the device, and aligned with how users expect interactions to behave.<\/p>\n

When prototypes need to handle dynamic behavior<\/b><\/h3>\n

The difference between the two types of prototypes is not just theoretical; it starts to change what the experience can support. In walled prototypes, content is often fixed, and interactions move users between predefined screens. While this works for simple flows, it becomes harder to represent how interfaces behave when content needs to update dynamically based on user interaction.<\/p>\n

In the Report Broken Site<\/b> feature, this was important. A walled prototype struggles with:<\/p>\n