When you know what to fix but can only write a ticket

In Figma’s virtual museum example, feedback from synthetic personas surfaced a low-contrast date picker and inconspicuous CTAs. The team review then clarified requirements such as matching visible text with screen-reader labels and ensuring keyboard focus reaches the CTA. Even when the problem and direction are this clear, handing it off as a ticket puts implementation order at the mercy of the development backlog. Changes that look small are especially likely to slip behind feature work and incident response.

Figma’s published Workflow Lab reframes that wait. A designer finds shared components in an existing codebase, makes changes on a separate branch, and proposes a GitHub PR. Engineers retain review and merge authority. It turns a ticket asking for implementation into a reviewable code change.

That said, this should not be read as a real customer outcome. MOSF is a virtual museum created by Figma, and Workflow Lab is also a sample workflow. The scene in the original where work that would slip through a quarter ships in a day is narrative within the example, not a productivity metric with a disclosed sample and methodology.

Fix the shared component, not the color on one screen

The key takeaway from this sample is the scope of the fix, not its speed. The problematic date picker was a shared component reused across three places: exhibition pages, the event calendar, and the sign-up flow. Because the designer checked relationships in the current code, they could propose a change to the component itself rather than fix only one screen.

The accessibility intent the team reviewed was also specific: alignment between visible text and screen-reader labels, the date picker’s aria-label, focus order through the CTA, and an empty-state message announced when there are no search results. After the designer proposed the PR, an engineer reviewed, approved, and merged the code.

Your first target should be small and clearly bounded. Choose an item that can be resolved within an existing shared component, where reviewers can inspect changed files and affected screens in a narrow scope. Labels, contrast, focus order, and empty-state guidance are candidates. Problems requiring state-management or architectural redesign are beyond the scope shown by this sample.

This is a closed beta, not a standard GitHub push

Make in your local codebase, which clones an existing repository to create branches and PRs, is a free closed beta for a limited group of users. It requires a Figma account that received an approval email, a Mac running macOS 12 or later, the Figma Beta desktop app for Mac, a Figma organization with AI features enabled, and access to a Git repository. Joining the waitlist does not guarantee access.

Regular Figma Make Push to GitHub is not an alternative. It pushes output to a dedicated repository newly created by Make, so users cannot select an existing product repository or manage branches. The workflow that clones an existing repository and creates a working branch and PR belongs to the local-codebase beta.

CategoryRegular Push to GitHubLocal-codebase beta
Starting pointCode and a dedicated repository created by MakeAn existing Git repository you can access
Git workPushes to the default branch of the same repositoryRepository clone, local branches, pushes, and PRs
RequirementsPer-account availability requirements for regular MakeBeta requirements including an approved account, macOS 12 or later, and the Beta app for Mac

Your first PR starts by checking the operating system and approved account

The steps below do not guarantee that you can reproduce MOSF’s outcome. They are a first exercise, based on the current official documentation, for getting one small accessibility change to a PR. Run commands and environment variables differ by repository, so an engineer should participate in reviewing the setup.

  1. Confirm the account that received an approval email.
    The waitlist application confirmation and beta approval email in the official local-codebase guide are different. If you have not received an approval email, apply for the waitlist and wait for approval; the documentation cannot activate the feature directly.
  2. Check your macOS version and install the Figma Beta app.
    In About This Mac, first confirm that you have macOS 12 or later. If you are below 12, you do not meet the current official minimum requirement, so update to a supported OS version or prepare a supported Mac. Then download and install the macOS Beta installer from the official desktop-app guide. After opening the Beta app, sign in with the Figma account that received the approval email. The regular and Beta apps are separate installations, and installing the Beta app alone does not grant beta access.
  3. Check organization and repository access.
    Confirm that AI features are enabled in the relevant Figma organization, then open the GitHub repository URL in a browser to check your account’s access. For a GitHub organization-owned repository, regardless of whether it is public or private, confirm that an organization admin has installed the Figma GitHub app for that organization and included the repository you will use in its installation scope. You do not need separate terminal access or SSH keys; complete the GitHub authentication shown by Make during the first branch push or PR creation.
  4. Clone the repository in the Beta app.
    Create a Make file in Drafts and select Clone a repository. Specify an accessible GitHub HTTPS repository URL and a local save folder, then run Clone. If cloning fails, first check your repository access and whether the Figma GitHub app is connected to the correct organization.
  5. Prepare run settings and required credentials with an engineer.
    First create and switch to a new setup branch in Make, then confirm the current branch name. If prompted to add run settings, click Run. If a settings file was already created on main, move the change to a new setup branch while preserving it, then continue. Make generally auto-generates setup, install, dev, verify, and env files under .figma/make at the repository root. Confirm that each file fits the repository’s real runtime, and set the required PORT and FIGMA_MAKE_URL values in env.
    If the app requires API keys, sessions, or database credentials, first check the repository’s local-development documentation and existing secret-management practice. Do not commit secrets to the repository; pass them to the dev process using the team-approved method. If necessary values or how they are loaded are unclear, do not proceed until an engineer completes the setup.
  6. Check the preview and Git status.
    After dependency installation, development-server startup, and verify succeed, confirm that the real project screen loads in the Make preview. If another project appears or it does not run, inspect port conflicts, interactive start commands, missing environment variables, and the failed step in each configuration file. A background build may continue after the preview appears, so wait 30–60 seconds, then make sure Git changes do not contain large numbers of unexpected temporary or generated files. This is not a fixed performance promise; it is the wait range in the official troubleshooting guidance.
  7. Apply the validated settings to remote main.
    Commit the validated .figma/make changes on the setup branch, push that branch, and open a setup PR targeting main. An engineer reviews and merges the setup PR. If Make requests GitHub authentication during this process, complete authentication with that account. Once the remote update is complete, update local main to its latest state. The settings need to be on main so later branches and other users inherit the same runtime environment.
  8. Create an accessibility-fix branch from updated main.
    Create and switch to a separate working branch from the latest main. For the first exercise, limit yourself to one item that ends within a shared component and whose changed files and affected screens can be reviewed narrowly.
  9. Identify the actual screen to change, then send the sample prompt.
    Open the screen containing the date picker in the preview and note its exact path and element name. Replace the two bracketed placeholders below with those values. If there is no date picker, specify a small UI issue that actually exists and its path. This sentence is not a command whose results were verified in MOSF; it is a first-prompt example assembled by the editorial team from the official case’s review items.

Work on [actual screen path] in the preview, targeting [date picker name or location]. If you cannot find the specified element, do not guess and make changes; confirm its location. First check whether the element you find is a shared component reused on other screens. Check whether visible text matches screen-reader labels and whether keyboard focus reaches the CTA. Summarize the files to change and affected screens, then create a narrowly scoped fix on the current working branch.

  1. Check changed files and the actual preview.
    Review the current branch, generated local commits, and modified files, then open affected screens in the preview. If unrequested files changed or the change spread outside the shared component, narrow the scope before opening the PR.
  2. Push the working branch and open a PR.
    If GitHub authentication appears during the first branch push or PR creation, complete it. If authentication cannot be completed in Make because of a company-restricted auth browser or hardware key, check with the organization administrator for a supported authentication path.

The first success criterion is not automatic deployment. It is enough that the real repository app runs in preview, a separately scoped branch has a commit with the intended changes, and a GitHub PR is open for engineers to review the changed files, affected screens, and accessibility intent.

A PR is the starting point for accessibility validation

It has not been disclosed whether the MOSF sample passed real keyboard-only navigation, specific screen readers, or automated WCAG checks. Appropriate attributes in code or a synthetic persona finding a problem alone does not prove real usability.

Set merge criteria separately. After passing engineer code review and existing CI, operate the changed area using only a keyboard and read it with the screen reader your team supports. For a shared component, check representative usage screens as well.

The practical value of this approach is not that designers replace engineers. Designers propose small UI fixes with clear intent as executable changes, while engineers own the runtime environment, code structure, quality bar, and merge decision. If accessibility tickets routinely sit in your team’s backlog, try sending one small change to a PR within these boundaries before expanding permissions all at once.

If you want to dig deeper

Workflow Lab: Deploying Designs Directly with Figma Make explains the full narrative, including that MOSF is a virtual sample, the shared date picker, accessibility review items, and engineer approval and merging. figma.com

Make in your local codebase is the official starting document for approval requirements, supported repository scope, applying settings to main, the GitHub app, and first push and PR authentication. help.figma.com

Make in your local codebase: Setup, gotchas, and troubleshooting is useful when automatic configuration fails, or when the preview does not open correctly because of the development server, environment variables, ports, or a background build. help.figma.com