【干货】超全面!阿里设计师教你写好一份设计文档

鸿影:一份设计文档 的 结构大概可以分成Background项目背景、Schedule排期、History版本历史记录、Information Architecture信息架构分析(包括Site Map、Experience Map、Flow等)、Framework框架设计、Wireframe线框图和Mockup视觉稿等。取决于实际项目的情况,部分内容可以省略,也可以 加入更多,比如Storyboard故事板,Prototype可交互原型等。

【干货】超全面!阿里设计师教你写好一份设计文档

鸿影:一份设计文档的 结构大概可以分成Background项目背景、Schedule排期、History版本历史记录、Information Architecture信息架构分析(包括Site Map、Experience Map、Flow等)、Framework框架设计、Wireframe线框图和Mockup视觉稿等。取决于实际项目的情况,部分内容可以省略,也可以 加入更多,比如Storyboard故事板,Prototype可交互原型等。

在过去,我一度没有什么规范的设计文档写 作习惯,用纸笔画完Information Architecture和Wireframe后,就匆匆进入了Mockup阶段,最后的交付物也仅仅是Mockup。前期的时候觉得没什么,后来就感觉 到了问题,这样很容易过早地陷入对视觉细节的纠缠,设计到一半忘了最初的设计目标,有时花了很多精力纠结一个模块交互or视觉设计的好坏,后来却发现整个 模块都没有存在意义,已经背离了最初的业务目标与设计目标,根本不是用户想要的东西;或者场景考虑不全面,设计完一个模块后放到整体里充满矛盾,结果需要 花更多精力来进行补救,导致进度Delay或只能上线充满问题的版本等。

而良好的设计文档写作习惯,虽然会在一开始占据比较多的时间和精力,但却能保证全程设计思路一直比较清晰,做设计的时候时刻思考用户是谁、目标是什么、这样设计是否能帮助达到目标,向团队、向合作伙伴沟通传达自己的设计方案时,也有更强的说服力。

Background

这一部分的内容在设计师和PM、业务方充分沟通需求之后完成,我的习惯一般是分成这几个模块:产品描述,要设计的产品是什么,依托怎样的平台,在什 么场景下发生;业务/产品现状,总结需求方现在面临的主要问题,有哪些体验不好的地方,关键痛点是什么;用户目标,用户群有哪些类型,他们分别想解决什么 问题;访问流程,产品有哪些入口,最终把用户导向哪些地方。这些都需要和需求方确认清楚,明白整个产品的来龙去脉,最终提炼出设计目标:需要设计什么新的 功能,需要优化哪些已有的设计,提高产品哪些使用环节的体验,引导用户做出什么操作,最终达到怎样的业务目标。

Schedule

和需求方确认各阶段交付物的时间节点,制定完成设计的具体计划,每个阶段大概做哪些工作,什么时候内部Review,什么时候和项目组Review等。确保设计以一个合理的节奏展开,可以以较高的质量按时交付。

History

设计稿版本每发生一次比较大的迭代更新,都要记录在版本历史记录里,相比一个个去翻以前的设计稿,版本历史记录可以清晰地展现设计稿的迭代历程,有 哪些需求的变动,有哪些设计时没思考清楚需要修改的地方,Review时大家给出了哪些意见和建议等。有时版本需要回滚,可以更方便地追溯,而项目结束后 浏览这一部分,可以看到自己的设计在哪些方面一开始思考不足出现了各种问题,是如何被发现、改进和提升的,下一次设计的时候是否可以更早地思考到和回避 掉。

Information Architecture

根据具体项目性质的不同,这一块的分析工具也有较大的差异,具体的选择和使用要按照实际场景来,而非机械进行套用。

如果是设计一整套网站系统,Site Map必不可少,通过它将需要设计的内容以全景图的方式呈现出来,对整个网站的架构可以构建起一个初步的印象,像架构层级过深、页面内容重复等问题都可以 通过Site map发现,进而提出是否可以减少页面的信息层级、合并部分页面等,从整体上优化产品的使用体验,而非只见树木不见森林。

Experience Map可以把产品在不同使用场景、流程下的体验问题直观地呈现出来,我们有时会得到一些用研结果反馈,但大量反馈建议直接列举的话会很散乱,也不知道哪些 是真正的问题,哪些只是个别用户的吐槽,通过Experience Map可以整理出用户使用产品大概有哪些场景和环节,各场景和环节下都遇到过什么样的问题,哪些问题出现的频率较高等,帮设计师更好地代入到用户使用产品 的实际体验过程中去,进而思考各场景、环节下都可以进行怎样的设计目标拆解与设计优化、最终帮助完成产品的整体目标。

Flow流程图也是一个常用工具,可以总结出不同场景下用户使用产品的流程和步骤是怎样的,可能产生怎样的分支需要在设计中考虑到,在哪些地方可能产生较大的流失,步骤是否可以合并优化,能否抽象出通用的流程来构建框架设计等。

【干货】超全面!阿里设计师教你写好一份设计文档

Framework

Framework和Wireframe的区别主要在于前者更抽象、通用化,不需要太多的内容细节,而后者更详细、分场景、已经有了删格化和详细的文案等,离Mockup甚至只差配色、图标、阴影细节等。

Framework开始构建起产品的形,抽象出通用的布局原则,页面上大概有哪些模块,这些模块之间的主次、优先级关系是怎样的,每个模块要帮助用 户完成怎样的目标。思考清楚了这些问题,接下来的设计才会减少目标偏离与方案返工出现的概率,能把握住界面的整体结构、模块关系呈现等,而不是陷入细节, 结果让次要的东西喧宾夺主。

Wireframe

Wireframe在Framework的基础上具化出了产品的完整骨架,在这一步需要仔细考虑到每一个可能的使用场景,包括极多极少、错误等特殊情况都要包括在内。

我一般习惯在Axure文档里以建立很多页面,每个页面按照场景进行命名,再在页面里画Wireframe,具体到每一个模块可能出现的一些特殊场 景等,则直接在页面里以模块的方式在主界面旁边呈现,如果是比较简单的情况,也可用文字直接说明。总之,每一个角落都要考虑得当,不能有遗漏,因为水平经 验还比较稚嫩,一开始遗漏了较多内容,也非常感谢合作伙伴和团队前辈们的及时指出。

Wireframe虽然不是Mockup,但在视觉效果呈现上却马虎不得。一开始我觉得不是视觉稿没必要考虑那么多,在画Wireframe时完全 没考虑栅格之类,最终的视觉效果感觉也比较粗糙。后来被指出在Wireframe这一环,文案等内容基本就确定了,如果不考虑视觉效果,可能在实际的视觉 稿产出后,会发生因为文字内容过多溢出,导致整个页面结构都要被迫调整之类的情况,最终增加了产品的设计成本。作为交互设计师,我们可能不用考虑太多配 色、创建角色形象之类的视觉细节,但一定要懂基础的UI设计规范,甚至在视觉要求不高(如很多B端产品)的时候,需要直接扮演视觉设计师的角色,这也是我 们区别于“能画线框图的产品经理”的重要价值。

【干货】超全面!阿里设计师教你写好一份设计文档

还有文案,通俗来说就是“说人话”,各种导航标签、各种引导提示问题、各种按钮说明等的文案也是交互设计师需要思考的,目前我在这方面做得还比较弱,文案有啰嗦、用户不容易理解等问题,正在努力看书写作试图弥补中,就不多谈了。

Mockup

Mockup作为表现层的主要产出,在Wireframe的基础上完成配色表现、图标绘制等视觉细节的呈现,为产品的骨架覆盖上最终的皮肤。在 Wireframe已经充分考虑到各种场景的情况下,Mockup不需要再面面俱到,而是选择关键场景的界面进行绘制表现即可,注意一些 Hover/Active之类的状态表现,再就是标注(在公司内部神器的帮助下似乎已经不用这一步了,怒赞,Sketch棒棒哒,前端都是专业的甚至还懂 点设计,不需要太多沟通就能高保真还原效果,感觉比以前幸福好多!)交付前端了。(想到自己以前画大量精力画不同场景的Mockup,很多只有一点细节的 差异,而Wireframe就是一点纸笔草图,感觉蠢爆了= =)

最后放一张自己的设计文档结构截图吧,虽然Axure很多人黑,但我觉得在文档结构呈现这块真的是最好用的。

【干货】超全面!阿里设计师教你写好一份设计文档

来源:优设   原作者:鸿影

 

原创文章,作者:Catherine,如若转载,请注明出处:https://www.iamue.com/32353/

(0)
CatherineCatherine
上一篇 2017-06-05 02:32
下一篇 2017-06-05 04:37

相关推荐

  • 非设计专业的学生,如何系统的学习交互设计

    数十万互联网从业者的共同关注!作者:青溪Joanna微信公众号:qingxizhaji(青溪札记)作者投稿早读课发表,转载请联系作者。曾经我也是一名非设计专业的学生,作为自动化专业的硕士希望自学做交互设计,有很长一段…

    2017-08-02
  • 案例:交互设计七大定律分享

    一费茨定律(Fitts' Law)1、费茨定律(Fitts’ Law)简介费茨定律是由保罗·费茨(Paul M. Fitts)博士,在对人类操作过程中的运动特征、运动时间、运动范围和运动准确性进行研究之后提出的,时间是1954年;该定律被用来预测从任意一点到目标中心位置所需时间的数学模型,在人机交互(HCI)和设计领域的影响却最为广泛和深远。费茨定律指的是:使用指点设备到达一个目标的时间,与当前设备位置和目标位置的距离(D)和目标大小(...

    2018-02-28
  • 重版权轻用户体验 盲目IPO的腾讯音乐或成下一个多米

    最近,音乐版权又起风云,各大新闻版面被网易云音乐因版权续约未果,下架周杰伦作品的信息霸占,这场由杰威尔音乐独家版权方腾讯音乐主导的“版权狙击战”再次成为行业焦点。众所周知,自在线音乐兴起至今,腾讯与网易云音乐、虾米音乐等音乐平台之间在版权上的纷争已经历了多个回合。但是,距离国家版权局宣布推动腾讯音乐和网易云音乐达成版权合作还不到两个月,在线音乐市场版权之争就因腾讯再起硝烟,令人诧异之余不免有些心寒。所以,腾讯音乐“阳奉阴违”背后,到底有...

    2018-04-08
  • 从设计指南说起,详解Material Design体系组件

    iOS 或 Material Design的设计指南,都是按照组件的属性来系统介绍。
    一般把Control翻译成控件,把Component翻译成组件。通俗的解释说法就是组件为多个元素组合而成,控件为单一元素。但是Material Design把我所认为的控件和组件都合为一体,统称为组件。摊手。

    2017-04-28
  • 设计思考:如何传达APP中的隐藏手势?

    手势本是能够帮助用户更好的使用产品,但手势交互常被隐藏起来,因此用户如果没有发现隐藏手势,便失去了设计这些隐藏手势的功能作用。那么到底该如何向用户传达APP中的隐藏手势呢?看看这篇文章,或许你就知晓。

    2017-05-10
  • 用通俗的方式告诉你什么是「交互设计」

    通常来说,拥有成熟产品的大型互联网公司都会设有交互设计岗位,这个岗位在近几年的招聘市场上也越炒越火。不同于视觉设计师有可视化的作品展示,交互设计师的工作大多无法直观可视化或出于保密性难以对外展示,所以在大众心目中始终是神秘的存在。所以今天就来给大家分享一下我作为一个交互设计师眼中的交互是什么样的。文章的目的是帮助对交互设计不太了解,但工作相关或对此感兴趣的人对交互设计进行基础入门的了解,所以采用了尽量平实简单的描述方式,以帮助大家快速理...

    2018-04-11
  • 【干货知识】最全面的交互设计原则和理论汇总(上)

    【点击上方蓝字↑↑↑关注「艺恋优梦」获得每晚推送】文章包括:格式塔心理学原则、尼尔森可用性原则、尼尔森F视觉模型、Heuristic Evaluation十原则、费茨定律、席克定律、7+2法则、2秒原理、2/8法则、3次点击法则、界面黄金8法则、jakob nielson原则、KANO模型、0123简单法则、MVP法则、婴儿鸭综合症、包豪斯理念、泰思勒定律、防错原则、奥卡姆剃刀原理、maya法则、信噪比法则、序列效应、功能可见性原则、成...

    2018-04-16
  • 用这3个方法,让你像用户体验设计师一样思考

    只要保持好奇心、同理心,热衷于研究身边的世界,像用户体验设计师一样思考,其实很容易。

    2017-05-12
  • 互联网+时代,让用户体验到你的专业性

    物质种类丰富之后,市场要面对的新重点就成了“用户体验”。只有“功能”的商品即使做成百宝箱也只能昙花一现,能够让客户用得舒心用得愉悦才是现代产品的应有魅力。在企业竞相提升体验的大潮中,“别让我等、别让我想、别让我烦”的用户三大心态仍然是大部分厂商的改良依据,然而总有一些人可以在这一基础上做得更加精细周到,成为“体验战”的大赢家。01曾经被无视的用户体验如今是神兵利器在计划经济时代,消费者的选择余地很小,导致了厂商只注重“功能”不注重“体验...

    2018-05-07
  • 交互设计的三个半原则

    一些设计的基本原则往往是通用的、甚至可以说放之四海皆准的,例如优先级、一致性、界面的隐喻等等,好的设计都需要考虑到这些问题,甚至再更广的范围内也同样适用,而不仅仅是交互设计范畴。一个设计师&产品经…

    2017-08-01