交互设计模板-如何写一份交互说明文档

上一篇给大家讲了制作交互设计作品集,前期的准备和应具备的内容框架,将自己作品素材已经梳理好的小伙伴,接下来就可以来做核心的作品内容了。

本文将 重点介绍 上一篇框架中 “ 四、作品集主体 ” 这一部分的内容。

交互设计作品集, 注重的是思维逻辑 ,将自己作品案例罗列累计显然是不明智的做法,一方面无法聚焦你的优势和专业能力,另一方面读者也会产生思维疲劳。好一点的做法是,将自己的专业能力和掌握的专业知识分解,然后映射到对应的作品案例上, 每一个作品重点突出你的某一项能力 ,然后 整个作品集是你的综合体现 。

下面我讲一下在不同的案例中,应该是怎样的框架,都需要透出交互设计上的哪些知识点。

要点:交互设计所涉及的全流程个环节完整、每个环节不必特别详细,一页表达清楚即可,但前后逻辑关系要严谨。

知识点框架:透出内容之间的衔接、上下游的因果关系突出,是整个案例要表现的。

举个栗子为了大家理解内容的衔接,给看一个只有逻辑内容,没有视觉美化的案例:

以上是让人知道,你逻辑严谨,且可以跑通全程的。即便拿一个普通的作品来做也没有问题。

要点:突出对用户调研和可用性测试的专业性和完整性、研究结果利用的合理性。

①项目背景:简单描述,提出项目价值或问题。

②用户研究(完整展现知识点):前期准备、用户样本分类及特种、访谈或问卷提纲构建、数据分析、调研结论。

关于用户调研。可查看文章: 《了解用户:调研的定量与定性》 《用户体验之定量调研:让问卷无可挑剔》 《用户体验之定性调研:让访谈物尽其用》

③需求分析:建立用户角色、分析目标用户特征,得出主要用户和次要用户,确定产品定位。

④需求解决方案:简单阐述产品定位,和核心界面的线框图即可,这一环主要是为了下一步可用性测试来起到衔接作用。

⑤可用性测试:测试前准备内容、启发式评估原则及结论、测试方法(发声法/观察法/AB测试/眼动测试等)、测试结果、分析后结论、修改建议。

⑥产品最终原型:是经过改良后的产品方案,要体现出可用性测试的结论。

作品集的展现上需体现出以下具体内容。用户调研相关可视化框架模板,供大家参考:

要点:突出对流程和界面布局方案的思考、原型设计方法和修改。

①项目背景:简单描述,提出项目价值或问题。

②产品定位:呼应背景中提出的项目价值或问题,给出相应产品定位描述、目标用户和典型场景,1~2页概括即可。

③功能架构分析:根据产品定位给出需求转化模型、功能优先级、产品整体功能架构。

④任务流程分析:根据功能架构,给出详细的流程分析图,定义每个功能任务。

⑤界面信息布局:详细的界面线框图、流程引导、注释说明。

⑥交互规范和视觉效果:控件规范、文字规范、色彩规范。

体现在页面上的可视化框架如下:

界面原型设计最完整的作品,适合在这一案例中表现,同时这也是一个设计师的基础核心能力。

要点:一般选用已经面向市场的产品,提出当前问题后,阐述解决方案,突出服务设计理念的完整性,或运营前后的用户变化程度。

①项目背景:简要概括项目背景,一般是已经面向市场的产品。

②市场分析:利用SPET、波特五力模型、SWOT分析、5W2H等分析方法,得出市场现状。

③用户旅程图:用户从使用到结束完整的旅程,写出每一阶段的描述和遇到的问题。

④需求痛点分析:梳理用户核心痛点、设计机会、得出机会所转化出的功能、功能优先级。

⑤商业模式分析:商业画布(合作伙伴 关键业务 核心资源 价值主张 客户关系 渠道通路 成本结构 收入来源)。

⑥服务设计/运营方案:商业拓展方案、服务设计蓝图、或运营推广方案的模型图等(围绕之前提到的痛点和商业模式来进行可视化展示)。

⑦市场效果:设计或运营方案应用后,市场的反馈数据,活跃度或粘性的增加等(如果没有实际数据也可以不写)

对细节问题的处理、微交互、相关设计原理或方法论的利用等。不必是完整的项目,可以是某个小环节,作为专题的形式来展现,证明你的细节处理能力。

如以下案例:

6.1 数据信息可视化

通过你作品集每一页的信息布局和图形表达来展现,因为原本你作品集上的每一页,应该有很多的文字和数据来传达,但为了他人更轻松易懂的看明白,你需要以可视化的方式表现。所以你的作品集在无形当中就已经在透出你这方面的能力。

关于信息可视化的一些技巧:利用方法论模型、利用数据表、场景故事化、关键字突出法

作品集信息可视化的一些常见问题:

6.2 沟通与话术构建能力

作品中总会有无法用可视化表达的内容,你每个项目中的介绍和注释描述,都去简化和推敲,你精准的文案表达就会体现出你的沟通与话术构建能力。

6.3 审美感知能力

作品集的封面与内页的装帧设计、每一项目的首页设计、每一页中的排版布局设计,将是你视觉审美设计的体现。

所以:

1.在制作作品集之前,找准作品集视觉风格,包括配色和图形特点,再开始制作;

2.在制作过程中随机调整图文;

3.作品集初稿完成后自查,统一各级标题与文本的“字体、字号、字色”,校对图形的主体色和辅助色,精简多余的装饰性视觉元素。

但要注意,这里的视觉效果还是以提升你作品集的可读性为主,装饰为辅。让人在阅读时把注意力放在你内容的逻辑上还是最重要的。

6.4 复盘思考能力

在每一章节或项目结尾,对项目核心所展现的能力进行总结。该总结应该重点放在知识点的运用梳理、方法论的理解、或某个问题的顿悟,尽量避免主观的情感表达。

以上就是交互设计作品集制作的全部流程和方法论,你get到其中技巧了么?

关于如何写背景分析,可查看文章 《项目背景分析怎么写》

关于用户调研。可查看文章: 《了解用户:调研的定量与定性》 《用户体验之定量调研:让问卷无可挑剔》 《用户体验之定性调研:让访谈物尽其用》

1. 前言

目前常用的前端框架为 Angular与Vue,个人觉得长久累积下来Angular 对于日后变化与表现会比Vue来的更佳,Vue虽然对于前端工程师较为方便好上手,但对于设计师维护两种设计规范是不大现实的,设计师只需要依据公司内部使用的前端框架维护一套设计规范即可。

接着开始介绍一下我长年使用的规范,一开始也是针对 Vue 设计,基本的设计规范可参考 Element 饿了吗即可。设计师一开始应该如何设计"设计规范 ( Design Guidline )"呢? 我对于规范当中的设计理论大多也是参考饿了吗为主,在参照其他公司的设计规范,依据自身公司内部的需求提取所需要的部分,先搜集完后在提炼,并且在日后维护继续修正调整。

2. 设计规范的目的

设计规范(Design Guideline)通常负责的为 UED 部门,国外一般也称"设计语言Design Language",目的在于减少企业内部设计师重复劳动,并且提高设计师工作效率,帮助设计师能有更多的时间着重在思考、构思业务身上,在一定的基础上,设计师只需按照规范执行,透过设计规范公司的产品也能有一致性,包含交互行为、界面风格,最理想的状况下是衍生出自身的企业品牌,并且深刻于用户心中。所以设计规范不仅是一套规矩,肩负某种程度上公司能宣传的优势之一,尤其对于 B 端企业来说,一套能完全符合业务场景的设计规范,是经过不断的打磨与修正调整,能够扮演着教育客户角色,当然能够是服务于业务场景才是称得上好的设计规范。

3. 设计规范应用理论

原子理论 (Atomic theory) 为整套设计规范应用的基础理论,主要是由小的元素一步步堆叠成的最终页面等级的模板,透过长期的积累,不仅能从 交互视觉达成一致性 ,慢慢演化成模板、页面甚至是整个操作流程,这样设计师就能 高效地运用常见或者制式的流程 ,从而帮助设计师能有更多时间考虑交互上的细节,另一方面也能帮助设计师们 协作一个软件或多个软件时,能有统一的规范参考 ,背后隐藏的深意是透过不断的累积,进而形成互联网公司独有的产品特色或产品交互流程;当然以上是非常理想的状况下能够达成的目标,实现这些目标的基础也是端看设计师与前端工程师必须对规范有很深入的了解与熟悉,才能达到一致性、清晰、高效的理想境界。以下是原子理论的一些解说与图示:

原子(Atoms):符号,为页面构成的最小基本元素。如颜色、字体,或是图标等;

分子(Molecules):组件,由原子构成的简单 UI 组件。例如文字按钮,结合文字、按钮与图像,形成一个独立的分子;

组织(Organisms):模块,由原子及分子组成的相对复杂的组织,在页面中可视为模块/样式层级;

模板(Templates):原型,将以上的元素进行排版,显示设计的底层结构,在设计中对应的是原型图层级;

页面(Pages),将实际内容(图片、文章等)套件在特定模板,页面是模板的具体实例。

4. 设计目录

1. 规范简介

2. 规范原则

3. 设计视觉

4. 组建规范

5. 设计模式

6. 附录:规范文案

参考链接:

饿了吗

Angular (左下方有各大厂应用组件)

Angular for Material Design

Uber

google

Apple

SAP

交互说明文档,是交互设计师 的输出物中必不可少的一项,它关系着设计方案能否最大程度的被实现。交互新人,大多会烦恼如何写交互文档,今天来聊聊这个话题。 交互文档,写给谁看 交互文档可以看做交互设计师 输出的”产品”,它面向的”用户”是下游的同事——视觉设计师、测试工程师、开发工程师。他们会根据文档中的线框图、交互细节说明等等,来输出视觉设计稿、写测试用例、用代码实现产品设计方案,并以此为依据完成验收测试等工作。 交互文档,写什么内容 最初写交互文档时,很多人会有疑惑该写些什么内容。我的看法是,开发同事在写代码时需要考虑的与界面显示逻辑、用户操作相关的内容,几乎都要在交互文档中体现,建议越全面越好。 如果有遗漏的内容,开发可能会找你讨论,也可能懒得费时间沟通直接按照自己的理解去实现。最终,验收测试的效果不如意,你也不能全赖开发。所以尽量将交互文档写的全面些,别消费开发同事对你的信赖值。 那么,到底交互文档中,需要写哪些内容呢? 1、页面流程(界面之间) 页面流程图,可以表达产品的整体结构,帮助同事了解界面之间的关系。在撰写交互文档时,也可以以任务、子任务为模块来详细介绍界面如何跳转、何时跳转。 2、内容布局(界面内) 正在加载状态、加载完成有内容的状态、加载完成无内容的空状态、失败状态(比如网络异常/权限未开启)、不同角色的用户看到的内容是否一样、不同状态的文案图标变化 内容的加载方式,何时加载、何时显示、何时刷新 其他 … 3、交互操作与反馈(界面内) 根据用户与界面之间发生的交互操作,提供相应的反馈,可能是提示内容,也可能是界面内或界面之间的跳转。 刚入门的交互新人,喜欢把重心放在界面之间的跳转,而遗漏了界面内的内容布局和交互操作。对此,我的小技巧是,先整体看界面全局,再review界面上的每一个元素,思考各种不同场景下这些元素是否变化、如何变化。 以登录界面为例,看看怎么写交互细节说明 下图,是一个简单的登录界面,我们试着先整体后部分的方式,看看这个界面的交互说明需要考虑哪些方面。 1、登录界面的跳转流程 什么情况下,从哪些界面可以进入登录界面 登录成功后进入哪个界面 取消登录后回到哪里 界面转场方式,比如从下向上进入界面,从上往下离开界面 2、账号输入框 字段格式要求,字段长度、字段类别(汉子、字母、数字、手机号) 是否有默认提示文案,如果上次登录过是否显示上次的账号 光标是否置入此输入框,键盘是否显示,键盘用哪种视图 何时检测用户填写的是否正确,填写正确的提示,填写错误的提示,反馈提示何时显示、何时消失 输入框中的内容是否支持一键清除 3、密码输入框 字段格式要求 何时检测格式是否符合 光标置入后显示键盘的哪种视图 输入框中的内容是否支持一键清除 是否支持密码可见、如何切换可见状态 4、登录按钮 按钮是否有可用不可用之分,何时可用状态、何时不可用状态 点击按钮之后提示正在登录的方式 登录成功如何提示、跳转进入哪个界面 有哪几种登录失败的场景(比如账号未注册、网络异常等),不同失败的情况下如何提示 多次登录失败提示方式是否变化 5、注册按钮 点击进入哪个界面 界面的转场方式是怎样的 6、关闭按钮 点击进入哪个界面 界面的转场方式是怎样的 以上只是抛砖引玉,给大家打开思路。虽然只是几个输入框,但其细节比大多数界面都要复杂。你可以找一款优秀的APP,去研究它如何设计这些细节,是否还有我没有提到的点,研究透了下次自己设计才能做到更加全面。 当然,交互细节说明,只是方案的表述,每一个小点都有好几种设计方案。如何权衡选择体验更优的方案,才最是考验交互设计 师的能力。你可以对比研究几款优秀产品,看它们在细节设计有何不同,分析其中的缘由,想想是否有更好的方案,学无止尽。 如何提升交互文档的浏览体验 交互设计 师的目标是提升产品的体验,我们输出的文档本身也应该有上佳的浏览体验。为了达到这个目标,我也在不断优化文档的撰写方式和排版。下面聊聊我尝试过的几种方式。 方式1:一页纸表示所有的线框图,配上箭头+简单的文字说明 网上流传着很多这种风格的图,最初觉得这样的图很有范儿,以为这就是他们输出的全部交互文档,所以按照这种模式产出。等到自己做的多了会发现这类图大多只表达了某个界面的正常状态,并没有详细的交互说明来体现界面的内容布局和交互操作反馈。 方式2:一页一个界面,每个界面建一个交互说明文件夹,分功能模块写交互说明(Web产品) 工具: Axure Web产品的特点是,层级复杂,每个界面比较大而且内容很丰富。通常会组织好页面层级,再画每个界面的原型,待几轮讨论过后界面布局和内容基本确定之后,再为每个界面撰写各自的交互说明。 考虑到每个界面中的内容模块和功能点不少,我没有在确定好的界面上直接标注交互说明,而是将这个界面划分为几个功能模块,并给每个功能模块新建一个页面用来写交互说明。 如下图,分别是 Axure的文档目录(左)、某个功能模块的交互说明(右) 方式3:一页显示一个大功能点的所有界面和交互说明(App 产品) 工具: Axure App相比Web界面内容简洁很多,很多人输出App的交互文档都是一页展示很多个界面,上下左右排满了。设计师大多是大屏电脑,这样设计起来确实比较连贯流畅。 但是开发大多用MacBook,没有外接的大屏显示器,一屏看不到几个界面。虽然我会按照横向主流程竖向次要或分支流程的规律排列,但是他们对这些规律并不熟悉,左右拖拽上下滚动几次就容易犯晕,可能一会儿就找不到刚看过的界面了。 如下图,界面右侧配上对应的交互说明(通常情况,交互原型应该以黑白灰颜色为主,不过因为我们的APP处于迭代优化的阶段,已经确定了视觉风格,而且某些状态需要用颜色来区分对错,所以会有一些配色。) 期间优化过这种方式,将大功能点拆分,按照以往设计Web 产品的方式来组织。对此开发同事仍然觉得不够好,所以有了后面ppt/keynote演示文稿的方式。 方式4:一页介绍一个子任务,每页最多4个界面,输出PDF格式(App 产品) 工具: Axure 画原型,Keynote 写交互说明 为什么采用这种方式呢?源于开发同事看到产品老大介绍需求用的幻灯片,觉得一张图配一个表格的方式很清晰,强烈建议用这种方式来写交互文档。 我觉得用幻灯片输出PDF 的方式确实可取,易于浏览。不过一页一个图太零散,界面之间、界面内容的不同状态关键性很强,放在一起介绍更直观。 于是,我想到了以前 yoyo 在腾讯CDC 官方博客上分享的交互文档撰写方式:《如何制作实用美观的设计文档》 。以前尝试过用他推荐的indesign写文档,但对这个工具不那么习惯以至于效率并不高,尝试过写完一个产品的交互文档之后就没再用了。不过 yoyo 推荐的将大故事拆分为一个个小故事来写交互说明的方法让我记忆犹新。 就这样,尝试了这种新的搭配方式,Axure 画原型,Keynote 写交互说明。 Keynote缩略图预览如下图,为每个功能模块建立一个任务/子任务的目录结构,按照划分的结构依次介绍各个子任务。每个页面最多介绍四个界面,页面底部作为固定的区域用来写交互说明。 测试、开发同事反馈这种方式不错,一方面是因为每页文档的结构大小一致,滑动浏览的体验也更好;另一方面是因为他们写代码也是按照这样的方式一个小模块一种场景依次往下走,更容易专注看当前写的这个模块的交互说明。 虽然有同事的肯定,但这种方式还有优化的空间。因为采用了两个工具,一个画原型一个写文档,如果Axure原型有改动,需要复制到keynote,两处都要更新显然影响效率。所以我还在考虑是否切换到某一个工具搞定这两件事,比如用sketch 。除此之外,文档模板也可以改进优化。 就像前面说的,交互说明文档,就像是交互设计师输出的产品,既要根据场景的变化不断调整,又要听取用户的意见,持续优化提升体验。