交互设计文档616.pptx

交互说明文档必要性、多方意见共享、计划及模版讨论Heidixie 2009-6-16Contents为什么要有这份文档？写什么？什么时间交付？怎么写？可能会出现的问题？为什么要有这个文档？要解决什么问题？要满足什么期望？我讨厌文档工作……我们都不喜欢阅读文档、更别提写文档，太Boring了！现在不是好好在运作吗？我怀疑写了会不会有人用……别白花力气了，直接说更直接更快……要占用我更多资源……没空……要解决的问题——RA之前做过一些小需求和项目，每次变动都很痛苦，设计变了之后，我就要跟着改UC，改截图，有时候UED改了还忘了通知我们需分，导致UC有问题……吴屹峰UC写成什么样，一旦终审完了，需求冻结，以后设计即便发现不吻合，也需要提交需求更改，不然就按照UC进行开发。要解决的问题？页面交互的需求容易漏掉，因为UC里面不可能写太多交互方面的东西。RA贾玉成RA现在如何写UC:1. 参加FBRD确认会，了解并讨论商业需求；2. 看终审之后的FBRD和线框，写UC,遇到不明确的，就找相应的人。有些项目会让RA参加线框评审，有些却不会。线框有时承载不了太多的设计需求，口头传播的容易流失。要解决的问题？希望UED能够在提交HTML?DEMO给RA时，能同时给出一份页面元素描述文档，需要介绍html?demo中的文案、链接以及相关的图片尺寸或显示字符个数。现在RA在这方面花费的时间比较多，经常要和UED去确认这些内容。RASQA收集要解决的问题——前期RA和PD沟通过程中，有很多交互点点不能够明确，比如“默认显示多少属性值”，“标题显示多少字符”等。在以往的需求和项目中，对待这些问题我们都是想到一点补一点的到FBRD文档或者邮件中去。既增加了沟通成本又会存在遗漏细节的风险。PDDean要解决的问题——一怕UC写太多设计需求——写了就不好改设计了。二怕UC不写设计需求——口头讲给前端，前端交代给开发。三怕前端换人做——要重复讲解。UEDHeidi刷新不刷新页面的tab——Radio button有无默认选择——输入框有无初始值？校验如何做？要解决的问题——交互认为很平常的设计需求，如果不表达出来，还是容易被前端和开发忽略掉。UEDLucas这么多问题？牵制重复劳动沟通成本大重要信息遗漏 理解偏差How？一份交互说明文档？PD怎么说——解决了前期RA和PD沟通过程中很多不能明确的交互问题。诸如显示字符数，默认展示多少属性值，标题是否换行等问题……这个文档可以很大程度的推动项目更高效的进行下去。PDDeanRA怎么说——对我的工作很有帮助。首先，不用每次一个仅涉及到交互设计上的改动都要设计文档和UC两方面都做改动，重复劳动减少；关于一些字符数显示、页面控制、校验等非页面功能性的设计，UC中不用写这部分内容我感觉轻松很多。RA吴屹峰使用方法：作为UC的附件一起上传，在UC相关内容处直接链接到设计文档。RA怎么说——我认为它的存在能够相当程度上弥补UC中对页面交互介绍的不足。因为UC是用来描述需求的，如果花太多的篇符描述交互方面的内容，那么将会大大限制UC本身的表达效果及开发人员对业务本质的理解，而且页面交互的描述确实是非常繁琐的，事实上我们在以前的项目中对此是有遗漏的，测试人员经常会测试出一些交互方面的BUG，如页面的较验、联动、页面控件的形式、显示方式等等，而统统这些在UC中一般很难描述完整，或许页面交互的描述也不是UC的主要职责。RA贾玉成UED怎么说——做为参考手册，避免不吻合的问题发生。即使有问题发生，也可以作为界面验收时的Checklist。将“我对A说，我对B说，A对B说”，转变为“A和B共同参考同一份文档”，减少沟通成本及信息不对称。全程影响用户体验（一直到测试，都需要参照设计文档）。UED文档写什么？字符限制链接具体化交互细节说明校验浏览器兼容性测试说明12345文档不要写什么？视觉规范规格（Margin、间距、容器宽度等）商业逻辑（比如为什么要有这个功能）详细的功能实现机制（UC和FBRD的任务）功能逻辑（点击离线状态的ATM后判断等）详细的文案（另外提交动态文案表）12345视觉规范规格如图：由视觉制定。文档写什么？字符限制1每一段动态文本区域，字符有无限制？ 1. 有。按字符数截断（注明多少字符数），注明是整词截断还是字符截断。2. 无。注明自动换行，词内换行VS词内不换行文档写什么？链接具体化2A. 复杂交互的流程图：B. 链接和button的指向：Buy now button，指向下订单页面。不一定是具体的URL，但是需要给出线框图或demo的链接。文档写什么？交互细节说明3文档写什么？交互细节说明3文档写什么？校验——在不能应用校验框架的前提下4文档写什么？校验4在现有的校验框架下，若需要自定义校验方案，需要在此文档