onelucy

我曾见过的生命,都是行过,无所谓完成。

© onelucy | Powered by LOFTER

关于交互稿的一点思考

工作经验尚浅,对于交互也从不懂到略知一二,在实际工作中,不断有新的收获与认识,做一个简单的分享,还请各位批评指正,共同进步。

 交互设计师的工作中,最主要产出物是原型图,也就是交互稿。

最早,学习使用AXURE,绘制交互稿,主要是想将自己的    设计方案表达出来。然而在实际工作过程中,逐渐体会到了交互稿不仅是一份设计稿,还是PM,交互,视觉,开发多方的沟通文档,包含了不同的职责(用途)。

 一方面,对于交互设计师来说,交互稿是我们的交互方案、设计表达。

 拿到需求后,设计师需要对PM给的需求重新审核,产生新的理解,并转化为设计目标,才能设计出更合理的方案。设计过程中,如果没有足够深入和清晰的设计思考,将会在多个方案中难以抉择,或是陷入细节无法自拔,后期也难以与多方达成共识。

 原型绘制在整个过程里占用时间精力不会太多。有的时候最后呈现的的交付结果是一个看上去很简单的方案,相对单薄。但在实际设计过程中我们进行了大量看不见的思考和探讨,可能已经否定了多个其他方案,并在在这个过程中逐渐形成了清晰完整的设计思路。

 而原型图作为一个交付结果,不太能反应设计师的思考过程。怎样将设计思考反应在方案中,或者在沟通过程中完整将设计思路表达,补充交互稿的不足,是一个要思考的问题。

 另一方面,从交互设计师的职能来说,交互作为PM和视觉/开发的中间环节,我们的交互稿将被PM、视觉、开发的相关同事阅读,进行多方沟通。一份清晰的交互稿能够节省大量的沟通时间。所以我们的交互稿需要考虑相关岗位的同事对于交互稿有怎样的需求,即怎样绘制和标注交互说明能够更清晰地向不同岗位的同事传达所需要的信息。

 怎样将从PM处获取的需求优先级等信息反映在交互稿中。向PM了解项目当前情况,考虑后期拓展,运营需求,对进度把控,对开发难度进行评估也是交互的职责。

 交互和视觉有重叠的工作区域。在后续工作中要考虑交互稿的绘制方式,对于视觉设计师,怎么样能给予辅助而非限制。

 而开发人员,需要从交互稿中知道页面逻辑、服务器响应的判断点、极限状态等交互说明,并且前端和后台也有不同的理解需求,这些都会影响交互稿的绘制和交互说明的标注。而作为设计出身的初级交互设计师,对视觉的工作较为容易理解,而对于开发的工作量还难以有正确的评估,对前后端的分工职责的理解也不够明确,都需要在项目中多与开发沟通、请教。

 一份好的交互稿能够承载不同的功能,节省沟通成本,减少犯错,更加高效地支持多方的工作。所以,在后续的工作中,基于交互稿不同职责,不断去思考交互稿更好的表达方式,优化调整交互稿。

 一方面,从自身出发,多多积累循循渐进,不断提高方案设计和表达的能力。另一方面,多与不同岗位的同事沟通,了解他们对交互稿的需求,看看怎么样通过原型绘制,交互说明的撰写能够更好得实现。

 哦弥陀佛,苦海无边,继续修炼。


评论 ( 2 )
热度 ( 1 )