Custom GPT: Turn a Feature Spec into an On-Brand Screen Brief

What This Builds

A Custom GPT trained on your design system, voice guidelines, and past screen briefs that turns a raw product spec (a PRD paragraph, a Jira ticket, a Slack thread) into a structured screen brief: which components to use, what states the screen needs, what copy tone applies, and open questions for the team. It does not generate final pixels. It generates the brief you would otherwise write by hand before opening Figma.

Prerequisites

• Plus subscription at $20/month, required to build and use Custom GPTs
• Your design system documentation (component list, spacing rules, voice and tone guide) as PDF or text files
• 3-5 examples of past screen briefs you've written, to use as style reference
• Total ongoing cost: $20/month a month, no separate fee for the Custom GPT itself

The Concept

Think of this Custom GPT as a design-ops assistant who has read your whole design system and every brief you've ever written, and never forgets any of it. You hand it a rough spec, the kind a product manager drops in a ticket, and it hands back a brief written in your team's format, using the correct component names, before you've opened a design file.

Build It Step by Step

Part 1: Gather Your Reference Materials

1. Export or collect your design system documentation: component names and when to use them, spacing and grid rules, accessibility minimums, and your voice and tone guide.
2. Pull 3-5 past screen briefs you consider good examples, ideally covering different feature types (a form, a dashboard view, an empty state).
3. Save everything as PDF or plain text. Keep the total under roughly 15-20 pages so the GPT can search all of it reliably.

Part 2: Build the Custom GPT

1. In ChatGPT, click your name or icon, choose My GPTs, then Create a GPT.
2. Use the Configure tab (not the conversational builder) for full control over the setup.
3. Name it something specific to your team, for example "[Product Name] Screen Brief Assistant," not a generic name.
4. In Instructions, paste a system prompt like this:

You are a screen-brief assistant for a UX design team working on [product name]. When given a raw feature spec (a PRD excerpt, ticket, or meeting notes), produce a structured screen brief with these sections:

1. FEATURE SUMMARY (2-3 sentences, what the user is trying to do)
2. SCREEN STATES NEEDED (list: default, loading, empty, error, success, as applicable)
3. COMPONENTS TO USE (reference only components in the uploaded design system, name them exactly as documented)
4. COPY TONE NOTES (reference the uploaded voice guide, flag any copy that needs legal or compliance review)
5. OPEN QUESTIONS (anything the spec doesn't answer that the designer needs from product or engineering before starting)

Only reference components and terminology from the uploaded design system files. If a spec calls for something not in the design system, say so explicitly instead of inventing a component name.

1. Under Knowledge, upload your design system files and the sample briefs. Cap uploads at 5 files, more than that and retrieval quality drops.
2. Leave Capabilities like web browsing off unless your specs reference live URLs.
3. Set visibility to Only me unless you want teammates using the same GPT, in which case choose Anyone with the link and share it internally.
4. Click Create.

Part 3: Test and Refine

1. Paste in a real spec from a current or recently completed project and check the output against the design system and your own judgment.
2. If it invents a component name not in your system, tighten the instruction: "If unsure whether a component exists, say 'not in current design system' rather than guessing."
3. If the copy tone notes feel generic, add two or three example phrases from your actual voice guide directly into the instructions, not just the uploaded file, since instructions get weighted more heavily than knowledge files.

Real Example: Notification Settings Feature

Setup: A UX designer at a project-management software company built a Custom GPT loaded with the company's 40-component design system and eight past screen briefs.

Input: A three-paragraph Jira ticket describing a new notification preferences screen, written by a product manager with no UI detail.

Output: The GPT returned a brief listing four screen states (default, empty for new users, error for failed save, success confirmation), named the exact toggle and section components to use from the design system, flagged that the "quiet hours" copy needed legal review since it referenced time zones, and raised an open question about whether the feature needed a mobile variant.

Time saved: Writing a brief like this from scratch, including checking the design system for the right component names, usually takes 30-45 minutes. The GPT produced a first draft in under a minute, leaving 10-15 minutes of review and adjustment.

What to Do When It Breaks

• GPT invents a component that doesn't exist → Add an explicit instruction to say "not in current design system" when uncertain, and re-upload your component list if it's out of date.
• Output ignores your voice guide → Voice and tone examples work better pasted directly into the Instructions field than buried in an uploaded PDF. Move a few key example phrases into the instructions themselves.
• Brief format drifts over time → Re-paste your five example briefs periodically; Knowledge retrieval can weight recently referenced content differently as your file set grows.
• Teammates get inconsistent results from the same GPT → Check everyone is using the same version. A GPT edited after sharing does update for everyone automatically, but a teammate's browser cache of an old conversation can look stale.

Variations

• Simpler version: Skip the Custom GPT and paste the same system instructions directly into a regular ChatGPT conversation along with your design system as an attached file each time. Slower per use, no setup required.
• Extended version: Add a second Custom GPT, or a second instruction mode, that takes the finished brief and drafts the actual UX copy for each screen state, so the handoff from brief to first-draft copy happens in the same tool.

What to Do Next

• This week: Run three real specs through the GPT and compare against briefs you'd write manually.
• This month: Share the GPT with your team and standardize on it for a full project cycle, refining the instructions based on where it consistently gets things wrong.
• Advanced: Pair this with the chained research-to-brief workflow so research findings feed the spec that feeds this GPT, connecting research straight through to a build-ready brief.

Advanced guide for UX designer professionals. These techniques use more sophisticated AI features that may require paid subscriptions.