关于原型交互设计文档的一些建议

 

文档的一些建议-交互原型设计软件">
  作为一名合格的交互设计师,为方便产品经理、设计师、开发及项目相关人员能够看到直观的效果,进行更有效的沟通;提供直观的产品设想,说明用户将如何与产品进行交互,在交互设计的过程中一定会产出各种各样的产出物,如流程图、思维图(脑图)、纸上的草稿、甚至高保真演示稿。

  这里简单分享下自己在项目过程中的原型交互设计的一些心得。


  Axure

  制作交互Demo的软件有很多,个人比较喜欢且习惯的就是Axure。Axure操作简单明了,对于初学者来说,非常容易上手;它也拥有强大的交互演示动作,对于高级使用者来说,制作非常高保真的演示Demo, 也是非常有成就感的。

  Balsamiq

  提供了丰富的手绘风格的web常用元件,能创建接近于纸上手绘的原型,让人有眼前一亮的感觉,个人建议初稿方案的时候可以考虑用这个更能吸引人。

  Mockups

  与Balsamiq 风格相似,而 Mockups最大的特色是网页版,无需下载安装,可以基于web的存储可以在任意电脑上联机打开。

  其他还有一些工具,我就不做介绍了,因为个人也没有使用过,比如:

  Microsoft Office Visio、Pencil sketch、Design Studio、Prototype Composer、Lucid Spec、Irise Professional Edition、Adobe Reader…

  每个软件都是各有特色,也有利弊,但软件都只是工具,用哪个都无妨,只要符合自己的习惯就好,关键是产出物。

  相对中保真的交互Demo

  工具之后,就是Demo稿的设计了。在平常的项目中,我基本上都是使用Axure 工具,也是大家常用的工具。而交互Demo也只要出到相对中保真的状态即可,所谓的相对中保真,就是产出交付物中能体现出用户在每个页面上期望看到的内容,以及这些内容在页面上的相对优先级,并要提供流程说明和操作方式及响应状态的表述。

  不是粗糙的草稿方案,也不要出高保真的视觉效果,草稿方案,可以用手绘或者接近手绘效果的工具(balsamiq、Mockups),不见得都需要用axure; 而高保真的原型需要花费更多的精力,同时,不够效率,除非是用于汇报演示方案、或是为可用性测试制作高保真原型。


  一、遵守栅格规范

  很多新人交互设计师都比较容易忽略这一点,没有按照栅格规范来布局,这样容易导致的结果就是:视觉设计师在按照栅格排版时,发现在交互稿中能排下的内容,在视觉稿中排不下了,这样就还得返回去改交互稿,或是需要重新设计布局。

  所以要养成习惯,在设计初时,一定要先根据栅格进行布局,同时也要保证交互稿中的字号、间距尽量符合视觉要求(比如间距最小10像素等),以免给视觉造成不必要的困扰。


  二、不要使用截图与颜色

  有些产品人员或设计师为了能方便,拼凑各种竞品的截图,组成一个页面。这样即不规范,也大大降低了交互稿的档次,还会对视觉设计师也有一定的干扰,个人是非常厌恶的。

  另外,交互阶段的产出方案,应该更聚焦在信息布局、内容层次、操作流程。不太建议在交互稿上使用色彩(除了文字或特殊状态),避免对视觉设计师造成不必要的干扰。如果真的有一些关于想法,可以通过文字描述,或者直接告诉视觉设计师需要营造什么样的氛围,达到什么效果。

  让色彩、质感、具体形势交给视觉设计师,多点空间让视觉设计师去尽情发挥。


  三、不要沉迷于复杂的交互动作效果

  Axure提供了丰富的动作脚本支持,使得动态模拟真实界面交互变成可能, 能实现状态切换、时间动画以及其他一些惊人的小玩意。

  但有时候我们需要思考,在日常工作中是否需要花费这么多的精力和时间?

  这也许决定于我们在设计的这个原型是用于什么情境。如果原型是用以进行前期的用户测试,或为争取资源的高保真演示汇报Demo时,也许需要我们快速产出接近于实际界面的互动效果。

  而如果只是用于流程中的交互物,提供给视觉设计师或前端工程师进行开发,那么过度的设计和效果只能是浪费精力。


  四、一定要有一套属于自己的控件库

  把常用的控件、功能组建、图标、标注等制作成通用的标准小单元,插入到部件库(widgets),在制作交互Demo时,只需要调出需要的控件即可,这可以大大的提高你的效率。


  关于原型控件,每个原型工具都有,可以网上搜索或者调用下他们分享的。但个人建议,还是根据DPL,制作一套自用标准的控件库。

  五、善用master,提高效率

  大量的页面进行统一的更新也是相当麻烦的一件事。在制作时,直接用master制作复用的模块,来取代复制黏贴,在需要调整时,只需要调整master文件即可。

  master是Axure提供的类似于自定义组件的功能,你可以在master设计将常用的交互组件,然后在不同的页面引用,如页面头尾、菜单等会在大部分页面公用内容,非常适合做成master,然后在各个界面中拖曳相应到指定位置。这样当这些共用内容需要修改时,只需修改mater即可。


  六、版本存档也很重要

  Demo,跟实际产品一样,是会迭代和不断被修改的,所以,一定要记得存档。即使是在同一个原型上做修改,也一定要做记录,这对后续回顾很重要。


  后话: 交互Demo设计,是每个交互设计师最最基本的技能,这也是一个梳理思路很好的方式,但不是唯一的形势,Axure也不是唯一工具。只要能清晰表达产品思路、界面UI、流程逻辑及交互状态的好用工具都是值得去尝试的。

时间: 2024-09-04 05:47:04

关于原型交互设计文档的一些建议的相关文章

界面交互设计文档是什么文档 该怎么编写?

文档是什么文档 该怎么编写?-vc编写人机交互界面"> 离开交互圈已经有段时间了.但由于博客还在,还是能够偶尔收到一些邮件,上周有位同学问我:我在求职,我看到很多招聘说明上需要交互设计师编写界面交互设计文档,请问界面交互设计文档是什么文档?怎么编写呢? 这让我想起来2009年自己在项目里也大力推行过交互说明文档(在下文中,简称为DRD),格式倒没什么限制,交互设计师自己写到界面上也行,单独文档成文也行,总之就是让交互设计师能够将界面承载不了的信息通过文档沉淀下来,降低项目里的沟通成本和风险

降低项目沟通成本和风险:写好交互设计说明文档

文章描述:如何写一份交互说明文档. 离开交互圈已经有段时间了.但由于博客还在,还是能够偶尔收到一些邮件,上周有位同学问我:我在求职,我看到很多招聘说明上需要交互设计师编写界面交互设计文档,请问界面交互设计文档是什么文档?怎么编写呢? 这让我想起来2009年自己在项目里也大力推行过交互说明文档(在下文中,简称为DRD),格式倒没什么限制,交互设计师自己写到界面上也行,单独文档成文也行,总之就是让交互设计师能够将界面承载不了的信息通过文档沉淀下来,降低项目里的沟通成本和风险.今天整理电脑,翻出以前的

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

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

如何写软件设计文档

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

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

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

设计理念-有关设计文档的分析

设计师无论"点子"多酷.多富创意,难免面对实际"交付物"--交互文档书写的问题.尤其在一些大公司,文档书写的漂不漂亮有时是"Make your work visible"的关键. 实际项目中,文档大体可以分为三类: - 用户需求文档 - 商业战略文档 - 设计文档 用户需求文档主要解决网站为"谁"提供服务,用户是谁?的问题.商业战略文档主要是对产品概念模型.网站主要内容和商业竞争分析.而设计文档的书写才是这里讨论的重点. 首先

传达出设计的“灵魂”——关于设计文档的分析

设计师无论"点子"多酷.多富创意,难免面对实际"交付物"--交互文档书写的问题.尤其在一些大公司,文档书写的漂不漂亮有时是"Make-your-work-visible"的关键. 实际项目中,文档大体可以分为三类:- 用户需求文档-商业战略文档-设计文档用户需求文档主要解决网站为"谁"提供服务,用户是谁?的问题.商业战略文档主要是对http://www.aliyun.com/zixun/aggregation/8780.htm

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

本文是实战每晚构建系列的第三篇,利用第二篇文章中叙述的开源技术对第一篇中的分析模型进行设计和实现. 1.构建信息显示系统的设计 这是一个典型的web应用系统,不过非常简单.根据<面向对象的系统分析和设计>所描述的,设计主要对四个部分进行描述: 问题域的细化:考虑将来实现语言的特性和利用某些设计模式,对分析模型进行细化,并作某些权衡.实现对未来系统"如何做事情"的描述. 人机界面设计:考虑和使用者的交互,对信息显示的布局和接收用户指令或数据的行为进行设计. 存储设计:考虑如何

设计文档的制作经验分享

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