新建 Artboard 之前,你可能还没准备好…

相对于 Adobe Illustrator 、Axure 时代,
如今我们有了更多 fancy 的设计工具帮助我们
更快更简单的绘制精细的设计稿。

我们可以不去辩论「工具决定思维」的对错,但
我们却不得不承认「工具影响我们行为」的现状

原型图(prototype)既是设计方法,也是设计产物。原型图帮助我们探索产品形态,辅助项目内沟通以及用户测试。相对于Adobe Illustrator 、Axure 时代,如今我们有了更多 fancy 的设计工具帮助我们更快更简单的绘制精细的设计稿。我们可以不去辩论「工具决定思维」的对错,但我们却不得不承认「工具影响我们行为」的现状。

如果你上一次拿到需求之后,第一件事情是打开 Sketch ,新建一个 Artboard,那么请允许老司机在此多唠叨几句…

01. 不要着急出原型图

很多不习惯手绘的设计师,通常会在软件中去构思设计的概念和整体框架。但过程中却不自觉得受到对齐、布局、字号、字体等等的影响,花了部分时间调整细节。但其实当前应该聚焦在 high level 的问题上,比如交互模型定义、用户操作流程定义等等问题。

🤔怎么做到?

  • 不要马上深入第一直觉的方案,尝试探索更多的可能性。
  • 试一试白板。当你有了初步的设计想法之后,可以在白板上演练一次。白板笔画不了细节的局限性反而让我们更聚焦在框架上,而非细节,同时白板也非常适合其他成员介入,是交流的好助手。
  • 白板之后,把方案在纸上演练一次,规划好页面布局和 CTA 即可,并且聚焦在核心流程的核心页面,而不是每一个页面。
  • 找 stakeholders 确认目前的产物,保证在概念层面大家是达成一致的,这个之后所有设计的基础。

02. 先理清页面的关系

不要从第一个页面开始设计,因为你很可能不知道整个项目到底涉及多少页面以及有多少页面是可复用的,有多少页面是全新的。在开始画原型图之前,理清页面的关系,抽象出页面的形式,比如「列表页、详情页、促销页」等等。然后找到每一种形式的关键页面着手干活

🤔怎么做到?

  • 可以借助类似 mindnode 这样的信息整理工具,先把可能涉及到的页面做个 sitemap 。这个sitemap 既可以帮助梳理范围,也可以作为自检checklist。
  • 标记出页面的优先级,并按照优先级来合理分配自己的有限的时间。
  • 如果项目过程中有需求变动,也需要及时更新到 sitemap 中,以便后期回顾。

03. 明确每次原型图的保真程度

交互设计过程中,会有很多次和项目成员或需求方的沟通和确认。沟通的目的不同,设计稿的保真程度也应当不同,所以设计师需要明确每一次交付的目的。但很多设计师总是习惯用自己习惯的工具,提供该工具擅长的保真程度的设计稿。

原型图的保真程度:

低保证:黑白线框,仅表现页面间跳转关系及页面内 layout 。

中保真:在低保真基础上,明确每个页面内的具体设计。

高保真:在中保真基础上,适当增加视觉表现效果。

🤔怎么做到?

  • 开始设计之前,一定要明确下一次交付物是为了什么目的。是跟对方探索设计可能性,还是为了获得对方的建议;是为了可用性测试,还是为了跟相关方同步设计进度;是跟开发沟通设计细节,还是跟上级汇报设计内容,或者是别的。总之一定要根据目的需要,去交付不同保真程度的设计稿。
  • 综合考虑时间限制。如果项目着急,请一定确保低保真沟通之后,再进入视觉设计。

04. 确保他人理解原型图保真度差异的意义

做用户体验的设计师都能充分理解,我们会根据目标的不同提供不同保真程度的原型图。但项目组其他的成员或者客户就不一定那么了解了。他们有的会觉得低保真的没意义、不想看,又或者会在低保真上挑细节、抱怨太难看。这些都会严重影响沟通质量和效率。

🤔怎么做到?

  • 在开始你的工作之前,先给项目成员大致介绍下你的工作流程以及过程中的交付物。在每次沟通的时候,也有必要重复申明下本次沟通的目的。
  • 演示原型图之前,也需要明确申明哪些是伪造内容,哪部分信息先不深究等等。

总结一下

开始动手画设计稿之前,一定确保自己对本次项目有了最宏观的理解,并且有了完整的工作计划。确保项目其他成员或客户也非常清楚你的计划,并理解和愿意配合。最后的交付物需要精心设计,确保可读性,确保信息传递准确。

Anyway, design first, then prototype according to a plan. ✿✿ヽ(°▽°)ノ✿

当我们在讨论交互设计时,我们在讨论什么

如果有幸参与一个产品从 0 到 1 的过程,那么我们似乎可以非常明确的认为,交互设计即是画出整个产品的所有页面,并且明确页面之间的跳转关系

但在日常的工作中,交互设计师接触的需求往往多样化。除了 0 到1 的诞生,还有 1 到 1.2 的迭代,以及 1 到 2 的改版。那么在这么多样化的需求形态下,我们讨论的交互设计,又该是什么?

我将需求分为几种不同的类型,并探讨交互设计的价值以及交付物。

类型1:底层数据为主,轻前台页面

该类型最具代表性的,是扩展功能范围类需求。比如 Teambition 自定义字段功能,我们想要在以往的字段类型(文本、数字、单选等)上,增加附件类型。这类需求比较偏底层,轻前台页面。这个时候交互设计的价值是什么,又该交付什么样的产物?

价值:立体表现本次需求的范围,让项目成员能够直观全面的了解需求。

核心交付物:需求概览图

同样以自定义字段增加类型为例,需求概览图如下:

类型2:需求点多,但单个需求点功能简单

产品为了达到一个目的(比如让权限配置能力更加自由),往往会改动多个功能,且每个点改动很小。比如在 Teambition 中,产品想要开放角色可配置的权限,需要涉及 [企业默认角色开放用户编辑、企业默认角色可设置为默认角色、自定义角色可选择所有权限] 等等,而每个涉及到的功能只需要调整一些数据或页面上的点。这个时候交互设计的价值是什么,又该交付什么样的产物?

价值:完整表现本次需求涉及到的功能点以及对用户的影响

核心交付物:Use Case

Use Case 表现的是用户为了达到一个目的,需求做的所有事情以及结果,可参考的 Use Case 格式如下:

类型3:页面级调整

日常中页面级调整的需求非常多,比如调整注册表单、比如调整全局导航等等。我个人最近一次接触到的页面级调整需求,是 Teambition 角色权限配置页。这个时候交互设计的价值是什么,又该交付什么样的产物?

价值:通过页面内信息的重构,实现产品目的

核心交付物:页面信息架构说明及细节交互说明

类型4:0 到 1 的新产品

这类需求对交互设计师的考验是最大的,需要和产品经理密切配合,两个工种的人一起,完成新产品的定义。这类需求的交互文档,可以说是最完整的交互内容了。而交互设计师的价值,我们可以抽象的理解为:用设计的语言,翻译产品需求,让读者可理解。

我个人使用的交互文档涉及到的内容有:

Part 1:需求分析

  1. 产品架构图
  2. 角色表
  3. 需求概览

Part 2:Use Case

基于产品经理给出的 User Story 我们可以拆解出 Use Case。有了 UC,我们就能宏观的理解本次需求对用户的影响。这部分对开发、测试同学都非常有帮助。

Part 3:Wireflow

基于 UC 我们进一步细化出 wireflow。wireflow 重在表现用户为了实现某个目标,需要经历的页面级流程。

Part 4:交互细节

页面内微交互的说明、空状态说明等等,这个老生常谈,不赘述。

Part 5:Demo

这部分视情况而定。Demo主要用于汇报或展示核心流程,或者一些特殊交互形式的演示。

📎交互文档模板下载

最后:

不管是哪种类型的需求,我们交付的交互文档结构应该是完整的,只是允许部分内容留空。

继续阅读“当我们在讨论交互设计时,我们在讨论什么”