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 产生新迭代需求,进入下一个循环。