Product design / Discovery to play
Playfold
Creative direction for Playfold: social posts become characters, worlds, and playable stories.
- My role
- Founder & Creative Director — product direction, interaction design, visual system, prototyping, and engineering of the existing product.
- Product
- Wizzo Labs
- Period
- February 2026 - Present
- Resources
- Case study + two guides
The Playfold experience
01 / 13Homepage: source-to-game introduction
The existing homepage connects Playfold’s proposition, a source post, an interpretation and a public game. The full native desktop and mobile pages continue through examples, product explanation, support and footer.
Product overview
From a source post to something playable.
I own Playfold’s product direction, interaction design, visual system and engineering. The homepage makes the source-to-game relationship concrete before asking someone to explore or create. Its current presentation combines a source, an interpretation and a public game, then continues through explanation, examples, a product tour and support.
Make the invitation concrete
The source and game remain visibly related. Distinct Create and Discover actions give the introduction a useful next step.
Homepage: how a source becomes play
The homepage’s lower explanation makes the source-to-game sequence visible before the product tour. It connects source selection, interpretation, game construction, browser play and supported follow-on actions.
The main UI represents the existing product. Public examples preserve observed game identities and artwork; counts are a frozen reference, not impact evidence. Signal Range is a separate simulated private-result exploration.
Explore the homepage and public browsing pathCatalog and discovery
Give the catalog more than one way in.
Discover lives at /games. I use wide cards for the latest refolds, a popular shelf and a denser browse grid. Artwork invites exploration; titles and separate creator/source labels make the choice understandable. Search provides a direct route to a known game without changing its identity.
Preserve the browsing context
The connected AETHERSEED example returns to the catalog or its search query through browser-style Back. The product’s Back to Discover control intentionally opens the unfiltered catalog.
Discover: latest refolds, popular shelf and public grid
The current catalog uses wide latest-refold cards, a popular shelf and a browse grid, with search and separate creator/source attribution. AETHERSEED is the connected public walkthrough example.
Public game and focused play
Keep context beside the game.
AETHERSEED carries its title, artwork, objective, creator and source from discovery into the public game page. Focused play removes the app rail, while instructions and the game’s own controls remain close to the viewport. On mobile, the page stacks those relationships and keeps lower utility groups reachable by scrolling.
Keep the selected game
Poster, instructions, play and restart belong to the same AETHERSEED example. Figma changes platform states; the captured game scene does not execute the runtime.
Reflect actual capabilities
Public-game utility groups are represented where the inspected product provides them. The walkthrough does not submit Save, Share, Tune, Refold or score activity.
AETHERSEED: public game context and focused play
The public game page keeps artwork, objective, creator and source beside Play, with further context and utilities below. Its focused shell removes the app rail; the separate prototype bar models browser-style return.
Responsive product UI
Keep mobile play connected.
The mobile app uses a compact header and bottom navigation for browsing. The public game page replaces those destinations with its focused header, preserving the selected game while stacking its objective, source and utility groups. I keep the lower content scrollable rather than squeezing every action into the opening viewport.
Mobile AETHERSEED: game, source and scrollable controls
The native mobile public-game page preserves AETHERSEED’s identity while stacking game and source context. Lower utility groups remain reachable by scrolling; the game scene is a capture rather than an executing Figma runtime.
Leaderboard
Explain what the ranking measures.
The leaderboard ranks games. Season uses total verified score, with best run and scored plays resolving ties. All time uses shares, then plays. Podium cards introduce the leaders before compact rows continue the list; the alternate and unavailable states retain the mode context.
Preserve the existing return behavior
The inspected product resets All time to Season after leaving and returning. The prototype records that limitation instead of implying that period state persists.
Leaderboard: verified Season game rankings
Season ranks games by total verified score, then best run and scored plays. The system also represents All time shares with plays as the tie-break, plus unavailable data; the shown dataset is illustrative.
Source and intent
How does a post become a game without losing its context?
The current private creator accepts the signed-in person’s own X post with text and a static image. I use a separate illustrative scenario to examine the saved result: Alex Rivera selects Image 1 from a source about unstable signal beacons, and the game is Signal Range. Sam Chen is the illustrative player. Keeping one source and game lets me compare state and recovery consequences.
Preserve two relationships
Game by and From a post by remain separate labels even when Alex fills both roles. Attribution identifies origin; it does not grant permission to redistribute source material.
Keep the input concrete
Alex selects Image 1 from the source post. This creator flow does not accept a blank game prompt, video or animated source.
Creator source: owned post and selected static image
The disabled creator baseline retains its actual legacy navigation, owned-post field, primary-image selector and attempt history region. This representative account state does not enable creation or expose private production history.
Private creation and recovery
What has actually happened when creation finishes?
In the inspected application, Create and save privately moves through Checking source, Interpreting and Building and saving before Ready — saved privately confirms the retained result. A generated candidate is not yet a playable saved game, and private saving does not publish it. The application can reopen or rebuild retained work without another interpretation. The selected prototype demonstrates reopening and a separate recovery path; the saved receipt needs no second Save step.
Recovery keeps the attempt
Recover saved work — no new interpretation may reuse a valid saved specification. It can also be unavailable; it does not promise an automatic retry.
Cancellation can take time
Cancel remaining creation requests a stop. A result already in flight may still arrive, so cancellation pending must not promise that nothing was created.
Creator result: Signal Range saved privately
The proposed inline result preserves the source excerpt and selected Image 1 beside a private-save receipt. Play and Open private library are grouped with that result; reopening does not introduce another Save step.
New creation is disabled in the inspected product. The prototype simulates the gated creation and persistence sequence. Public release remains a separate owner-only review and authorization process.
Explore recovery from the same saved attemptPrivate-result exploration
Where should the result explain what to do next?
I compare two approaches to the same private Signal Range result. A keeps a preserved source excerpt and Image 1 beside the saved receipt. B gives that result a dedicated page with its own source summary. Play saved game and Open private library stay with the result they operate on. Both return to the selected alternative after reopening, and read-only source inspection returns to the same saved game.
A / Inline outcome receipt
Keeps the source, private-access explanation and result actions together. Its tradeoff is competition for space on a long page.
B / Dedicated result page
Separates the result and provides more room for play. Reopening and source inspection must preserve the B context instead of silently returning to A.
Compare the consequential tasks
Can someone explain private visibility, reopen without creating again, recover without a new interpretation and find actions on a narrow screen?
Private-result alternatives: inline receipt and dedicated page
The native sketches compare the same Signal Range private result and preserved source. I recommend the inline receipt for design review; both alternatives keep their branch on reopen and use read-only source inspection.
I recommend Alternative A for design review. It is not implemented or evaluated through participant research. Play saved game is proposed navigation within this refinement; recovery remains a separate path.
Play the preferred inline-result proposalPlayer and responsive behavior
Which controls belong around the game?
Sam opens Signal Range from a simulated discovery card, checks its source and instructions, then plays toward Clear the signal targets. The example uses three targets and a maximum of three hits. Movement, Fire and Restart belong to this runtime. This focused exploration tests access to controls below the viewport; the public-product designs above retain the full app and focused-game shells.
Expose supported controls
WASD or arrows move; Space or Enter fires. Touch uses a movement pad and Fire. This retained-runtime example has no Tune, Refold, challenge, score sharing, sound or haptic settings.
Make the return predictable
Restart resets the run without changing its source. Returning to discovery preserves the same Signal Range identity.
Desktop player: Signal Range context and controls
Sam Chen’s illustrative Signal Range journey separates runtime instructions, restart and return from prototype outcome controls. This focused exploration is simulated and remains separate from the existing public catalog.
Mobile player scrolled to movement, Fire and Restart
The actual presentation is scrolled to Signal Range’s controls below the viewport. Movement, Fire, Restart and return remain accessible; Figma navigates simulated outcomes and does not execute the game engine.
Signal Range is a safe local fixture, not an existing public catalog listing. The published context and play transitions are simulated. A local gameplay capture represents the viewport; its source-media texture has a recorded rendering limitation, so the source illustration is shown separately. The prototype does not run the game engine.
Open the mobile player prototypeReusable visual system
Can shared components keep the flow consistent?
I extend the existing system across marketing navigation, the desktop rail, mobile destinations, catalog cards, focused-game patterns and ranked-game podiums and rows. Dark surfaces, blue play actions, pink source context and violet Refold roles keep their meanings. The original gamepad identity stays intact. Corrected Action variants separate hierarchy from state and preserve label overrides and a stable 50-pixel height.
Document the source mapping
The design roles map to the product’s adaptive CSS. The existing creator surface’s slate/cyan variation remains documented rather than presented as already unified.
Keep type practical
Roboto is the verified Figma working face and is already in the production fallback stack. The application keeps its platform system-font configuration.
Shared public-game cards across responsive densities
The editable game-card family preserves artwork, title, genre and creator/source attribution across shelf, wide-card and marketing treatments. Navigation, action states, outcomes and ranking families extend the same product system.
Evaluation priorities
Test comprehension and control next.
I plan task-based evaluation around finding a public game, understanding its controls, interpreting rankings and returning to the right context. Creator tasks ask people to explain private access, reopen without creating again and distinguish recovery from a new interpretation. AI assistance supports source review, alternatives, critique and consistency checks. Prototype verification does not establish participant findings, adoption or business impact.
Understand the consequence
Ask for an explanation of private saving and cancellation before the participant takes an action.
Recover independently
Observe whether the participant returns to the saved attempt, finds recovery and understands when a valid specification is unavailable.
Reach the controls
Use the actual scrolled mobile state to examine whether movement, Fire, Restart and return actions are discoverable.
Working Figma and FigJam sources may require sign-in. The public images and downloadable PDFs carry the design narrative without changing workspace sharing.
Open the editable case study and guidelinesTake a closer look
Case study and design guides
Download the complete design narrative, identity guidance and reusable system specifications.
Tools
Tools and implementation
Continue the evidence trail
From proof to role fit
Compare Playfold with adjacent systems, or carry its reviewed capabilities into an Adaptive Focus brief.