Getting Codex to produce a page that runs is only part of the job. Giving that page a clear visual focus, the right information density, and smooth interactions takes a more deliberate process.
Choose the visual direction first, have Codex implement it, and then complete the real user task in a browser.
If you do not have a design yet, start with @Product Design and compare three visual directions. If you already have Figma files and a component library, give Codex that design context. Both routes give implementation a clearer target.
1. Use Product Design to compare three directions
Product Design is a plugin from OpenAI for taking product ideas toward prototypes a team can review. It brings together briefing, visual exploration, flow audits, Image to Code, and design QA. You can start with a written requirement, screenshot, existing page, or design reference. See the official Product Design overview.
A useful part of this workflow is seeing several possible interfaces before implementation begins. In the plugin version reviewed for this guide, visual exploration without an existing target produces three separate options, waits for your selection, and then moves into implementation.
The point of choosing among three images is to compare ways of organizing the product, rather than the same page in three colors.
For an appointment-management interface, the directions might be:
- Calendar first: lead with the schedule for someone managing today's appointments.
- List first: lead with customers, statuses, and follow-ups for someone working through a queue.
- Action first: lead with pending confirmations, rescheduling requests, and conflicts.
This is an illustrative example, not a completed product test. Choose the structure that fits the user's daily work. Appearance matters, but so does being able to identify the next action immediately.
Try this prompt:
@Product Design
Design an appointment-management homepage for an independent service provider. The main tasks are reviewing today's appointments, confirming pending requests, and changing appointment times.
Show me three separate visual directions with meaningful differences in information hierarchy and layout, not just color. Use the same example content, keep the interface compact, and consider mobile use. Wait for me to select a direction before writing code.
Once you choose, make feedback specific: “Keep the second image's list structure, move pending confirmations to the top, and reduce the space used by the statistics.” That creates a clearer target than “make it more polished.”
2. Use Image to Code to build the selected interface
A design image puts layout, typography, spacing, color, and emphasis in one place where you can compare and revise them. Once selected, it gives Codex a visual reference to work against.
Clarify the design, then express it in code. That is the reason to use an image-to-code workflow. Product Design includes Image to Code, but that does not establish that generated images always look better than generated code, or that every product should start with an image.
If a project already has established pages and components, extending them may be the better route. When exploring a new interface, an image can help reduce the back-and-forth of writing code while still guessing at the visual direction.
For implementation, use a prompt like this:
Implement the appointment-management page from the design image I selected. Preserve its information hierarchy, layout, typography, spacing, and component proportions. Reuse existing project components.
Build the lists, buttons, inputs, and navigation as real frontend elements. Implement confirmation, rescheduling, and cancellation, along with empty, loading, submission-error, and success states.
Run the page in desktop and mobile browsers, compare it with the reference, and actually complete an appointment-rescheduling flow. Clearly distinguish example data from real integrations.
A single image cannot specify every interaction. Where does a user choose the new time? Does a failed submission preserve their input? Where does keyboard focus return after a dialog closes? Add those requirements to the implementation task.
Review both screenshots and the working page. Matching the reference image completes only part of the work.
3. Use Figma to Code when you have a design system
If your team already maintains pages, components, and design variables in Figma, give that context directly to Codex.
In February 2026, OpenAI and Figma announced a deeper integration through Figma MCP. Teams can bring designs into Codex for implementation and turn UI from code into editable Figma designs for further exploration. This supports a two-way workflow between design and implementation. See OpenAI's Figma partnership announcement.
Compared with a screenshot alone, Figma can supply structured context about components, variables, and layout. Its current tools also support creating or updating native canvas content, including frames, components, variables, and Auto Layout; Codex is listed as a supported client. Writing requires a Full seat and edit permission for the target file. A read-only connection is not an editing connection. See the Figma MCP overview and canvas-writing requirements.
The design file still needs to communicate intent. Use components for repeated elements, variables for styles, meaningful layer names, Auto Layout, and annotations for important behavior. If production components already exist, Code Connect can map the design to those implementations. These are also Figma's recommendations for better code output.
Work on one page or flow at a time. Include a link to the specific Figma node, the relevant code location, and the required interactions:
Implement the appointment-details page from this Figma frame: [node link].
First read its design context and screenshot, inspect the existing project components, and reuse available design variables and component mappings.
Keep the information order and implement confirmation, rescheduling, and cancellation. Include loading, error, and success states. Use the project's existing stack, then check mobile layout, keyboard use, and state preservation when navigating back in the browser.
If the design is unfinished, a connection with write access can first add a page or state in Figma. Review that work before asking Codex to implement it. The team can keep discussing the design in its existing canvas.
4. Make interaction checks part of the task
Whichever route you choose, finish by doing what the user came to do.
For appointment management, open an appointment, change its time, submit, and confirm that the list shows the update. Then try a failure case: is the input preserved, is the error understandable, and can the user recover?
Check for mobile overflow, keyboard access to the main controls, and clear loading and success feedback. When something fails, give Codex a specific correction: “Keep the selected date after a failed submission, place the error near the confirmation button, and allow a retry.”
Start with Product Design's three images when you need a direction. Use Figma's components and design context when you already have one. Keep each iteration focused on a page or flow, then run it, capture it, and use it before moving on.
If you are still deciding what belongs in the first version, use our guide to building an app prototype with AI to narrow the scope before starting visual design and frontend implementation.
Product capabilities checked October 10, 2026. The three-option workflow was checked against Product Design 0.1.56. Plugin availability depends on your plan and workspace settings. The appointment examples and prompts are instructional, not a report of measured performance.