Variables and Logic
Variables store values that change during a prototype session — user name, selected plan, item count, toggle state. Conditional logic uses those values to control what the user sees and how the prototype responds. Together, they make prototypes behave like real applications without writing production code.
A prototype with variables can show a personalized welcome screen, adjust pricing based on a plan selection, and display different content depending on which path the user took earlier.
Why variables and logic make prototypes realistic
Static prototypes show one fixed path. Real applications adapt based on user input, account state, and previous actions. When you test a static prototype, you are testing whether users understand a predetermined flow. When you test a prototype with variables and logic, you are testing whether users can navigate the actual decision points they will encounter in production.
Variables also enable quantitative testing. Instead of asking "did the user understand the screen," you can measure "did the user select the right plan tier based on their stated needs." The prototype captures the variable values at each step, creating a data trail that informs product decisions.
Without variables, testing multi-path flows requires building separate prototype branches for each path, which is slow to create and difficult to maintain when the base screens change.
Adding variables and conditional logic
- Open the variables panel and create variables for each piece of dynamic data in your prototype. Choose the right type: text for names and labels, number for quantities and prices, boolean for toggles and flags.
- Set default values for each variable. These are the starting values when a test session begins. Choose defaults that represent the most common user scenario.
- Bind variables to display elements by inserting variable references in text fields, visibility conditions, or style properties. The syntax uses double curly braces like .
- Create update actions that change variable values in response to user interactions. A button tap can increment a counter, a dropdown selection can set a plan name, and a toggle can flip a boolean.
- Add conditional logic to control flow. In the trigger settings, add conditions like "if selectedPlan equals pro, navigate to pro-features-screen." Multiple conditions can be chained with AND/OR logic.
- Test variable flows by running the prototype and using the variable inspector to watch values change in real time. Verify that conditions fire correctly for all expected input combinations.
Logic and variable mistakes to avoid
- Using variables for values that never change. Static content should stay static. Variables add complexity; use them only when the value genuinely varies during a session.
- Creating too many variables without a naming convention. Projects with twenty or more variables become unmanageable without prefixes or grouping like user.name, cart.count, nav.currentTab.
- Writing conditions that reference variables not yet set. If a user can reach a conditional screen before the controlling variable has a value, the condition evaluates against the default, which may not be the intended behavior.
- Testing only the default variable values. Change variables manually in the inspector to verify that all paths work correctly with non-default inputs including edge cases like empty strings and zero values.
- Nesting conditions more than three levels deep. Deep nesting makes logic hard to debug and indicates the flow should be simplified or split into separate screens.
Measuring prototype fidelity
- Variable coverage: The percentage of dynamic elements in the real product that are replicated with variables in the prototype. Higher coverage means test results are more representative of real behavior.
- Path coverage: The percentage of conditional branches that have been tested with at least one participant. Untested paths may contain logic errors or confusing experiences.
- Data accuracy: Whether the variable values shown in the prototype match what the real application would display in the same scenario. Inaccurate data undermines test participant trust.
- Logic error rate: The number of broken or unexpected conditional paths discovered during internal review. Track this to measure whether prototype logic quality is improving over time.
When to add logic to your prototype
- When the feature you are testing has branching paths that depend on user input, like a multi-step form with conditional sections.
- When you need to simulate personalization, such as showing different content based on user role, plan tier, or account age.
- When testing error handling, where the prototype needs to respond differently to valid versus invalid inputs.
- When running quantitative tests where you need to track which choices users make and in what order, using variable logs as the data source.
Key concepts
- Variable: A named value that can change during a prototype session based on user input or conditions. Variables enable personalized, dynamic prototype experiences.
- Conditional logic: Rules that control prototype behavior based on variable values, user actions, or system state. Conditions determine which screens, states, or messages appear.
- Expression: A formula that combines variables, operators, and values to produce a result used in conditions or display.
FAQ
- What types of variables are supported? Text, number, boolean, and list types. Each type supports different operators in conditional expressions.
- Can variables persist across screens? Yes. Variables maintain their values as users navigate between screens, enabling multi-step flows that remember user choices.
- How do I debug conditional logic? Use the variable inspector in preview mode to see current values and which conditions are evaluating to true or false.
Next steps
Add one variable to your current prototype to replace a hardcoded value, then connect it to a conditional interaction. Test whether the variable-driven behavior makes the prototype feel more realistic to reviewers.