Wireframe Specification Writer

A thorough wireframe spec that gives designers everything they need to start building without a single back-and-forth question.

Best For

•A product manager without wireframing skills writes this spec so a contract designer can start building low-fidelity screens same day.
•A UX designer joining mid-project uses it to document an existing undocumented screen before proposing changes.
•A founder building an MVP feeds the spec directly into a no-code or AI UI tool to generate a first-pass layout.

Prompt Template

Write a detailed wireframe specification for the [SCREEN_OR_FEATURE_NAME] screen of [PRODUCT_NAME]. This spec will be handed to a designer to create low-fidelity wireframes. Include: (1) Screen purpose, one sentence on what the user accomplishes on this screen, (2) Entry points, how does a user arrive at this screen? List all navigation paths, (3) Layout grid, specify columns, gutters, and breakpoints for [BREAKPOINTS, e.g., mobile 375px, tablet 768px, desktop 1440px], (4) Content hierarchy, list every content element on the screen in priority order (1 = most important), describe its type (heading, body text, image, CTA, form field, etc.) and rough position, (5) Interactive elements, for each button, link, or form element, specify: label, action on click/tap, and destination or outcome, (6) Edge cases and empty states, describe what the screen shows when: data is loading, there is no data, and an error occurs, (7) Annotations, flag any elements requiring specific UX rationale. User goal for this screen: [USER_GOAL].

Pro Tip

Write the content hierarchy as a strict numbered list, not bullet points, because the priority order is what actually drives layout decisions downstream.

Example Output

A sample of what this prompt produces once you fill in the placeholders.

Screen purpose: let a returning user reset a forgotten password in under 3 steps. Content hierarchy: 1) heading 'Reset your password,' 2) email input field, 3) 'Send reset link' CTA, 4) 'Back to login' text link. Empty state: if email isn't found, show inline error below the field rather than a blocking modal.