Layer States
Layer states let you define multiple configurations of the same screen without creating separate copies. A single screen can have a default state, a loading state, an error state, and a success state, each showing different elements in different positions. Transitions between states create the illusion of a dynamic, multi-step interface.
This approach is faster than duplicating screens for every variation and easier to maintain when the base layout changes.
Understanding layer states in prototypes
Every element on a screen exists as a layer. Each layer has properties like visibility, position, opacity, and size. A layer state saves a specific combination of these properties. When the prototype transitions to a different state, the layers animate to their new configuration.
The most common use case is showing and hiding elements. A form screen might have a "default" state showing the form fields, a "submitting" state that shows a spinner and disables the button, and a "success" state that shows a confirmation message. All three states exist on the same screen.
Layer states also handle layout changes. A card component can have a "collapsed" state showing a summary and an "expanded" state showing full details. The transition between them can include height animation, content fade-in, and icon rotation.
Working with layer states
- Select the screen where you want to add states. In the states panel (bottom bar), click "Add State" and name it descriptively. Names like "form-valid" and "form-error" are better than "state-2".
- With the new state selected, adjust layer properties to match the desired configuration. Hide layers by setting visibility to off, move layers by dragging or entering coordinates, and change opacity or size as needed.
- Set transitions between states by selecting a trigger (like a button tap) and choosing the target state. Configure transition duration and easing in the animation settings.
- Preview the transitions in prototype mode to verify they feel natural. Adjust timing and easing until the interaction matches real application behavior.
- Test all state paths end-to-end. Verify that every state is reachable, every transition works in both directions, and no layers are accidentally visible or hidden in the wrong state.
- Use the state overview panel to see a grid of all states side by side. This catches visual inconsistencies faster than clicking through each state individually.
Layer state pitfalls
- Creating too many states on a single screen. Beyond eight to ten states, the screen becomes difficult to manage. Split complex flows into multiple screens connected by navigation.
- Forgetting to set properties for new layers in existing states. When you add a layer, it inherits the current state's properties but may not have correct properties in other states. Check every state after adding new elements.
- Using identical transition timing for all state changes. Fast micro-interactions like button state changes need shorter durations than larger layout shifts. Match timing to the visual distance of the change.
- Not naming states descriptively. State names appear in triggers and conditions throughout the prototype. Generic names force you to click through states to remember what each one looks like.
- Skipping the preview step after making changes. A state that looks correct in the editor may feel wrong in motion because the transition easing or duration creates jarring movement.
Tracking prototype complexity metrics
- States per screen: The average number of layer states across all screens. Keep this under six for maintainability. Screens with more states are candidates for splitting.
- Orphan state rate: The percentage of states that are defined but never targeted by any trigger. Orphan states indicate dead paths or incomplete wiring.
- Transition coverage: The percentage of state transitions that have been tested in prototype preview. Aim for one hundred percent before sharing with stakeholders.
- State reachability: Whether every state can be reached from the initial state through some sequence of user actions. Unreachable states waste effort and confuse reviewers.
When layer states are the right approach
- When a screen has two to six visual variations that share most of their layout, making full screen duplication wasteful and hard to maintain.
- When you need to prototype micro-interactions like toggles, accordions, dropdown menus, or modal overlays that appear and disappear on the same screen.
- When testing loading and error states for asynchronous operations like form submissions, data fetches, or file uploads.
- When building a component that needs internal state management, like a multi-step wizard, a tab bar, or a card with expand/collapse behavior.
Key concepts
- Layer state: A saved configuration of layer visibility, position, and properties that can be toggled during prototype interactions. States enable multi-step flows without duplicating screens.
- State transition: The change from one layer state to another, triggered by user actions or conditions. Transitions can include animations, delays, and conditional logic.
- Default state: The initial configuration of layers when a screen first loads. All other states are defined relative to this baseline.
FAQ
- How many states can a single layer have? There is no hard limit, but keep states under ten per layer for maintainability. Complex multi-state interactions are better handled with separate screens.
- Can layer states be triggered by variables? Yes. Conditions based on variable values can trigger state changes, enabling personalized prototype experiences.
- What happens if two state transitions conflict? The most recently triggered transition takes priority. Design your state logic to avoid conflicting triggers where possible.
Next steps
Create a layer state for the most common interaction in your prototype, such as a button hover or a panel open/close toggle. Test the state transition with a colleague to confirm the behavior is clear and responsive.