加入AI 知识共创: https://aicc.pro

UXD 全流程产出参考

by jovi @ 2021 本页的主要目的是：
  1. UXD 标准流程（SOP）参考
  2. 收集整理各阶段的关键 产出的样例，参考学习，优化。

* 没有最好，只有更好。 有尴尬的事是有些流程虽重要，但不一定有产出。

UXD 产出前流程

在 UXD 工作中，通常在前期容易出问题，一些工作不到位，疏漏会导致设计效果不好，偏离轨道，各种奇奇怪怪的问题，特简单说明。

特别注意：并不是所有项目都需要严格照做，大项目按流程走，防错，质控。 中项目通常控制关键节点，多数小项目按需。具体实施以团队结果为准。

『拉成条』的流程

以线性排列，实际操作中部分节点是同步的，具体参考流程图部分。这里主要是做相关节点的说明，记录。存放参考样例。

必

必做的

荐

推荐做的

参

可以参考的

Avatar 需求阶段

需求阶段

以产出为主，兼顾关键节点提示，目标编写必要产出的最合理的范本。
推荐部分可能无需实际产出，同样有些节点很关键，但在工作中很难用具体产出限制。

产品提供的产出，包括来自前面流程的相关文档。

●
  • 参BRD（business requirement document）— 商业需求文档
  • 参MRD（market requirement document)—市场需求文档

通常带有原型图，该原型图用于从产品的理解处理需求的原型。此时重在表达完成产品的参考，主要用于讲清楚需求，以推荐/自己会的交互方式。这里是心原型为工具说明产品思路或产品的交互建议。（当然也可能包含需求部门的硬性要求的内容）

  • 参PRD（product requirement document)—产品需求文档
  • 参FSD（functional specification document)—功能详述文档
Avatar 交互阶段

交互阶段

如果有条件，在需求讨论阶段时就介入（或者更早，有必要的话），充分理解、沟通 。 尽量提前介入。

  • 必产品背景文档

了解项目的基础，如有不清楚不明白的，要与产品确认。此项为交互方向的重要参考，防止遗漏。

●

必要（按需）的用研工作 （交互参考）

●
  • 必场景分析
  • 必需求分析
  • 参任务分析、拆解
  • 参其它必要的分析、研究 不同的项目、环境等因素，需要的研究有所变化
●
  • 荐UX 设计方案（草图） 纸上原型推敲，沟通 （快速设计方案）【IMG】

此时需求已完全理解，方案基本确定，可以给出工时预估，更新研发计划或调整功能设计了(如果有)。

在方案确定之前，工作量可能有较大的差异，充分理解产品需求，结合场景、任务、流程后，做出当前环境的最优方案（原型），这里的原型与产品原型的不同之处在于： 用了产品原型的核心（产品目标，和预期的手段等）合理的结合了用户体验学科的内容，是进一步的升华。 当然也有变化不大的，比如:

  1. 评估后发现产品已经做的很好了，交互处理也很专业。 [好]
  2. 对交互要求不高，原型已完全满足。 [不一定好，足够用]

在项目越急的时候，更要做这一步的工作，帮助尽快确定准确评估工期。 时间要求越严，手稿要做的越细致，但因为是手稿，高精度的和低精度的时间成本相差很小。

  • 必方案（原型产出）【IMG】

质量审查

  • 必自查 设计师自查表过程中查流程遗漏，产出前查设计过程的疏忽。
  • 必内审（UXD组内）-> 调整、审核【IMG】
  • 参外审（产品项目组）->调整、审核
  • 必终稿交付【IMG】

内、外审核后，需要修改的项目如何跟进，是主观还是客观的意见，由谁来定需不需要修改这些问题。如果是使用评审制度初期，可适当的放松，不必过于严苛，对流程、员工工作造成困扰，合理引导，循序渐进。

  • 必后续跟进
Avatar UI 阶段

UI 阶段

非线性，可提前介入，可分批交付（常见）

团队是接口人制度，所以 UI 什么习惯，什么时候介入适合等等都由 UX 来安排。

●
  • 参需求解读、沟通

共同参与产品需求会，启动会的，就不需要该步骤，如果没有参加，后期介入的，需要再做

●
  • 参设计预期

项目方 /stackholders 的预期是什么样的，有没有参考，做到什么样能达到满意？

●
  • 荐设计调研 / 定位
●
  • 必设计策略（方案设计、推敲，沟通） 【DOC】

!!!可给出工时预估，[更新研发计划或调整功能，交互定后通常不会有大的变化]

●
  • 必设计产出（组件提炼）【IMG】

遵守规范，使用早期的 beta 规范，才能发现规范的问题，从而优化规范，提炼必要的组件。

●
  • 必切图标注（可于上一步同步，也可分开）

质量审查

  • 必 自查设计师自查表
  • 必内审 （UXD组内）-> 调整、审核【IMG】
  • 参外审（产品项目组）->调整、审核
  • 必终稿交付【IMG】

内、外审核后，需要修改的项目如何跟进，是主观还是客观的意见，由谁来定需不需要修改这些问题。如果是使用评审制度初期，可适当的放松，不必过于严苛，对流程、员工工作造成困扰，合理引导，循序渐进。

  • 必后续跟进
Avatar 验收

验收 UX、UI

通常在研发阶段会造成很多的设计还原问题，因前端习惯或能力问题。 其实，用职业的眼光看问题，开发对设计的细节不敏感也可以理解的（不过优秀的 FE 是不应该）。甚至一些细节，我们设计师自己也只是在做图的时候思考、注意。如果不对照原图很多的细节也看不出来（只是在设计的时候认真的推敲）然而细节的集合就是设计的质量、质感。 丢掉了一部分，就会有折扣。

这就要求我们，在验收的时候对照原图，找回丢掉的还原度，找回设计质量。同时学习相关部分的经验（有时候甚至会发现更好的方案，因为实际场景和设计图的差别等原因）下次做好乙方的改善。

也要督促前端照图施工，养成看图认真看标的习惯。

●
  • 必验收单【IMG】
●
  • 参最终验收
●
  • 参灰度上线 / 设计验证

通过验证数据调整设计方案，最终成功上线或终止上线。

●
  • 荐后续上线/运营数据获取

经常会被项目淹没，没时间或精力去跟进后续的数据。 要知道，你的设计最终是为了什么？ 通俗点说：“你要怎么在你简历的项目说明部分描述你的收益？”

可以试着在完成自己交付时，给日程设置一个提醒，比如在上线后一周，找产品要相关数据（权限范围之内的）。

Avatar 其它

其它

除了以上内容，还有些内容需要注意，这里暂时想到一点点，如果有好的建议可以告诉我

●
  • 荐项目复盘 【HTML】<缺>

推荐重大项目或出问题的项目及时复盘，吸取经验教训。

●
  • 参通过反馈、数据获取洞察，结合backlog 产生新迭代需求，进入下一个循环。