How would you architect interdependent filter variables in a complex dashboard?

WHAT THIS TESTS: The interviewer wants to see if you treat prototype state as a dependency graph rather than a collection of disconnected screens and overrides. At senior level they care about unidirectional data flow inside Figma, using variables as a real source of truth, and avoiding combinatorial explosion of frames. They are listening for whether you know how to use conditional prototyping to derive state instead of duplicating artboards.

A GOOD ANSWER COVERS: First, establish a single source of truth using Figma variables such as a string for status, a string for date range, and booleans for disabled states. Second, bind component properties to those variables so the UI updates automatically without manual overrides. Third, model the relationship as a directed acyclic graph where the status dropdown is upstream. Use an on-change interaction that sets the status variable, then chain a conditional check: if status equals Closed, set the date range variable to a valid default and set a boolean that disables invalid date options. Fourth, keep the chain unidirectional so the date picker never writes back to the status filter. Fifth, mention that the list itself can be filtered by showing or hiding layers based on the same variables, or by swapping variants on a component with bound properties.

COMMON WRONG ANSWERS: A red flag is suggesting duplicating frames for every combination of filter states instead of using variables and conditional logic. Another red flag is proposing interactions that directly manipulate component instances with overrides rather than updating variables, which breaks consistency across screens. A third is creating bidirectional variable updates where changing the date picker can alter the status, inviting prototype loops or dead ends. A fourth is ignoring Figma variables entirely and relying on the viewer to manually click through a predefined flow.

LIKELY FOLLOW-UPS: The interviewer may ask how you would add a third filter that depends on both status and date, or how you would handle a user manually selecting an invalid date after the status changes. They might ask how to keep the prototype performant when many variables change at once, or how you would hand off the variable schema to developers so it maps cleanly to component props or query parameters.

ONE CONCRETE EXAMPLE: Imagine a job dashboard where selecting Closed status should disable the Future date range. Create string variables status and dateRange and a boolean dateDisabled. The status dropdown has an on-change interaction that sets status to Closed. A chained conditional checks if status equals Closed; if true, it sets dateRange to All Time and sets dateDisabled to true. The date picker component binds its current option to dateRange and its disabled state to dateDisabled, so it updates automatically. The list below binds its visible items to a filtered set derived from the same status variable.