如何制作实用美观的设计文档

   作为一个交互设计师,我们要全局掌握产品的背景、逻辑、用户体验。但是,我们不能忽略设计过程中一个很关键的步骤,设计输出。

  如果我们用email或者其他大海报的方式来输出设计文档,有没有产品经理会抱怨说看不懂?有没有开发抱怨使用过程中效率低?在我之前的工作经验中,我一直保持用一种方式来输出设计文档,InDesign + PDF,在之前的产品同事与开发同事得到的反馈是好的,这里也希望分享并讨论这个方式是不是适合我们腾讯的产品开发节奏。

  用InDesign输出PDF设计文档的好处有不少,我这里先列举几点:

  1、设计文档规整,阅读效率提高。

  2、设计文档适合打印,在很多评审场合阅读纸张更有效。(同时请注意环保)

  3、一个部分讲一个故事,清晰明确,而不是把所有场景都集中在一页上。

  4、InDesign可以设置文字,图片格式,通过style来管理,大大提高修改设计文档的效率。

  5、设计文档简洁美观,让阅读者轻松愉快。

  6、笔记,交互形式,配合设计图的方式,全面,内容集中,不需要额外注解。

  7、可以配合视觉设计进行文档输出,作为一个完整的reference。

  8、有助于知识保存,知识传播。

  9、设计师创建并维护设计文档贯穿整个产品设计过程,主人感,成就感强。

  最后强调一下,这里指的设计文档是唯一输出,贯穿设计师所有工作过程中,而不是产品设计完成后的总结沉淀。

  这个设计文档模版也是多变的,设计师可以根据自己产品的需求灵活变动,请不要拘泥于模版。

  Now let’s start digging.


  这是第一页:文档封面,文档封面是每一个文档的第一个展示,我们应该清晰的传达这个设计文档的基本信息。在InDesign中,这页的顶部可以设立为主模版,支持整个文档。

  A. 文档生产方logo,展示设计文档来自哪个团队。

  B. 团队或者项目名称,再次展示文档信息。

  C. 主标题,这个标题是产品的名称,应该贯穿整个文档。

  D. 版本号很关键,设计文档需要有严格的版本控制;修改时间可以告诉读者,这个文档的最近更新情况;当然,这里还可以根据需要加入设计师名称,ID,Email信息等。

  E. 页码需要在一个显眼的位置,特别是在远程会议的时候,页码会是一个重要的定位信息。

  F. 第一页不要太多信息了,要让读者集中注意力,只放一个标题是好主意,有时F与C会是一样的。


  这是第二页:修改记录,修改记录对于持续更新的产品设计文档是不可或缺的,开发,产品经理,与设计师能根据修改记录快速了解每个版本修改的内容。例如例子中,7月12日修改了6个点,如果没有修改记录,开发可能需要1个小时看完100页的文档才能了解哪些地方被修改过。

  A. 修改记录应该为文档的第二页,关键,价值大。

  B. 内容区重点为修改日期,与简短的修改内容,修改内容应该首先点明版本号,然后把修改的部分与页码写出方便读者查阅。


  这是第三页:内容目录。

  A. 内容目录是整个设计文档的索引,放在第三页的重要位置。

  B. 在用InDesign生成PDF后,请使用PDF把这页的每个索引编辑为链接,这样读者就可以方便在这页直接跳转到需要阅读的页面。


  这是第四页:分段。在完整展开设计文档前,要构思好每个段落应该讲一个什么故事。无论多么复杂的产品,都可以根据功能,场景,用户群体等因素划分为数个故事。在每个设计文档中,我们都应该思考怎样划分故事情节给到我们的产品经理,开发,设计师,管理者,以及适应用户群体,理想状态,故事的划分是通用应对所有人群的。

  A. 就像模版中所说一样,一次只说一个故事。


  这是第五页,内容。内容区展示的内容丰富多样。这里我只给出了款式,分析了款式后,再补充一些可以在文档中加入的内容。

  A. 副标题,也是故事名称。例如一个面向用户的产品的总标题为QQ美好生活,副标题会是一个清晰的故事子集,例如美好生活之夏日健康饮品。

  B. 每个设计图需要配标题,在远程会议中,这个标题配合数字的方式可以极大提高交流效率。

  C. 在InDesign中,我主要使用两种设计图方式,一种是在InDesign中直接生成设计图,一种是把PSD源图直接放入InDesign。第一种的好处是,所有设计图在InDesign中,可以统一设定风格,统一修改。第二种的好处是,PSD可以输出更清晰的交互,视觉图,而且InDesign可以记录路径,以后的修改中,可以直接修改源PSD,然后刷新InDesign文档就可以刷新所有文档内PSD图。

  D. 笔记区适应在每个需要笔记的页面,非常重要,可以极大减少产品经理,开发,设计师持续互相问问题的时间。

  E. 笔记中也可以录入对产品经理,或者开发的问题。在每次评审的时候,我会在文档中直接标记需要注意的点,这样会后设计方的修改记录就直接产出。例如:”这6个图需要在2秒内拉出来,需要与开发确定”。

  今天只给出了基本的模版和InDesign设计经验。设计文档还有很多功能。例如,可以和视觉设计师配合,在一个文档内同时记录交互和视觉设计。甚至可以在一个文档内同时记录交互,视觉,前端开发code做整体文档。

  生成PDF后,可以放入iPad等移动设备,可以帮助你在5分钟内,与老板散步中描述几个好点子。

  设计文档的难点是开始建立所需的细致时间较多,但是文档架构一旦搭好,维护的精力小于预期,以后的每次输出,制作的设计师以及阅读的产品经理和开发,都应该是心情愉悦的。:)

时间: 2024-10-02 20:10:44

如何制作实用美观的设计文档的相关文章

产品交互设计:如何制作实用美观的设计文档

中介交易 SEO诊断 淘宝客 云主机 技术大厅 前言:最近准备做一个设计文档的分享,但是一直没有时间整理好keynote,这里先分享一个设计文档模版,以及模版中每个元素的使用理由与方法.之后的设计文档分享中,会加入更多的设计文档案例来分析讨论. Here we go. 作为一个交互设计师,我们要全局掌握产品的背景,逻辑,用户体验.但是,我们不能忽略设计过程中一个很关键的步骤,设计输出. 如果我们用email或者其他大海报的方式来输出设计文档,有没有产品经理会抱怨说看不懂?有没有开发抱怨使用过程中

设计文档的制作经验分享

最近准备做一个设计文档的分享,但是一直没有时间整理好keynote,这里先分享一个设计文档模版,以及模版中每个元素的使用理由与方法.之后的设计文档分享中,会加入更多的设计文档案例来分析讨论. Here we go. 作为一个交互设计师,我们要全局掌握产品的背景,逻辑,用户体验.但是,我们不能忽略设计过程中一个很关键的步骤,设计输出. 如果我们用email或者其他大海报的方式来输出设计文档,有没有产品经理会抱怨说看不懂?有没有开发抱怨使用过程中效率低?在我之前的工作经验中,我一直保持用一种方式来输

设计理论:制作网页前端开发的文档

前端开发的文档相信大多数情况下都没有后端的服务描述详细,而大多数测试也仅仅在黑盒测试,所以很多情况下对这片文档的描述都廖廖无几. 前端文档缺失的原因 前端开发的文档相信大多数情况下都没有后端的服务描述详细,而大多数测试也仅仅在黑盒测试,所以很多情况下对这片文档的描述都廖廖无几. * 前端开发的代码分散--没有规范化,没有很好的设计,大多数人仍以业务为主的开发方式.* 测试人员对前端仍然处于黑盒测试,有没有文档都不影响到他们的测试进程.* 一旦业务定型,用传统方式的文档模式,很难复制到前端开发来.

通向架构师的道路(第二十六天)漫谈架构与设计文档的写作技巧

前言: 这篇是一篇番外篇,没有太多代码与逻辑,完全是一种"软"技巧,但是它对于你如何成为一名合构的架构设计人员很重要. 在此要澄清一点,架构师本身也是"程序员",不是光动嘴皮子的家伙们,如果你不是一名程序虽出身那你根本谈不上也不可能成为一名架构师. 那么架构师还有哪些是作为一名程序员来说不具备的呢? 其中有一项能力就叫做"文档写作能力". 一.Soft Skill与Hard Skill 作为一名架构师除了是一名资深的程序员外,它还必须具有相应的S

如何写软件设计文档

软件设计的不同模型:瀑布式.快速原型法以及迭代式 自从1968年提出"软件工程"概念以来,软件开发领域对于借鉴传统工程的原则.方法,以提高质量.降低成本的探索就从未停止过.而在这个过程中,提出了许多不同的软件开发模型,典型的有:瀑布式,快速原型法,以及迭代式开发等. 瀑布式模型 是由W.W.Royce在1970年最初提出的软件开发模型,在瀑布模型中,开发被认为是按照需求分析,设计,实现,测试 (确认), 集成,和维护顺序的进行. 快速原型法 快速原型模型的第一步是建造一个快速原型,实现

用户界面设计文档:手指友好型设计

文章描述:手指友好型设计-为了更好的点击而设计. 玩飞镖的时候,靶心是最难射中的位置,因为靶心是整个靶面上面积最小的部分.越是小的目标,就越是难以达到.这个准则在移动设备的触摸屏幕上同样适用. 众所周知,对于触屏设备用户来说,面积小的目标比面积大的目标更难操纵.所以,在设计移动设备界面的时候,触控目标一定要充分的大,足以让用户操作自如.但是多大才算充分呢?多大才是对于大多数用户最合适的尺寸呢?各大移动设备开发者已经认识到这个问题,最常见的做法是在各大厂商的用户界面设计文档中寻找答案. 那么,设计

互联网产品设计:产品设计文档(PDD)

传统上写产品需求文档(PRD)的做法,就是把用例.流程图和网页原型图一股脑的放到一个Word文档里.一般一个产品都包含乃几十个乃至上百用例,每个用例都有自己的流程图,每个流程图又包含了少则几个多则几十的网页原型图,结果就是产品需求文档变得庞大无比,写的人费事儿,读的人更惨. 自从我受到了这样文档的折磨,我就一直都在琢磨怎么才能把文档写得更简单一点,让阅读的人-通常是设计师和程序员-能够在最短的时间内领会产品的设计. 原来做UI设计师的时候,我创造了一种用流程图来表示产品交互的办法,这个方法受到了

实战从需求文档到设计文档的书写规范(一)

1.前言 本文有两个目的:实现每晚构建平台和探讨一个软件从需求文档到设计文档的书写规范. 每晚构建是软件研发管理中极具价值的手段,对于加快发现和改正缺陷,降低集成风险,提高产品质量,加强成员沟通与协作,缩短产品上市时间,增加项目开发透明度,提高项目组成员信心和斗志有着非常重要的作用和意义.本文从软件工程过程:需求定义,分析,设计出发描述了实战每晚构建平台的大部分过程. 软件工程中文档有着极其重要的地位,良好的文档风格和习惯是一个团队成熟的重要标志.目前有些软件研发人员特别是刚刚走上岗位的研发人员

实战从需求文档到设计文档的书写规范(七)

2.2 人机界面设计 不需要. 2.3 存储设计 见构建信息显示系统. 2.4 系统接口设计 构建系统和操作系统的接口在OSScheduler.在Linux下可以实现成一个调用ant LogAdmin的shell 可执行文件,并配置crond每晚某个时刻执行这个可执行文件. 3.实现 在这节中充分利用本文章系列中篇中所有的技术,并显示了部分源代码. 3.1 部署图 在实现时,第一个要考虑的就是类如何与源文件对应,这些源文件又是如何组织的,表示这些信息的图表称为部署图.图表的格式不一定要很标准,这