--- title: Prompt design — spécification route: /fr/resources/prompt-design-specification lang: fr part_of: Onirion version: "4.0" date: 2026-09-22 author: Alexis Boyer license: CC BY 4.0 one_line: "La spécification longue que la session PM écrit pour l'outil de design, en exigeant des flows de bout en bout." kind: prompt layers: summary: /fr/resources/prompt-design-specification complete_text: /fr/complete.md markdown: /fr/resources/prompt-design-specification.md --- *Le texte ci-dessous est celui du kit, en anglais.* # The design prompt — long specification **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Gate 3.** The specification the PM session writes for the design tool. It asks for end-to-end flows, not just the major screens. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ```text Design a full high-fidelity web application prototype for [PRODUCT NAME], [ONE-SENTENCE PRODUCT DESCRIPTION]. This is a real logged-in [B2B SaaS / internal operations / marketplace / admin] application, not a landing page. Start directly inside the product experience. Treat the attached PRD — whose first section is the strategic framing — together with the research notes, source documents and design-system references, as what decides. If a linked source is gated or unavailable, work from the pasted content and do not invent a product decision that is missing. Design end-to-end flows, not only the major screens. Every flow listed below must be walkable from its entry point to its final state, including the intermediate steps, the branches, the failures and the confirmations. ## Strategic context [Why this product exists, the business loop it serves, the constraints around it.] This product helps [PRIMARY USERS] answer: 1. [CORE USER QUESTION] 2. [CORE USER QUESTION] 3. [CORE USER QUESTION] The product should feel like [PRODUCT METAPHOR: an operations workbench, a daily work console]. Calm, precise, structured, auditable, built for repeated daily work. ## Product boundary This product is for: - [ROLE / USER GROUP] - [ROLE / USER GROUP] This product is not for: - [OUT-OF-SCOPE USER / TEAM] Do not design: - [OUT-OF-SCOPE WORKFLOW] - [OUT-OF-SCOPE SCREEN] - [INTERNAL-ONLY OR SENSITIVE SURFACE] If an out-of-scope workflow exists, represent it only as a safe status, a handoff or a request state inside this product. ## Users and roles - [ROLE]: [what they do, what they need, what they can see] - [ROLE]: [what they do, what they need, what they can see] - [READ-ONLY / ADMIN / SUPERVISOR ROLE]: [permissions and constraints] Show role-based differences wherever they materially change navigation, actions, data visibility, disabled states or empty states. ## Core product principles 1. Lead with action, not decorative analytics. 2. Make the primary workflow usable end to end. 3. Keep sensitive data role-gated and explain visibility limits clearly. 4. Prefer tables, queues, drawers, modals, tabs, filters and audit trails over marketing-style layouts. 5. Make every clickable surface imply a real behavior. 6. Do not expose internal operational complexity to users who should only see safe statuses. 7. Use realistic data density and realistic edge cases. ## Navigation and shell Use a real app shell: navigation appropriate to the roles, page header, account or organization context, notifications, language toggle where relevant, account menu, settings and administration in the right place. Primary navigation: 1. [MAIN AREA] 2. [MAIN AREA] 3. [MAIN AREA] Do not repeat the product name as a large brand row inside every page header. The shell should feel like a daily-use operational product. ## Visual direction Use [YOUR ORGANIZATION'S DESIGN SYSTEM OR REFERENCE PRODUCT]. Treat it as a constraint, not as inspiration. Use: dense operational layouts; near-white app surfaces; soft neutral background; subtle borders; compact spacing; strong readable typography; text near black; accent colors only where they carry meaning; functional status colors; status badges, segmented controls, tabs, drawers, modals, tables, filters and forms. Avoid: landing pages; hero sections; decorative gradients that are not an established pattern; oversized marketing cards; generic analytics dashboards disconnected from action; playful consumer UI; explanatory filler text inside the product UI; one-off components that do not look reusable. ## Core data concepts Represent these naturally in the UI, with their real relationships rather than disconnected cards: - [ENTITY] - [STATUS / STATE MODEL] - [DOCUMENT / REQUEST / CASE / INVOICE / REPORT] - [AUDIT EVENT] - [PERMISSION / VISIBILITY LEVEL] ## Required screens and flows Design a coherent multi-screen prototype. Include the ones this product actually has, each walkable end to end. 1. Authentication and entry: [OTP / email code / passwordless / SSO], loading, invalid code, resend, successful transition. 2. Workbench: what needs attention now — work queues, recent changes, next actions, role-specific content. 3. Primary object directory: dense list or table for [the main entity], with search, filters, counters, row status and next action, primary and secondary actions, empty state, bulk or import/export where relevant. 4. Primary creation or submission flow: a guided modal, drawer or multi-step flow, not one long undifferentiated form. Include validation, missing required fields, back and next, save and resume later, review and submit. 5. Detail workspace: header, status and key metadata, tabs or sections, related records, documents, thread or comments, activity timeline, contextual actions. 6. Requests and communication: list, categories, status and priority, creation flow, detail thread, attachments, linked object, action-required state, resolved state. 7. Documents and records: repository, detail or preview and download behavior, filters, missing-document state, replace or re-upload, access restrictions. 8. Finance, billing or reporting where relevant: overview by period, invoices or ledger, payment status, reconciliation, downloadable documents, exception workflow. 9. Settings and administration: organization settings, users and roles, role descriptions, invite and deactivate, security settings, read-only states for users without permission. ## Interaction states to include Empty; loading; validation errors; missing required fields; pending, approved, rejected, needs information, overdue, resolved; disabled actions with a stated reason; role-restricted content; notifications; audit timeline; download and export; confirmation modals; destructive-action confirmation; success and failure feedback; side panels and drawers; dropdowns and profile menus. ## Privacy, security and visibility rules Respect: - [RULE] - [RULE] Do not expose: - [SENSITIVE DATA] - [INTERNAL NOTES] - [RAW EVIDENCE] If sensitive data is needed to complete a workflow, show the approved role-gated version, a safe status, or a path to request it. ## Content and mock data Language: [French-first / English-first / bilingual]. Currency: [currency]. Organizations, people, domain vocabulary, dates and identifiers should look real. Avoid lorem ipsum. Write real product copy. ## Output expectations A polished full-product exploration, not a single screen. Prioritize clear navigation, complete product vision, realistic workflow depth, strong table and list design, reusable patterns, role and privacy logic, real operational actions, and the modals, drawers, dropdowns, tabs, empty and error states the flows need. Someone reading the result should understand what [PRODUCT NAME] becomes as a complete product, and be able to walk each main flow from end to end. ```