方向 01
需求梳理与方案定义
适用范围：手上只有一个粗略想法，或者需求散落在多份文档里，需要先把要做什么、做到什么程度讲清楚的情况。
- 典型任务：把零散描述整理成一份可执行的需求说明
- 典型任务：确认目标人群、使用场景与优先级顺序
- 典型任务：划定第一版范围，把可以后置的部分单独列出
判断依据：如果你说不清“做完之后谁会用它、怎么算做完了”，这个方向通常是第一步。
服务方向总览：先看方向，再决定谈不谈
这一页把囧次元能承接的工作按方向编号逐条摊开，写清每个方向适合的需求类型、常见任务和判断依据。你可以对照自己手上的事情，找到最接近的一条，再决定是否需要进一步沟通。
服务方向逐条说明
方向之间不重叠，也不排序高低，只是把不同性质的工作分开，方便你按需求类型对号入座。
方向 02
内容整理与信息架构
适用范围：素材已经有不少，但结构混乱、重复内容多，或者栏目划分一直定不下来的情况。
- 典型任务：把现有素材分类归并，去掉重复与过时部分
- 典型任务：确定栏目层级、页面归属与入口顺序
- 典型任务：为每类内容约定统一的写法与字段
判断依据：如果问题出在“东西都有，就是摆不顺”，先从内容结构入手比直接改版更省事。
方向 03
页面与界面设计
适用范围：内容结构已经确定，需要把它变成看得见、能评审的页面版式与视觉方案。
- 典型任务：按栏目输出页面版式与模块排布
- 典型任务：确定字体、色彩与间距的层级规则
- 典型任务：覆盖桌面与移动两套尺寸的展示效果
判断依据：如果讨论时大家各说各的、无法对着同一份东西评审，说明需要先把设计稿做出来。
方向 04
前端实现与静态交付
适用范围：设计稿已确认，需要把它变成可访问的页面，并且交付后能直接部署、直接维护。
- 典型任务：按设计稿输出语义清晰的页面结构
- 典型任务：处理响应式断点与移动端可读可点
- 典型任务：整理样式与脚本文件，保证加载体积可控
判断依据：如果验收标准是“打开页面就能看到、能点、能读”，这个方向负责把它落地。
方向 05
上线后维护与迭代
适用范围：页面已经上线，需要按固定节奏更新内容、修正细节或增加新栏目。
- 典型任务：按约定周期更新指定栏目的内容
- 典型任务：修正文字、图片与链接层面的问题
- 典型任务：在既有结构下扩展新页面，不推翻原体系
判断依据：如果需求是“在现有基础上继续往前走”，而不是重新做一遍，就属于这个方向。
方向与需求类型的对应关系
左边是你可能说的话，右边是对应的方向编号。找得到接近的一句，方向基本就定了。
需求类型
- “想法有，但讲不清楚要做成什么样”
- “素材一堆，结构一直定不下来”
- “结构清楚了，但没人能看到具体长什么样”
- “稿子定了，需要有人把它做成页面”
- “已经上线，需要有人接着维护”
对应方向
- 方向 01 需求梳理与方案定义
- 方向 02 内容整理与信息架构
- 方向 03 页面与界面设计
- 方向 04 前端实现与静态交付
- 方向 05 上线后维护与迭代
如果你的情况横跨两三个方向，通常按“先梳理、再设计、后实现”的顺序推进，具体阶段划分可以看 合作流程 。
选择方向时的判断要点
下面四条是沟通前最常需要先想清楚的，想清楚了，方向选择会快很多。
-
看当前卡在哪一步
卡在想不清楚，就是方向 01；卡在东西太多摆不顺，就是方向 02；卡在看不见效果，就是方向 03。卡点在哪，起点就在哪。
-
看手上已经有什么
只有口头描述和已有成稿素材，能承接的方向完全不同。先把手上的文字、图片、旧页面列一份清单，再对照方向。
-
看谁来拍板
如果确认人还没定下来，任何方向都会反复。先明确由谁确认需求说明、由谁确认版式，再进入具体工作。
-
看交付后谁维护
交付之后由谁更新内容、按什么节奏更新，会影响结构怎么搭。这一条想清楚，方向 04 和方向 05 的边界就清楚了。