How would you prototype a shared currently playing state in Figma?
This tests global state via Figma variables. Use one string variable for the active track; bind list and miniplayer to it via component properties; wire taps to update the variable. Avoid duplicating state per frame or faking persistence with overlays.
What's really being asked
This question probes whether you understand Figma variables and advanced prototyping as a reactive state layer rather than just a styling convenience. Seniors are expected to architect prototypes that behave like production apps, which means avoiding duplication and keeping a single source of truth for data that spans multiple views or components.
A GOOD ANSWER COVERS four things in order. First, variable choice: use a string variable for the currently playing track ID rather than a boolean, because a boolean cannot distinguish between track A and track B. Second, component binding: turn the track list row and the mini-player into interactive components whose variant states or layer visibility are driven by that string variable through conditional interactions. Third, interaction wiring: set the track list row so that tapping it updates the global string variable to its own track ID, and set the mini-player play-pause button to toggle a separate boolean if needed, while keeping the track identity in the shared string. Fourth, persistence: place the mini-player as a persistent component on a parent frame or use it across multiple frames so the variable binding remains alive during navigation, ensuring the player bar does not reset when the user scrolls or changes screens.
The mistakes people make
Duplicating state by creating one boolean variable per frame for isPlaying, which forces manual maintenance and breaks sync. Using overlay transitions to simulate the mini-player appearing on every screen, which destroys context and makes seek or pause interactions impossible across views. Proposing local component variables without explaining how they propagate upward, since local variables inside a track row cannot communicate with a mini-player in another frame unless bound to a shared collection. Suggesting auto-layout or simple component variants alone without mentioning variable-driven conditional logic.
What usually comes next
How would you handle a queue or playlist order? Would you use a number variable for progress or a separate string for album art? How do you prevent every track row from showing the active state at once if they all read the same variable? The interviewer may also ask how you would structure this at scale with multiple collections or modes.
A concrete example
Imagine a library screen with ten track rows. Each row component has a variant property called Active State that is bound to the global variable CurrentTrackID. When CurrentTrackID equals the row's unique track slug, the row switches to the active variant with a highlight and a pause icon. The mini-player at the bottom reads the same CurrentTrackID to display the matching album cover and title. Tapping a different row updates CurrentTrackID, so the previously active row reverts to default and the mini-player swaps artwork instantly, all without leaving the frame.
Interview question
When prototyping a music app with a track list and a persistent mini-player across multiple screens, which approach keeps the currently playing state synchronized without manual maintenance?
- a.Create a boolean variable named isPlaying on every screen frame and toggle it when a track is tapped, duplicating the mini-player on each frame to match.
- b.Rely on local variables inside each track row component to remember selection and propagate the state upward through nested component variants.
- c.Store the active track ID in a global string variable and bind both the track list rows and the persistent mini-player to it via conditional interactions.Correct
- d.Use overlay transitions to display the mini-player on every screen and manually reset the track list highlight after each navigation.
Why? this is the answer
A global string variable acts as a single source of truth that both the track list and mini-player can read reactively across frames. Relying on local variables inside rows is tempting but wrong because local component variables cannot communicate with elements in other frames unless bound to a shared collection.
Just read this? Test yourself on what you have been reading.
- #figma
- #prototyping
- #interactive-components
- #state-management
- #design-systems
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on figma — each one lists the topics its interview covers.
See open roles