In short
A click dummy (also clickable prototype, in German Klickdummy) is a clickable model of an app, website or software made up of linked screens. Anyone who taps a button, a menu item or a card jumps to the next prepared screen.
Behind it there is no program logic, no database and no interface: all content is designed in advance, and all paths are defined in advance. A click dummy therefore simulates the behaviour of a product without being one.
That is precisely where its benefit lies. With a click dummy, flows, navigation and screen layout can be checked before a single line of production code is written. Errors in user guidance are noticed while they are still cheap to fix. This entry explains what makes a click dummy, how it differs from a prototype, MVP and mockup, what companies use it for, how to create one step by step and where its limits lie.
What is a click dummy? Definition and characteristics
The German term combines "klicken" (click) and "Dummy". A click dummy is thus an operable mock-up of the later interface. In software development, it counts as a prototype, more precisely as a so-called horizontal prototype: according to the Wikipedia article on software prototyping, only one layer of the system is implemented in this form, typically the user interface, without the underlying logic.
Technically, a click dummy consists of three building blocks: the individual screens (usually called frames or boards in design tools), the clickable areas on these screens (hotspots) and the connections that determine where a click leads. In addition, there are transition animations, overlays for dialogues and menus, and defined starting points at which a flow begins.
What a click dummy can and cannot do
A click dummy answers questions about operation, not about technology. The following overview summarises the typical characteristics:
- Linked screens: every state of the interface is a separate, fully designed screen.
- Predefined paths: only the prepared click paths work. Everything else does not respond.
- Static content: names, prices, lists and search results are sample data that do not change.
- No input processing: forms usually do not accept real input; validation is simulated at most.
- No back end: there is no login, no storage and no connection to systems such as an ERP or shop.
- Quick to change: a screen can be rebuilt in minutes and a connection reset in seconds.
Click dummy, prototype, MVP and mockup compared
In everyday project work, the terms are often mixed up. The distinction is important, however, because it determines what an artefact can and cannot prove. A wireframe is the preliminary stage: a rough, usually greyscale layout of a single screen without design and without interaction.
| Artefact | Interaction | Logic and data | Main purpose | Reusable as a product |
|---|---|---|---|---|
| Mockup | None, static image | None | Agreeing on the visual design | No, serves as a design template |
| Click dummy | Predefined click paths between screens | None, only sample content | Testing flows and navigation | No, serves as a specification |
| Prototype (functional) | Partly real, often with code | Partly, e.g. simulated or local data | Checking technical feasibility or complex interactions | Rarely, usually throwaway code |
| MVP | Complete for the core scope | Real, with back end and data storage | Testing market acceptance with real users | Yes, is developed further |
Strictly speaking, the click dummy is a subtype of the prototype. When people in everyday language talk about a "prototype" as opposed to a click dummy, they usually mean a functional prototype with real code. A minimum viable product (MVP), on the other hand, is already a working product that real users use and that is developed further.
Low-fidelity and high-fidelity click dummies
Click dummies differ above all in their fidelity, i.e. in how close they are to the later product. In its article on low- and high-fidelity prototypes, the Nielsen Norman Group describes three dimensions: interactivity, visuals and content. A prototype can be worked out to different degrees in each dimension.
Low-fidelity click dummy
A low-fidelity click dummy links simple wireframes together. Colours, images and final texts are missing; placeholders replace content. It is quick to build and invites fundamental criticism because it is visibly unfinished. According to the Nielsen Norman Group, stakeholders are more willing to change the structure with such drafts. It is suitable for early questions: is the order of the steps right? Is a screen missing? Is the navigation logically structured?
High-fidelity click dummy
A high-fidelity click dummy looks like the finished app. It uses the final design, real texts, realistic sample data and transition animations. Test participants perceive it like a real product, which makes usability tests more meaningful. The effort is higher, and every design change has to be carried over into many screens. It is suitable for checking individual components, for approvals by decision-makers and as a hand-over to development.
What companies use a click dummy for
A click dummy is not an end in itself. It is always worthwhile when a decision is pending that is hard to make without a tangible picture of the solution. Four purposes are particularly common.
Usability testing before development
In a usability test, test participants carry out typical tasks in the click dummy, such as "Reorder this item" or "Report damage". The observers watch where they hesitate, take a wrong turn or give up. Because the click dummy has no logic, problems can be fixed directly in the design and checked again in the next round of testing. The comparison is simple: a changed connection in the design tool costs minutes, a changed flow in finished code often costs days.
A basis for decisions by stakeholders
Management, the business department and IT often have different pictures in their heads when "the new app" is mentioned. A click dummy makes these pictures comparable. Instead of discussing text descriptions, everyone involved clicks through the same flow. Unclear points in the scope, such as whether an approval step is needed, become visible before they tie up budget.
Presentation to investors and partners
In the early phases of a product, there is often no software yet. A high-fidelity click dummy shows investors, pilot customers or sales partners how the product is supposed to work. Transparency is important here: a click dummy proves the concept, not the technical feasibility. Anyone presenting it should make it clear that there is no working system behind it yet.
Annex to tenders and specifications
Specifications describe what a piece of software is supposed to do. However, texts leave a lot of room for interpretation. A click dummy as an annex makes requirements for the interface and flows more unambiguous. This allows providers to calculate more precisely and makes quotes easier to compare. The text remains binding: the specifications should state whether the click dummy counts as a binding requirement or as guidance.
Creating a click dummy: the process in four steps
In the common design tools, creation follows a similar pattern. What this looks like in a complete project, from the first sketch to the hand-over, is described in the article app design process: from wireframe to clickable prototype. For the click dummy itself, these four steps are decisive.
1. Select flows
No click dummy maps the entire product. Choose the two to five flows that matter most for the question at hand, such as registration, search and purchase or recording an order. Each flow gets a clear starting point and a clear goal. Anything outside these flows is not linked and is not covered in the test either.
2. Create and link screens
A separate screen is created for each step of a flow, including intermediate states such as "basket empty", "input error" or "success message". The hotspots are then connected to the target screens. In Figma, these connections are called prototype connections, in Penpot interactions. Each connection consists of a trigger, such as a click, and an action, such as switching to the next screen.
3. Add interactions and overlays
Details make a click dummy realistic: overlays for dialogues, dropdowns and notifications, transition animations between screens and fixed elements such as a navigation bar that stays in place when scrolling. The Figma documentation on prototyping describes triggers, actions and flow starting points in detail. Moderation is important: every additional animation costs maintenance effort when the design changes.
4. Test on the real device
A click dummy for a mobile app should be tested on a smartphone, not just on a desktop. Only there does it become clear whether buttons are large enough, whether texts remain legible and whether important elements can be reached with the thumb. The common tools offer share links or their own viewer apps for this. Click through all flows yourself at least once before presenting it to test participants or decision-makers, so that no connection leads nowhere.
Tools for click dummies: Figma, Figma Make, Penpot and ProtoPie
There are specialised tools for creating them. The choice depends on how complex the interactions are to be and what requirements exist for data storage and licensing.
- Figma (prototyping mode): the widespread standard in UI design. Frames are linked via connections, flows are given starting points and the presentation view plays the click dummy. For advanced cases, Figma offers variables, conditions and Smart Animate.
- Figma Make: an AI tool that generates interactive, high-fidelity prototypes from text input. After a beta phase from May 2025, it has been generally available since 24 July 2025. Unlike a classic click dummy, Figma Make generates code in the background.
- Penpot: an open-source design platform that can also be self-hosted. According to Penpot's help on prototyping, it supports triggers such as click, mouse enter or after delay, actions such as navigate to and open overlay, and several flows per page, each with its own share link.
- ProtoPie: a specialist tool for complex interactions. ProtoPie works with variables, logic and formulas, can integrate device sensors and import designs from Figma, Sketch or Adobe XD via plugins.
For most click dummies in a business context, the prototyping mode of a design tool is sufficient. Specialist tools such as ProtoPie are worthwhile when gestures, sensors or several networked devices are to be simulated. Penpot is interesting if design data should not be held by a US provider for reasons of data sovereignty.
Limits of a click dummy
A click dummy is a tool for clarifying operation and scope. It replaces neither development nor technical design. You should be aware of three limits before using it for decisions.
No code: a classic click dummy contains no program logic. Whether a function is technically feasible, whether an interface delivers the required data or whether a calculation step is correct cannot be checked with it. For that you need a technical prototype or a proof of concept.
Not reusable: a click dummy does not turn into an app. Development rebuilds the interface, even if design tools provide dimensions, colours and spacing for the hand-over. This also applies to AI-generated prototypes: their code is intended for demonstration and does not replace planned architecture, security and test coverage.
No statements on performance and data: a click dummy always loads instantly and always shows perfect sample data. It only represents loading times, empty states, very long names or thousands of entries in a list if they have been designed specifically. Nor does it make differences between a native app and a progressive web app (PWA) visible, for example in offline behaviour or device access.
Frequently asked questions about click dummies
What is the difference between a click dummy and a prototype?
A click dummy is a form of prototype that only maps the interface and connects screens via predefined click paths. In narrower usage, "prototype" often means a functional prototype that contains some real logic, code or data and can therefore also answer technical questions.
How long does it take to create a click dummy?
That depends on scope and fidelity. A low-fidelity click dummy for a single flow made from existing wireframes can often be linked in a few hours. A high-fidelity click dummy with a final design for several flows requires considerably more time, because the design has to be created first. Most of the effort goes into the design, not into the linking.
Can I test a click dummy with real users?
Yes, that is one of its main purposes. Test participants receive concrete tasks and carry them out in the click dummy, ideally on the target device. It is important to set only tasks that lie within the linked flows and to check all connections beforehand so that the test does not fail because of missing click paths.
Does a click dummy later become the finished app?
No. The click dummy serves as a template and specification for development, but its content is not transferred directly into the app. Development implements the interface and logic anew. Anyone who needs usable software with real data early on should plan an MVP instead.