产品经理提供了Usecase给交互设计师,交互设计之后怎样快速修正Usecase

先弄清问题出在哪里。\u0026gt;\u0026gt;UI进行交互设计之后,会打破UseCae交互的过程,甚至有的时候会完全颠覆,当然完成的功能还是一致的。遇到的头疼的问题是,几乎所有的UC都需要大幅的改动,几乎是改的面目全非。这就是问题所在。首先,认为交互设计就是由 UI 一个人负责的,这个理解常常是错误和片面的。针对一个系统功能的交互设计,一个系统只能出一个统一的版本。Use Case 是这个交互(步骤和流程)的文本抽象描述,而 UI 是这个交互的可视化(Visual)、视觉或直观表示,两者其实是一体两面,相互不能取代。你把交互设计的任务交给两个人去做,而他们做的结果,对功能交互的步骤、流程的理解从一开始就是不一致的,甚至大相径庭,而两人之间又存在协作、沟通上的问题,所以才导致这么多矛盾。第二种可能是,PO 没掌握用例编写技巧,导致写的 Use Case 本身质量不高(如含有大量 UI 细节,而不是准确反映用户的使用意图和目标),稳定性差。通常的解决办法:从源头上消除不一致性,从一开始就让 PO 在 Use Case 里编写的 flow 与 UI 设计的 flow 基本一致,确保实质上是同一个系统功能交互的流程。这需要两人之间的充分合作与沟通,例如同时在一起工作,pair design and review。这也要求 UI 经过学习能看懂 Use Case 的主要内容(如 outline),而 PO 也能明白 UI 的设计意图,确保两人设计出来的是同一个交互模型。而不是像现在这样,两人各做各的,结果出来两套东西,既不沟通,也不核对,尽量去理解、靠近对方的设计。\u0026gt;\u0026gt;1、UC大幅改动,需要较长的时间更新此部分文档,PO很不乐意。2、更新UC导致交付给开发的时间延后,开发经理很是恼火。\u0026lt;\u0026lt;如果 PO 与 UI 之前就有很好的沟通,确保 UC 与 UI 大体上的一致性,这种大幅度改动是完全可避免的。减少返工和浪费的一个关键在于 UI 设计的时间点。如果 UI 总是在 UC 成文之后大幅度变化交互流程,不如让 UI 与 UC 同时设计,或者推迟 UC 细节的编写。\u0026gt;\u0026gt; 3、新的交互方案没有得到PO的认可,双方争执不下,评审会变成辩论赛。研发过程中就技术问题经常出现争执,很正常。如果两人争执不下,而且都有道理,需要有人作出仲裁并承担责任,可以是开发经理、架构师、项目经理等人。可以先决定选择某一方的方案实现。而不是把时间都浪费在辩论上。你们团队的 PO 好像不是真正的 Product Owner(如 Scrum)。一般 PO 作为产品负责人(产品经理)比 UI 的级别要高,他应该比 UI 更了解用户需求。如果出现争执,采用哪个方案 PO 有最终的决定权。这是权利结构设置的问题,责权利分清了可以减少不必要的内耗。如果你们的 PO 水平不够,可能只相当于一个需求分析师,与 UI(用户界面设计师)平级,那么就有可能彼此不服气,老是争执不下。\u0026gt;\u0026gt;4、PO和UI之间存在一定的不和谐因素。这恐怕才是导致问题的一个主因吧,互相看不顺眼。先把两人之间的过节处理掉,如果还是不和谐,考虑换人作搭档。
■网友
PRD增加两轮评审,UI直接介入评审,有意见早提,别交付了再提评审通过后UI需要尊重PRD,不是说完全不能改,但至少要提供靠谱的依据才能大动方案评审会议严格控制时间,争议点采取记录,有证据的当场说,还有疑点的记录下来需要哪些论据比如统计还是分析还是调研回去各自做,迅速做完回来继续对项目经理要控制这个时间做出取舍,有时候为了争取时间容忍一定程度的交互缺失是可以接受的
■网友
po uc ui 为一个人就可解决此问题.


    推荐阅读