With the usability and speed of modern product design tools, most designers utilize high-fidelity, clickable prototypes to illustrate product flows. Clickable prototypes help designers to quickly understand interactions and are ultimately used to facilitate design conversations with clients & developers. Plus, these design tools enable you to add ever-complex transitions and get components pixel-perfect. Most designers assume this is a necessary part of the design process but as an empathetic team member, designers should be asking themselves, "Who is the prototype serving? Does this way of working best serve the primary recipient of the designs?"
To add clarity, we should define what we mean here by a “clickable prototype.” A clickable prototype begins as a high-fidelity design mockup created in a design tool like Figma or Sketch. Then, hotspots (or clickable areas) are applied to specific points on a screen that trigger a transition to another screen(s) - emulating the functionality of a real digital product. For example, a hotspot applied to the Send button would progress you to a success screen. (See images below.)
.gif)
The right tool for the right job
So, when is a clickable prototype really necessary and when is it better to deliver something else? I can think of a few scenarios in my experience where a prototype is valuable and where another design asset might be more beneficial for the recipient.
The development team
Our development team doesn’t just need perfectly flowing happy paths in a clickable prototype. A happy path is the imagined default flow of a user through an application encountering no errors or edge cases. In fact, designing for happy paths can be detrimental, because following too closely with a single flow often means leaving edge cases unexplored.
I've also found that developers sometimes prefer to see the whole scope of the application, having access to any screen they want rather than a linear flow. Having access to all screens, great inspection tools, and a robust component library is a great recipe for close collaboration with the dev team. Creating screens that don’t stick to one single flow also allows software designers to explore other states or edge cases that would otherwise be raised by developers during implementation.
The user or test user
This is where high-fidelity prototypes shine - and sometimes fail due to a specific, defined clickable path. When user testing, you’ll want to make sure you have a robust, high-fidelity clickable prototype so users can get a realistic feel for what a final app experience may be. This will help elicit better feedback and cause less confusion for the user. Prototypes with a more narrowly defined flow are okay too! Just be sure the user knows that this isn’t the final app and be clear about their specific objective. Figma’s built-in Presentation view is a great way to get your prototype in front of users. Combine your prototype with paid tools like Maze to collect powerful data-driven user feedback.
The client
Clients typically love features and flash, and high-fidelity prototypes deliver that. It’s easier to walk through a design solution if it feels real. And it’s easier for our clients to talk to their stakeholders or user testers if it looks real. But clients of different sizes and goals all have different needs. To address what each might want, let’s break them down into a few examples:
- Startup
- Midsize
- Enterprise (looking for buy-in)
- Enterprise (ready to build)
Startup
The startup client may be looking for something akin to a concept car. A product designed to look great but doesn’t yet have the practicality or functionality of the full user experience. At this stage, low-fidelity designs might be a good place to start as the client is defining what they want. In the end, high-fidelity mockups are probably the goal as they provide the vision and inspiration a startup needs to garner interest and support.
Again, these are likely aspirational and may not need any type of advanced prototyping. Some startups with no real product might be looking for something that feels real. A prototype can help with that and give potential users or investors a sense of what the product could be.
Midsize
A midsized client typically has the budget for a larger design engagement. So low-fidelity designs that turn into high-fidelity mockups are the place to start. More refined designs help facilitate the conversation and help the client to understand what the end product may actually look like. Turning these types of mockups into clickable prototypes can be helpful to turn a simple design engagement into a larger engagement that includes development work. Showing the client how the app or product would actually look in practice can help illustrate the value in a design/development engagement helmed by the same team.
Enterprise (looking for buy-in)
The enterprise client who is looking for internal stakeholder buy-in is likely led by a team member who has a pretty good idea of the product or feature they want. Taking the initial concepts from the client and turning them into visuals that can be shared and discussed are invaluable assets that don’t require any prototyping. These visuals may range from low to high-fidelity depending on the stage the client is at with the concept.
Enterprise (ready to build)
An enterprise client who is ready to build may need a combination of high-fidelity mockups and clickable prototypes. Detailed designs are critical for developers to build the product while clickable prototypes may not be critical - though they can still provide some insight into intended interactions. Ensuring the design assets include components, error states, and edge cases will almost always be more valuable than a clickable prototype.
Wrap up
Modern design tools allow creatives to work faster and with higher fidelity than ever. Cloud-based software and a large catalog of plugins means our tools are consistently on the bleeding edge of what’s possible in user experience and user interface design. However, just because a tool can do something, I’m finding myself asking if I should be doing it in the context of a particular client or recipient.
