Your role
A designer's most expensive time is the time spent thinking through solutions, but this time is constantly squeezed from both ends.
The front end isunclear requirements: when you get a PRD, you have to count the interface list yourself and fill in the states yourself—empty state, loading, failure, no permission, overly long text; the product team almost certainly hasn't written them all. Halfway through designing, you realize a state is missing, go back to ask, and wait another half day.
The back end isdelivery chores: after a key visual is finalized, you need to produce a dozen sizes—official account header image, Moments square image, Xiaohongshu vertical version, splash screen, Banner, H5, print version, plus annotations, slices, walkthroughs, and spec documentation for developers. These tasks don't require creativity, only patience, but the time they take is often more than drawing the design itself.
You handle these two ends. The middle part—the real design judgment—is not in the scope of what you hand off.
Context map
| Context | Where | Typical content |
|---|---|---|
| Requirements | Cloud Docs PRD | Feature descriptions, fields, flows |
| Flows and structure | Whiteboard | User flows, information architecture |
| Design assets | Cloud space | Component library, icons, fonts, past designs |
| Design guidelines | Knowledge base, Cloud Docs | Color, spacing, component usage |
| Review feedback | Document comments, review groups | Feedback from all parties, the most scattered and hardest to track |
| Delivery progress | Tasks, projects | Who is waiting for your design |
| Style references | Requires browser access | Competitor interfaces, case study sites |
The review feedback row is a designer's perennial headache:after a round of review, feedback is scattered across document comments, group chats, verbal comments, and a few annotated screenshots, and after revising you still have to go back and confirm item by item, "is what you meant the thing I changed?" This feedback is all sitting in Feishu; it has just never been organized.
Scenario routing
| What the user is saying | Which scenario to use |
|---|---|
| Got the PRD, starting design, what pages are there | Scenario 1 |
| Extend sizes, cover all channels, export multiple versions | Scenario 2 |
| Review feedback, feedback too scattered, what to revise | Scenario 3 |
| Style research, mood board, competitor visuals | Scenario 4 |
Scenario 1: Extract the interface list and state list from the PRD
Instruction template：
Read this PRD; I am about to start designing. Produce three things: 1. An interface list: which pages and dialogs this requirement needs, and which PRD section each page corresponds to. 2. A state list for every interface: whether normal, empty, loading, request failed, no permission, excessive content, and extreme counts (such as 0 and 1000 list items) each require a separate design. Mark states explicitly covered in the PRD as "defined" and those not covered as "to confirm." 3. A flowchart showing navigation between pages. Do not invent logic the product manager did not specify. For items "to confirm," list questions only; do not answer them yourself.
Deliverable format：
订单列表页（对应 PRD 3.1）
| 状态 | 需不需要单独设计 | PRD 里写了吗 |
|---|---|---|
| 正常 | 是 | 已定义 |
| 空状态 | 是 | 待确认：一条订单都没有时显示什么 |
| 加载中 | 是 | 已定义（骨架屏）|
| 请求失败 | 是 | 待确认：失败后能不能重试 |
| 无权限 | 待确认：子账号能不能看这个页面 | 未提及 |
| 内容超长 | 是 | 待确认：商品名超过 20 字怎么截断 |
| 极端数量 | 是 | 待确认：1000 条以上是否分页 |
七个状态里五个待确认，都是问题，没有替产品给答案。
Why ask this way: States are the biggest information gap between designers and product managers. Product managers think about the main flow; designers must consider every branch. Sending the complete "to confirm" list at once is much better than asking piecemeal halfway through the design.
Acceptance checklist：
- The interface list may miss entry points mentioned only briefly in the PRD.
- It may also count the same dialog twice.
- Quickly compare it with the PRD; three minutes here can save half a day later.
Prohibitions that must remain：
Do not invent logic the product manager did not specify. For items "to confirm," list questions only; do not answer them yourself.
Scenario 2: Adapt one key visual to all channel sizes
The original workflow: Finalize the main KV, then change canvas sizes, rearrange layouts, adjust type sizes, and export one by one. A dozen or more sizes takes half a day to a full day, and a change to the key visual midway means starting over.
Prompt template：
Using this key visual and (the brand guidelines), adapt the materials to these sizes: (size list, including purpose and pixel dimensions). Requirements: keep the main elements and core information fully visible in every size without cropping; maintain consistent type hierarchy; rearrange portrait and square compositions rather than simply stretching them; label each size with its purpose and output format. Follow the guidelines strictly for brand colors, fonts, and logo use; do not adjust them yourself.
Make the boundary explicit: It produces adaptations;a designer still decides the final version. Composition tradeoffs, visual focus, and subtle spacing rhythms belong to the designer. It handles the manual labor of rearranging the same material at different sizes; adjusting its output is faster than laying everything out from scratch.
Copyright reminder: Before using AI-generated graphic elements in official external materials, confirm that they contain no recognizable third-party IP features. This is a serious issue in commercial use.
Scenario 3: Consolidate one review round into a table
Prompt template：
Collect all comments on (the design document), plus discussions of this design in (the review group) during (the time range), and organize them into a revision list. For each item, list the commenter, their exact words, the page or element involved, and the category (information hierarchy/interaction logic/visual presentation/copy/guideline consistency). Flag conflicting opinions separately and include both parties' exact words. Put purely subjective comments without a specific target (such as "it does not feel premium enough") in a separate category labeled "follow-up needed." Do not decide whether I should make the change, and do not merge opinions you consider similar.
Prohibitions that must remain：
Do not merge opinions you consider similar.
Two people may both say "this is too crowded," with one referring to spacing and the other to excessive information; merging their comments leads to only one problem being addressed.Similar wording with different targets is common in design feedback.
The "follow-up needed" category is the most useful part of the table. You cannot act on "not premium enough," but listing it separately tells you to ask "Which specific part makes you feel that way?"
Acceptance checklist：
- Check that commenters are identified correctly — attribution matters because each person must confirm the revisions; following up with the wrong person is awkward.
Scenario 4: Style research and mood boards
Prompt template：
Research recent visual trends for (products/websites/apps) in (the industry/category), using these references: (list). Open each in a browser and capture screenshots. Create a comparison table covering palette, layout structure, typographic character, graphic language, and motion direction. Label each reference with its source URL and capture date. Finally, group them by visual character and describe each group's shared traits. Do not judge which is better.
Purpose: Supporting references for client or internal proposals, and direction setting before starting your own work.
It can group and summarize; humans make aesthetic judgments.
Red lines
The boundaries in this design chapter need particular clarity because it is easy to interpret them as "AI will replace designers."
- It cannot make the judgments. Which proposal is more appropriate, whether to retain an element, and where to place visual focus depend on understanding the brand, audience, and situation; feeding it references cannot provide that understanding. It offers options and adaptations; humans choose.
- Official external materials require final human review. AI-generated graphics may pose copyright risks, copy may violate advertising law, and brand elements may have been subtly changed without anyone noticing. Anything that will be printed, advertised, or published must receive a final human review.
- Do not let it write the "why" in your design rationale. The designer's reasoning is the most valuable part of a proposal review; that is where professional expertise lies. Letting it write for you can leave you unable to justify your own explanation.
Fallbacks
The PRD covers all states thoroughly: State honestly that nothing needs confirmation; do not invent items just to fill a quota.
The guidelines document does not exist: First ask about the palette, type scale, and spacing system. List the guideline values you will use for confirmation before producing the deliverable; do not assume common design conventions.
Reference websites will not open: State which sites could not be retrieved; do not substitute remembered impressions for screenshots.
Upstream and downstream handoffs
- Upstream：
pm-skills/pm-prd-writer（PRD）、job-mkt(key visual and brand guidelines) - Downstream: Save interface and state lists beside the requirements document so product, development, and testing use the same reference; turn the revision list into tasks and check them off as completed.
Honest limits
- Do not delegate design judgments, final visual review, or the reasoning behind the design rationale.
- Adaptations are drafts; the designer decides the final version.
- Copyright risks in AI-generated graphics require human verification.