对于设计师而言，移动端设备屏幕上的每一寸空间都是宝贵的资源。为了在小屏幕上做更多的事情，设计师在设计导航系统的时候，通常需要花费更多的时间来打磨。汉堡图标在过去几年当中，是最常见的一种设计策略，导航和选项被隐藏在这个小小的图标之后，但是实际上，虽然大众已经习惯了它的存在，但是它并不是最佳的导航设计方案。

在今天的文章当中，我们会探讨为什么汉堡菜单这样的隐藏式导航影响用户体验，以及可用性更强的替代方案。

为何汉堡图标会破坏用户体验

在移动端设备上，我们看到的可见式导航其实比汉堡图标这样的隐藏式导航更多，前者大概是后者的2.5倍。

相信很多体验设计师在与产品需求方进行设计提案的时候会遇到这样的情景：

• 你阐述自己的设计推导过程，从产品目标分析、问题定位、设计目标分析、设计思路阐述这样的推导下来，在场的产品经理们都点头，表达认可。
• 但是！当到了设计方案环节，你把方案放出来，各位就七嘴八舌挑战了：￥#@%&*&*
• 这时候经常会听到这样一句话：“有没有其他更好的方案啊？”
• 这时候你是不是会想，我前面的推导和演绎过程那么完美那么富含逻辑，推导的肯定是最好的方案啦！

但是哦，这个时候，你还是会感觉没底气说出这句话来。

于是你最后说出一句妥协的话“好的好的，我回去改一下。”（各位老板我都听你们的，你们说啥就是啥）

专业度呢？设计价值呢？你的玻璃心要碎了：死了产品经理们会不会觉得自己很水很不专业。

怎么办？这就是今天想聊聊的主题：“思维框架”理论，让我们更好地决策和解决问题。

语音交互是一个全新的体验设计领域，目前各家机构、公司、设计组织还处于摸索设计范式的阶段，Google提供了一份非常成熟、系统的交互规范文档，其中包含了核心概念的诠释以及诸多可以指导设计的实践原则。最近正在做的项目中涉及到语音交互的部分，所以顺手将这份文档翻译出来，给需要的设计师参考。

我的译文尽量的贴合文档中原有的表意，同时基于我个人对语音交互的理解对表达文字进行润色。其中有个别概念名词比较抽象，所以我也旁边附上了英文单词，以便大家理解。

我们正在进入一个有光明前景的全新计算领域，机器学习和人工智能激发着对话式界面和自然语言的进步，同时使对话式交互成为一种新的交互模式。

交互思维是什么？网上的搜索结果大多是一些交互设计的方法。但是我这里要讲的，是真正做交互设计所具备的思维方式。交互设计在国内发展的并不成熟，还有很长一段路要走。很多人，甚至包括交互设计师自身，对这一工作的性质和价值都未必有足够的了解。

交互设计，听上去是“设计”，但是其本质和常见的UI和视觉设计相去甚远。“交互”指的是人类与机器之间的沟通，与美学、界面、按钮什么的，其实没有半毛钱关系。领域细分之前，也许我们考虑的东西越多越好，但是在细分之后的今天甚至未来，交互设计就要有它不一样的价值。

由于目前的大环境对这一细分领域仍旧缺乏了解，所以我希望在这篇文章里，写几个做交互设计所需要的思维方式。

1. 先理解什么是业务需求、目标、目的

1.1 什么是业务需求

业务需求是企业为了达到某些目标和某种目的而制定的。它代表着企业希望下一轮产品的迭代能带来什么收益，所以企业和 PM 在制定需求时必须谨慎且方向清晰。在工作中，交互要分析拿到的业务需求是否合理，所以就要理解在业务需求中的一些基本元素：

• 需求定位：产品或用户，还有企业战略
• 需求类型：功能类、数据类、设计类等
• 重要性：重要、暂不重要

拿到需求首先就要分析，定位是否清晰，属于技术类、数据类、设计类等中的哪一类，筛选所有需求中哪个更重要，然后再去做相应的工作。

1.2 什么是业务目标

导语

随着各类App的业务功能不断丰富，小红点已经成为互联网从业者们最常使用的运营工具之一，每当有新的运营内容或新功能上线，大家的做法往往是“在那放个红点就行了”。然而简单粗暴的形式以及不加节制的投放，让小红点变成了人人厌烦的“小妖精”。本文从设计的角度出发浅谈小红点的一些设计细节，期望引起大家对小红点的关注，在这里抛砖引玉，也期待感兴趣的小伙伴一起探讨。

烦人的小红点

人类似乎天生对不对称，不和谐的事物有厌烦心理，并且想要去纠正这些“错误”，简而言之就是大家平时所说的“强迫症”。而小红点则完美利用了这一人性的弱点，它就像白嫩脸颊上长出的一颗小痘痘，让人忍住不去要去挤破它。因此，小红点也成为了一把产品运营利器，只要投放在某个业务入口，就几乎没有用户会对它熟视无睹，而当用户忍不住要去轻触消除它时，产品侧为业务导流的目的也就达到了。

那么问题来了，用户喜欢小红点吗？在Google和必应上搜索关键词“App 小红点”，几乎有一半的搜索结果是“教你如何消除小红点”。

在过去的几年当中，网络上所流传的各种设计和开发资源，在素质上有明显的提升。其中有一些已经几乎成为了设计师和开发者必备的工具，但是其中绝大多数由于其应用范畴的局限，或者传播不够广，导致它们大多并广为人知。将这些素材集中到一起，很大程度上是希望它们的目标用户能够明白，需要这些工具的时候，上哪儿找。

这次的前端干货合集内容也很齐全，仔细看看，总能找到几款你所需要的。

MuzzleApp

表单设计中，各种设计模式和技巧已经越来越成熟了。在诸多设计技巧当中，悬浮标签这一设计手法，应该是对于用户体验提升最明显的一种。早在2013年8月的时候，我第一次考虑在自己设计的表单中运用悬浮标签，这个想法很简单，在占位符文本中，借助动画加入一个图标显示，确保用户不会在填写过程中迷失。

不知道大家有没有这样的情况发生，自己设计的作品，“乍一看不怎么样，仔细一看，还不如乍一看”！

其实不耐看，或者不敢放大看的原因都是细节做的不到位。

最近在做手机OS的主题图标，对细节的感触很大，今天结合主题图标来和大家聊聊，我们可以从哪些方面注意自己的设计细节，大纲如下：

• 给造型加点细节
• 多加点质感的细节
• 不要让图标看着灰灰的
• 风格特点的运用

1. 给造型加点细节

造型是所有设计执行的第一步，造型做不好，说别的都没用。

那如何能给造型加点细节呢？

打个比方，我们要画一个圆角矩形：

如果您想订阅本博客内容，每天自动发到您的邮箱中， 请点这里

很多设计中，我们付出20%的精力就可以应付80%的 Normal Case，而剩下20%的 Special Case 却会花费我们80%的精力。换言之，普通情况谁都会处理，而为了应对一些少数派，我们将要付出更多。

Loading 失败时的错误提醒、搜索无少结果时的空白页面、打了车却没车接单……除了这正常流程下的失败反馈以外，最耗时间的是那些特殊流程或所有情况同时在一个页面堆砌出现的情况。

在设计前期，我们就应该尽可能地罗列特殊情况，即便它们出现的概率很低，也应留足设计时间。而应对非常规 Case 时，有一条原则帮了我很多次：

确保多数人体验的前提下，才去解决少数人的问题。

这不是说要为了多数人放弃少数人，还是造例子来说吧。

案例一：重复利用的物流单号

如果你在天猫有过退货经验就会知道，申请退货并得到商家确认后，需要填写退货的物流单号，当商家收货后才会把钱退给你。这里有个奇妙的问题，设计上是否允许多个用户填写同一个退货单号？

先来看看如果允许，会出现什么非常规情况：消费者AB两人各自在同一个商家C处购买了两台 iPhone，并且商量好分别发起七天无理由退货流程，商家C均同意。然后，消费者A先将手机按要求寄出，获取物流单号一个后填写到退货系统；同时，消费者B直接使用消费者A的退货单号填入系统，但不寄送自己的手机。

极端情况体现在，许多商家的店铺与仓储是分开的，当仓库收到A寄来的手机并确认收货后，店铺工作人员收到系统通知两个退货流程都已收货（其实是同一个单号），若不进行额外确认，就会把钱都退回去了。

再来看不允许重复填写同一个物流单号的情况：很简单，AB两个消费者是好人，但希望节省快递费，就商量好把两个手机放在一个包裹里寄回。此时若规则只允许一个单号只能填写一次，这种做法就无法实现。

错误的设计方法是这样的：用户填写退货单号时，新增一个流程询问用户该单号是否只关联了一个订单，订单号是多少；或者在原有基础上新增一个联合退货的功能，让多个用户合伙拼单退货。

正确的设计方法是这样的：消费者端流程全部不变，允许重复填写物流单号，但必须在后台记录一条单号被使用的次数。对于被多次填写的单号，在商家端告知商家须额外注意，一定与仓库确认好包裹内物品再进行退款操作。

错误方法的错误原因很简单，我们不能为了一些极端情况就去修改主流程，也不能为了少数人的需求就影响所有正常用户。

案例二：互相冲突的 Toast 提醒

天猫客户端的商品详情页中，当点击“收藏”按钮会有一个 Toast 告诉用户“收藏成功”，同样当点击“加入购物车”后，也会有 Toast 告诉用户“加入成功”。这样看好像没什么问题，但若用户点完“收藏”后马上点击“加入购物车”，就会出现两个 Toast 相互冲突的情况——视觉上互相重叠，或后一个 Toast 无法出现。再极端一点，如果出现了一个脑残用户，为了测试反复快速点击两个按钮，甚至会导致代码错误。

为了追求设计和代码逻辑的严密，我和开发同学花费了不少时间讨论对于这种极端情况，要如何设置 Toast 的出现和冲突机制。甚至为了应对极端情况，还需要调整 Toast 出现消失的动画过程与逻辑。但最后，我只设置了2个 Toast 在极短时间内前后触发的交互，也就是新的 Toast 慢慢把旧的推上去，并各自做淡入淡出动画——毕竟两次短促的操作是比较可能会发生的。

什么？你问我那个脑残用户怎么办？不好意思，为了满足所有正常用户的诉求，脑残用户的体验就只好先放一放了……

案例三：神出鬼没的 Loading

我们在客户端上做了一个比较酷的动画，对一个模块长按后可以弹出一张卡片，并在卡片中阅读一些详情（有点像 3D Touch）。问题在于，弹出卡片中的信息是触发卡片后才向服务器请求数据并加载的，正常情况下没有问题，但是弱网条件下，数据加载可能会花费不少时间。为此，第一版我们为这个数据请求设计了一个 Loading 的小动画（好吧，你就当是转菊花）。

这样做的结果是，对于网络非常流畅的用户，他们唤起这张卡片时，会看到一个菊花飞快地闪过，然后才看到数据加载——再流畅的网络下，数据也需要加载时间，哪怕是1ms，都会让菊花快速闪烁。

当然，不要 Loading 也明显不合理。弱网条件下，必须避免用户盯着空白的卡片发呆而不知道系统正在干什么。

所以，合理的做法是，为 Loading 动画的出现时间设置一个延迟：在卡片弹出的200ms内（卡片不可能突然闪烁出现在用户面前，必须有一个进场过程），如果数据加载完毕，则不显示 Loading 动画，直接显示数据。如果卡片进场完毕（200ms后）数据还没回来，则开始显示 Loading 动画。

这样，我们保证了正常用户的正常体验，避免他们每一次操作都为弱网这一极端情况买单。同时，也保障了弱网用户的体验。

最后，再总结一下我们的设计原则：确保多数人体验的前提下，才去解决少数人的问题。

蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务