本文将讨论如何通过流程化的交互实现用户目标，并处理好任务相关角色之间的互动方式。

当我们在制定设计方案的时候，可能会经历下面这些：

挖掘需求（正在渴望未被满足的地方）->界定目标（解构需求，定义重度、范围以及可行性）->设计功能（实现目标的方法）->结构化流程（定义控件，布局，页面逻辑）->测试可用性->优化视觉

从设计功能到结构化流程这一部分，是交互过程中主要的产出阶段，我们该如何让生硬的功能，转化为用户可以实现的操作，并最终落地呢？
思考阶段需要清楚的三个内容：

特征

设计最终都是为了人而服务，了解你的目标用户，这类人群的爱好，年龄，性别，教育背景，使用环境都会在设计过程中作为参考。例如搜索功能，老人与小孩可能会更适合语音搜索，而年轻人偏向于关键字，那么更多地优化在搜索联想上。

目标

用户想要做什么？用户的目标不一定是表达出来的，但是表达所传递的内容却会映射出真实的目标。
比如一天室友找你借钥匙，得到钥匙可能并不是室友的最真实的目标，它映射的或许是室友希望能够打开寝室的门，又大概他可能只是想取走落在寝室的某样东西，而他拿东西可能是为了完成另外一件事情。
这种动机和目标可以追溯到很长，那么我们如何确立一个正确的目标？可以依据如果确立的目标完成后，是否能够很好的抚平当前迫切的需求，同时需考虑自己当前所处的角色；如果角色是“我”，那么我借出钥匙就能缓解室友的焦虑，而如果我是一位隔壁室友，帮助他去联系有钥匙的人也能缓解焦虑。 因为深入地了解用户的目标，所以快播的单手模式广受美誉。

方式

当目标被确立了之后，应该思考的是用户该通过哪些操作来实现设计的功能，达到目标。
在流程上，清晰，高效，继承习惯，是个人认为比较重要的三点。

• 清晰

清晰的设计能够避免元素间的干扰，每一个元素都应该与它在行为中的重要程度匹配，包括视觉上的主次和以及信息呈现的先后顺序。让用户能够直观的找到入口，并执行操作。

• 高效

整个操作过程都是一个过渡态，用户不是来把玩这些控件的，通过更少的操作，更加快速的完成任务并从操作中脱离出去是尽量去达到的目标。现在的模式中提供了许多了方法。
归类：将复杂的表单中相近的内容归类
切割：对过长的流程切割分步骤进行
隐藏：次要信息的隐藏
默认选择：以及为用户提供默认的选项，从第三方获取公开数据等
但是不应该盲目，保持清晰，脱节的高效“一键完成”并不适用于所有的场景，如果用户不能给了解到自己会得到什么样的结果，留下的困惑会失去对产品本身的信任。

• 继承习惯

我们总是会通过以往的经验来对事物作出行动，对新事物的认识也是基于先前的认知习惯。就像带圆角的Button来源于工业界的实体键，纸质表单中的Check Box和Radio Button，在数字界面的表单中同样得到了继承，更自然的交互方式扩散性和习得性更好，像是手势和语音交互，就是继承了生活中对实体的行为方式。
而离构建产品更近的，是尊重平台，OS，以及同类产品的交互习惯。像是在PC和Mobile上，横向滑动浏览的模式比较少见，但是在TV上，这种浏览模式被广泛使用。（参考阅读：Designing for the Apple TV）同样的Android和iOS在设计语言上也有很多的差异，在对不同平台设计时，必然要考虑到用户操作习惯上的差异。例如“menu”和“pop”这两个控件上的定义和使用方法。最后要说的是同类产品的交互习惯，可能会产生一些争议，因为这多少会被人诟病为抄袭。当下规模前几的电商网站，导航框架和信息结构也相似很多，但是要去理解背后的动机和成因，和几种可能性方案之间的比较差异。拍照应用多会在拍完后选择滤镜；视频网站也会在播放完成后提供相关视频的入口（说到这，就有很多小广告在右上角加一个假的关闭icon，用户点击后并没有关闭广告，而是点进了广告，这也算是继承了一种习惯，但是糟糕透了）；同样是语音搜索的功能，浏览器的激活方式是tap，独立搜索应用多是long press，为什么存在这种差异？分别继承了哪些习惯？将认知上的习惯延伸向更广的区域，更自然，更易于理解。比如QQ在发送图片的时候，可以将图片上滑发送出去，这一个交互方式就点选图片更加流畅。

关联与边界

在刚开始做项目的早期，我常犯的错误就是在做割裂式交互，认为给上原型图，控件布局，标注下button的来源去向，填充内容的规范，就完事了。
单看这一个也没毛病，可用户并不是盯着一个内容转的。他会在整个应用中来回的跳转，犯错，反复操作，成功或失败。过于单薄的交互如果没有覆盖到足够多的场景，会让产品显得乏力，体验欠佳。
注重行为的整体性，交互行为是连续的操作，信息的接收与反馈。当前用户与平台的交换，与其他用户的交换。从发起动作到完成离开的每一步都构想好，才算是比较完整的交互流程。

举一个例子：如果在游戏中，A玩家想要组队，他的流程应该是怎么样的？
可能他会看看周围有没有合适的：

查看附近队伍->申请加入队伍

如果附近没有合适的，可能会不组队，或选择自己发起：

发起组队->邀请玩家

发起组队->接收其他玩家申请

这是A玩家可能需要执行的动作，但在设计的过程中，你需要考虑更多的场景边界，和关联信息的互动。

如果附近队伍很多，是翻页还是滚动加载？

如果附近没有队伍，该不该引导用户去创建队伍？

让用户对列表主动刷新？还是按固定时间刷新？

申请成功了该怎么提示？

申请被拒绝了该怎么提示？允不允许再次申请？加不加限制？

怎么提示有人申请加入队伍？提示呈现的方式是什么样的？

队伍成员已满时该不该自动拒绝？

邀请列表怎么排序？列表中显示哪些内容？

有人邀请了该如何提示？

有人申请了该如何提示？

有人加入后如何提示？

成员离开后的提示？

与队伍相关的其他操作会不会出现干扰？

上面这些列举了很多“提示”相关的问题，给予用户一个正确及时的反馈是一件重要的事情，是希望在设计的时候能够关注到这些场景下，是使用toast，dialog，亦或者action sheet等组件类型都有商榷的地方。将场景尽量的丰富，邀请和被邀的关联角色状态，才可能构建一个清晰的交互。

场景的边界，用户可能会在产品中漫无目的的操作，使用方式可能并不全会按着预想的那样做，虽然这可能会诞生一些有趣的事情，但还是希望产品能够明确自身的作用，做什么与该怎么做。

边界场景是为了让用户处在一个可控，并且可知的环境中。就像当我滑动到了文章列表的末端，显示一条“没有更多了”可以让用户明白继续滑动是无效的，不会有新的文章加载。如果没有这条边界，用户该怎么去辨别是自己滑动位移过小未加载，还是正在加载更多内容呢？

可能边界场景不太容易去体验，但是双11的时候，有朋友特意去观察淘宝天猫京东这些电商的崩溃页和崩溃提示，这也是操作失败的一个边界。边界会将我们弹回到一个可控的地方，比如返回上一页，或者回到首页，确保我们仍在一个安全的环境中。

极限是很多边界场景所处的状态，比如长按发送语音超时。还有全局场景，失去网络连接，未获得权限，操作失败，程序异常（程序异常不算是一个很好的提示，因为用户只会觉得你这个产品真糟糕）等等。

拓展阅读：[UX Patterns of the Future: Anticipatory Design](UX Patterns of the Future: Anticipatory Design)

当你考虑的越多，用户就会思考的考少。

(码字到最后自己都晕了，233)

:)