先讲大场景,再讲小分支。先简单叙述下我们的产品目标和设计目标,再说我们主要解决了哪几个场景下发生的问题。接着讲流程,先主线任务,如有时间再讲支线任务。讲页面之前,要先讲页面是怎么来的;讲页面时,不要细讲里面的内容,要在具体的详情页面中对照着讲,这样参会人更容易理解。在详述每个页面的过程中,分别描述清楚what?why?how?几点即可。 在阐述时有主次之分,重点或大的改变最开始讲,有的内容则不需要细讲,有人提出疑问或质疑时再详细解释。 c.明确会议主题 明确会议主题,是提高会议效率的首要指标。在会议前明确主题,尽量讨论具象化(有初步想法后再开会),即最好有实际的图表现出来,不然大家讨论全凭脑袋空想,且就算达成一致大家想的还不一定一样,这样开会会非常浪费时间且没有意义。 当遇到分歧或疑问时,如果是会议主题内的,能当场解决的当场解决,无法当场解决,先记录下来,会下继续讨论。如果是会议主题外的,则做好记录,会下与疑问提出人讨论。另外,在会议中看交互稿时,参会人员很容易提出细节和视觉层面的问题,此时要讲清楚这不是视觉稿,而是交互稿,主要是过内容和逻辑,不要纠结细节,具体风格、样式等内容在视觉阶段再提出。 d.记好会议纪要 现实中,一次性交付交互稿显然是不可能的,再加上需求方不时的需求变动、各职责人员站在自己角度看待问题的差异,会议上难免会产生一些分歧,导致需要改稿。所以会议上需要记好详细的会议纪要,以便对已确定的改动,交互设计师改稿后,与相关人员会下(或下次会议)再次确认;对提出的尚不明确的需求,会下及时与相关人员沟通,尽快确定。 另外,在会议上,产品经理“突发奇想”得出的新需求或要变动的需求,在未确认价值前,一定不要当场答应。可以先将内容做详细记录,在会下经过仔细评估是否合理,价值多大,与提出人再次确定后,再决定是否要改。并且所有的需求还需要产品经理们协调一致后,再做决定;若产品经理内部迟迟未确定,那可交互先行,一是从交互角度判断可不可行,可行的话先画出草图,出初步思路,再去找产品经理讨论;二是占据主动性,更有话语权。 5.项目跟进 即使已经定稿交付开发,也会有很多或细节、或实现难度、或时间资源方面的问题,所以不能一交付完就万事大吉了。毕竟最终的开发效果,根本性地决定着用户体验。实际项目中,经常有这样的情况:开发遇到问题却没有询问交互,而是自己用“自己的方式”解决。这显然是最糟糕的情况,所以为了保证最终体验,交互应主动进行项目跟进。 在这过程中,主动询问相关人员有没有遇到什么问题:交互文档中有没有什么没看明白的地方或还未考虑到的地方;设计的实现难度;如果时间紧张,那么设计的优先级是怎样…… 6.修改迭代 若设计需要有小的改动,则应先找相关人员讨论,多方明确且达成一致后,再做变更,并在交互文档中最好对应的变更纪要和具体说明。最后,将相关事项发邮件给所有项目成员。如有必要,则还需集中对相关人员再进行一次会上的讲解说明。若改动较大,则放到下一版本。 (责任编辑:admin) |