第一手参考
ORIGINAL SKILL / WEB DESIGN
reference-driven-
web-design
把客户口中的“照这个网站做”,变成一份可以直接开工的 DESIGN.md。
- 输入
- 客户给的链接、团队保存的截图,或 Skill 补找的候选
- 输出
- 每个参考负责什么、发生冲突听谁的、页面如何验收
偏好线索
受众 / 内容 / 品牌
填补缺失职责
桌面 / 手机
一份能直接开工的设计规则
- 视觉依据
- 来源与借用范围
- 信息结构
- 内容顺序与层级
- 验收方式
- 视口与降级路径
- 01验证证据
- 02分配职责
- 03用户批准
它解决什么
参考网站发过来了,
具体要学什么,却没人说清楚。
哪个网站管视觉,哪个管结构,动效从哪里来;如果发生冲突,谁优先。这些事不先定下来,参考越多,返工越多。
- 01
打开原网页
确认链接能不能访问,也确认页面上到底有哪些内容。
- 02
把参考拆开
分别判断视觉、结构、动效和设计系统该参考谁。
- 03
让用户拍板
借用哪些部分、发生冲突时谁优先,都交给用户确认。
- 04
写进 DESIGN.md
把决定写成网格、字体、组件、动效、移动端和验收规则。
三种处理方式
客户发来参考网站后,
接下来怎么做?
完整案例演示
原理讲完了。
让我们上手试试。
我们从一句模糊需求开始,走一遍补信息、选参考、用户批准、生成 DESIGN.md 和实现页面的过程。
开始案例示例项目 / TideNote
用户只给了产品想法和两个参考。
TideNote 是一个虚构的文献阅读工具,给经常读论文、做标注和整理摘录的研究生使用。我们就用这个任务来演示。
“给 TideNote 做一个产品介绍页。参考 Readwise Reader 和 Linear,做得高级一点。”
这两个参考没有覆盖全部决定。我会先确认 TideNote 的用户和内容,再分别判断它们适合负责视觉还是结构;缺少的动效参考会另外补找,不把方向偷偷混在一起。
Readwise 负责视觉,Linear 负责结构;动效候选看完后再批准。
Agent 补找并检查参考
每个网站,
只负责回答一个问题。
Readwise 管视觉,Linear 管结构,Raycast 管动效;Craft 留作备选,Arc 说明为什么不用。点击名称可以打开原站。
用户最终批准:每个参考只管一件事
用户 / 最终批准“视觉用 Readwise,结构用 Linear,动效用 Raycast。Craft 保留,Arc 不采用。”
- 视觉Readwise Reader
首屏直接呈现 PDF 阅读与标注界面
- 结构Linear
先说明用途,再展开三项核心功能
- 动效Raycast
只表现 PDF、标注和笔记的状态变化
Agent 生成规则并完成实现
决定已经写进 DESIGN.md,
可以开始做页面了。
左边是刚刚确认的规则,右边是同一个任务在有无规则时的两个版本。
- 视觉参考
- 参考 Readwise Reader;直接展示 PDF 阅读与标注界面
- 内容结构
- 参考 Linear;先说用途,再讲标注、笔记与文献库
- 动效参考
- 参考 Raycast;只在 PDF、标注和笔记状态切换时出现
- 检查视口
- 1440 × 900 与 390 × 844 分别检查
选择理由、冲突优先级和检查视口都在同一份文件里。
同一个任务,两种做法
左边直接拼参考,右边先确认 DESIGN.md 再实现。
直接把参考拼在一起
做出了一个通用产品页,但看不出它服务谁,也没有明确的验收方法。
更智能、更高效地管理你的知识
先确认规则,再实现页面
页面直接展示研究生的 PDF 阅读任务,并按 DESIGN.md 检查。
阅读和整理不再断开。
关联到论文第 4 页PDF 标注 笔记关联 文献库
笔记 03 已关联
- 产品对象
- BEFORE没有说明
- AFTER研究生和论文写作者
- 首屏内容
- BEFORE通用口号和功能名
- AFTERPDF 阅读、标注和笔记工作区
- 验收方式
- BEFORE凭感觉看像不像
- AFTER按 DESIGN.md 和两个视口检查
实际交付网页
现在,打开做完的 TideNote。
下面不是界面示意图,而是按这份 DESIGN.md 做出的响应式网页。可以切换文献、改变标注模式,也可以把笔记保存到知识库。