* 没有最好,只有更好。 有尴尬的事是有些流程虽重要,但不一定有产出。
在 UXD 工作中,通常在前期容易出问题,一些工作不到位,疏漏会导致设计效果不好,偏离轨道,各种奇奇怪怪的问题,特简单说明。
特别注意:并不是所有项目都需要严格照做,大项目按流程走,防错,质控。 中项目通常控制关键节点,多数小项目按需。具体实施以团队结果为准。
以线性排列,实际操作中部分节点是同步的,具体参考流程图部分。这里主要是做相关节点的说明,记录。存放参考样例。
必做的
推荐做的
可以参考的
以产出为主,兼顾关键节点提示,目标编写必要产出的最合理的范本。 推荐部分可能无需实际产出,同样有些节点很关键,但在工作中很难用具体产出限制。
产品提供的产出,包括来自前面流程的相关文档。
通常带有原型图,该原型图用于从产品的理解处理需求的原型。此时重在表达完成产品的参考,主要用于讲清楚需求,以推荐/自己会的交互方式。这里是心原型为工具说明产品思路或产品的交互建议。(当然也可能包含需求部门的硬性要求的内容)
如果有条件,在需求讨论阶段时就介入(或者更早,有必要的话),充分理解、沟通 。 尽前介入。
了解项目的基础,如有不清楚不明白的,要与产品确认。此项交方向的重要参考,防止遗漏。
必要(按需)的用研工作 (交互参考)
此时需求已完全理解,方案基本确定,可以给出工时预估,更新研发计划或调整功能设计了(如果有)。
在方案确定之前,工作量可能有较大的差异,充分理解产品需求,结合场景、任务、流程后,做出当前环境的最优方案(原型),这里的原型与产品原型的不同之处在于: 用了产品原型的核心(产品目标,和预期的手段等)合理的结合了用户体验学科的内容,是进一步的升华。 当然也有变化不大的,比如:
在项目越急的时候,更要做这一步的工作,帮助尽快确定准确评估工期。 时间要求越严,手稿要做的越细致,但因为是手稿,高精度的和低精度的时间成本相差很小。
质量审查
内��外审核后,需要修改的项目如何跟进,是主观还是客观的意见,由谁来定需不需要修改这些问题。如果是使用评审制度初期,可适当的放松,不必过于严苛,对流程、员工工作造成困扰,合理引导,循序渐进。
非线性,可提前介入,可分批交付(常见)
团队是接口人制度,所以 UI 什么习惯,什么时候介入适合等等都由 UX 来安排。
共同参与产品需求会,启动会的,就不需要该步骤,如果没有参加,后期介入的,需要再做
项目方 /stackholders 的预期是什么样的,有没有参考,做到什么样能达到满意?
!!!可给出工时预估,[更研发计划或调整��能,交互定后通常不会有大的变化]
遵守规范,使用早期的 beta 规范,才发现规范的问题,从而优化规范,提炼必要的组件。
内、外审核后,需要修改的项目如何跟进,是主观还是客观的意见,由谁来定需不需要修改这些问题。如果是使用评审制度初期,可适当的放松,不必过于严苛,对流程、员工工作造成困扰,合理引导,循序渐进。
通常在研发阶段会成很多的设计还原问题,因前端习惯或能力问题,其实,用职业的眼光看问题,开发对设计的细节不敏感也可以理解的(不过优秀的 FE 是不应该)。甚至一些细节,我们设计师自己也只是在做图的时候思考、注意。如果不对照原图很多的细节也看不出来(只是在设计的时候认真的推敲)然而细节的集合就是设计的质量、质感。 丢掉了一部分,就会有折扣。
这就要求我们,在验收的时候对照原图,找回丢掉的还原度,找回设计质量。同时学习相关部分的经验(有时候甚至会发现更好的方案,因为实际场景和设计图的差别等原因)下次做好乙方的改善。
也要督促前端照图施工,养成看图认真看标的习惯。
通过验证数据调整设计方案,最终成功上线或终止上线。
经常会被项目淹没,没时间或精力去跟进后续的数据。 要知道,你的设计最终是为了什么? 通俗点说:"你要怎么在你简历的项目说明部分描述你的收益?"
可以试着在完成自己交付时,给日程设置一个提醒,比如在上线后一周,找产品要相关数据(权限范围之内的)。
除了以上内容,还有些内容需要注意,这里暂时想到一点点,如果有好的建议以告诉我
推荐重大项目或出问题的项目及时复盘,吸取经验教训。