sprint

"罗马不是一天建成的。"

"千里之行，始于足下。"

将一个大问题，拆解成很多小问题，一点一点实现并验证可行性，一个版本一个版本改善，用迭代的思想输出成果。越早交付价值，就越早获得回报。市场瞬息万变，如果一定要把所有问题全都解决才能上线，结果就是迟迟无法上线，胎死腹中。

就像开发会交付一些带有BUG的程序一样，设计也会产出一些带有BUG的设计。评估一个设计结果是不是可以带着BUG交付，有两个参考因素：设计是否解决了需求，BUG的严重程度。

当然，无论是开发还是设计，在前期应该尽可能多方面考虑周全，尽量减少BUG的出现。

ratio

常见、不常见，就是比例。在一些书上的叫法是“关键路径”和“边缘场景”。

工作重心应该放到“关键路径”。不能因为处理边缘场景，而降低关键路径的使用体验。比如不能因为有一些用户不看活动细则就报名参加活动导致一些问题，就让所有用户首次进入时就先收到一个大大的弹框描述活动细则，首屏一个不友好的弹窗会极大降低活动的转化率。

同时，不常见的场景在设计中应该是要避免出现的。以登记出生日期为例，如果采用文本框，用户可能会输入无效的日期，而如果采用下拉框，就能够避免这种边缘场景的发生。

大部分用户和小部分用户，也是比例。想获得最大的收益，就要把重心放在大部分用户中。这在企业产品的设计中也适用，一个高净值客户的需求，不如一个典型用户的需求重要。因为$100 x 1 = $100，$10 x 50 = $500，该选哪个一目了然。

priority

所有的task都可以分出轻、重、缓、急。接到一个task不是马上去做，而是要先规划一下什么时候去做。这跟GTD的理念有点接近，新任务是要先放到待办事项中的。接到一个任务就立马放下手头的事情去处理，只会让自己的时间碎片化，什么都做不好，还越做越多。

不同的ratio也会产生不同的priority。你的目标用户群中很小一部分用户才有的需求，就是低优先级的。

system

一个系统，各个组成部分是相互关联的，牵一发而动全身。交互设计就是在构建用户的使用环境，是一个完整的系统。首先要考虑的，是“结构层”，之后才是“框架层”（具体页面）。在一个页面增加了一个按钮，随之就会产生一个新的页面或者新的状态，同时要确认按钮可用的前置条件，点击后的效果，对后续流程的影响，一切都是相关联的。

这跟建筑设计很相似，都是系统性工程。一个办公楼三层楼高的LED广告屏的位置下移了一点，广告屏的检修通道就会随之移动，尽而影响三层楼的平面布局，家具布置、采光、交通、消防、管道都可能会受到影响。

clarity

less is more.

你想表达的东西越多，别人就越听不明白你要表达的核心概念，因为传递了太多干扰信息。初阶设计师很容易犯的错误就是炫技，采用各种各样酷炫的效果，导致最重要的信息被干扰而无法传递给用户。

data

收集数据，分析数据，评估设计，优化设计，这才是一个良性的循环。没有数据，大家都是睁眼瞎。

用户体验的提升一定会带来某些数据的提升，这些提升可能是转化率的提升，也可能是净推荐值的提升。

在团队有分歧时，最容易解决分歧的工具也是数据。

code

设计要考虑开发可行性，了解一点代码可以让你高效率地利用已有工具，很多交互细节已经被现有的程序框架规定好了，不需要再特别注明让开发同事帮忙实现。

比如在网页中，表单是在标签中，当你在这个表单的任意一个输入框中按下回车时，会自动调用这个中的submit按钮。

再比如，iPhone中一个网页的输入框的type被设定为tel，当其获得焦点时，iPhone会自动调起只能输入电话号码的数字九宫格键盘。同样的还有email、number等。

其实这就是采用了一更大范围的“组件库”。

另外，交互细节有时也会体现在算法层面。比如Google Instant，一堆结果以什么样的规则呈现在面前，让用户满意的结果怎么出现在最前面，背后是靠程序算法计算出来的。

> 本文同步发表：

- 简书

- 个人博客：http://www.guibinspace.com