6 个输入框 ，47 个设计点
“乍一看到某个问题，您会觉得很简单，其实您并没有理解其复杂性。当您把问题搞清楚之后，又会发现真的很复杂，于是您就拿出一套复杂的方案来。实际上，您的工作只做了一半，大多数人也都会到此为止……。但是真正伟大的人还会继续向前，直至找到问题的关键和深层次原因，然后再拿出一个优雅的、堪称的有效方案。” – 史蒂夫·乔布斯
这篇文字只是描述对于简单的三个介面，我做每个设计决策的历程。
设计任务是对以下注册过程的优化，目标是降低注册门槛，让过程高效，平台为 iOS 。
设计分两步走，分别是资讯架构设计和细节设计，细节再从预设状态、填写状态、反馈状态三个角度进行设计。
以下是过程描述：
一、资讯架构。
也就是整理资讯、规划步骤，把需要多用户录入的资讯全部列举出来，然后设定到一个或多个步骤里，形成整个注册过程。
先列出需要的资讯有：[1]
1 通过验证的手机 (也就是手机号、验证码)
2 密码
3 暱称
4 性别
5 生日
原来的密码要填两遍，手机输入太痛苦，果断去掉一遍。
星座本就是由生日推算，放在注册环节徒增操作成本，果断去掉。
技术及运营需求，全部为必要资讯 (也就是必填) 。
接下来就是组织这些资讯，可能的组织方式有：[2]
后选择了这个：
具体是这样：
为什么呢?
从多用户操作流程考虑，我想让入门这一下足够简单 [3]，所以多用户看到的步只有一个要求，输入手机号，关于这个目标，后续细节分析还有进一步的交代。第二步开始渐难，第三步相对难，从简到繁。
那为什么不每一步只完成一个任务，每一步都简单呢? 这样会使得整个流程变得很长 [4] 。后面适当的复杂我觉得是可以接受的，这里动了一个邪恶的小心思，关于沉没成本的原理 [5]，大致就是对 “哥既然已经填了两步了，就再填一步吧，反正只剩一步了” 这种心理的利用。
细心的人也许会问，为什么中间一步是密码和验证码，且后一步没有返回按钮呢? 其实这是一个技术上的约束造成 [6] 。先，对于我们系统来说，手机号一旦验证 (验证码一旦正确提交)，手机号就不能再被使用，而完成注册还得搭上密码，所以验证码和密码得同一个动作提交给系统，不能分成两步，验证码如果单独作为一步先提交，也就是手机单独被验证，中间若发生非常规退出，密码还没填，下次再想注册就会被提示手机已被占用了。其次，在第二步填完验证码和密码后，其实已经注册成功啦，也就是说，多用户在第三步就把应用强制退出，下次回来也能够凭手机号和密码登入啦，当然登入完第三步的基本资料填写还是会等着他，跟他说未完待续。这也就是为什么第三步基本资料没有返回修改密码验证码的入口，看上去怪怪的，但游戏规则就这样，如果您有好办法，记得告诉我。
于是，从多用户操作流程和系统约束双线考虑，得到了这么一个资讯架构。因为介面内容不多，无需框架，直接进入细节设计。
二、细节设计，注册第 1 步 (手机号)
每一个介面都分别对预设、输入和反馈三个状态进行设计。个介面元素少，相对好处理。
预设状态设计如下：
导航栏左侧按钮用 X，代表对注册任务的取消 [+7]，代表这个介面跟上一个介面没有层级关系，当然个人认为这不是很重要，就算是放一个返回按钮，多用户也完全能够理解的。输入框采用左边固定标签，输入域在右边的设计，
因为空间足够，不需要整合输入域和标签，在输入时去除标签，这样感觉更稳一些 [+8] 。标签用浅色 (后面会跟视觉设计师探讨)，输入正文用深色，以表示主次 [+9]，我也想过标签预设用深色，等输入内容时，再相应变浅，但总觉得有些花哨，就放弃了。
提交按钮用大按钮的形式放在输入框下方，标签是 “获取验证码”，没有用 “下一步” 是想给多用户一个更清晰的预期 [+10]，按钮没有放在导航栏右侧，因为字太多，放不下了嘛，而且一个大按钮也显得比较清晰 [+11] 。
原本输入框里的提示文字 “请输入手机号码” 这句废话被我废了，同时也重写了多用户许可协议的入口引导，也是怎么简单怎么写 [+12] 。
输入状态设计如下：
填写就要拨出键盘，键盘要预设拨出吗? 从操作效率考虑，自动拨出比较好，省一步点选嘛，不过我做了一个相反的决定，决定不让键盘预设弹出，为的是整个介面眼看上去，足够简单。作为步，这时我觉得感官上的简单比操作上的简单更重要 [+13] 。因为是手机号码是数字，所以当然要呼叫数字键盘 [+14] 。填写的是电话号码，用自动分段的显示方式，如：138 0000 0000，方便多用户阅读确认 [+15] 。
反馈状态设计如下：
反馈的规则其实是从后面的介面往前做的，因为后面的输入项多，能概括出更适用的规则，所以规则就后面再说吧。至于这个介面反馈的内容，就是对于输入手机号的值进行判断，正确直接通过，不做提示 (或者说介面的跳转本身就是有效的反馈)，若出错，分 “是否为空”“是否格式正确”“是否已被占用” 三种情况对应提示 [+16]，行文稍微诙谐一些，作用也是放松情绪 [+17] 。
三、细节设计，注册第 2 步 (验证码，密码)
预设状态设计如下：
依然很简单，先告诉多用户简讯验证码已经传送到手机号 xxx，特意写多 “简讯” 两个字想把事情说清楚，这个有些纠结，貌似以现在多用户们的 WordPress APP 使用经验，把这两个字去掉也是 ok 的 [+18] 。
在密码下方有一行说明文字 “8-20 位，不能有空格，纯数字的话要 9 位以上”，是密码的输入规则说明，用的是大系统的通行证密码规则，大系统的规则是这么说明的：
我做了两件事情，精简和口语化，特别是 “不能是 9 位以下纯数字”，这句话是典型站在程序设计师的角度说的，而且拗口，所以改成了 “纯数字的话要 9 位以上”，如果您刚好想用纯数字做密码，看，要 9 位以上哦 [+19] 。这也会被用在后面的错误反馈里面 [+20] 。
输入框的标签和大按钮依然延续之前的风格。按钮标签用 “注册” 而不用 “下一步”，试图营造一种这就注册了的感觉，实际上也已经注册了 [+21] 。
输入状态设计如下：
还是不预设拨出键盘，眼不见为净。
验证码当然还是用数字键盘 [+22] 。
密码用英文预设键盘 [+23]，键盘多了一个设定，右下角的按钮，用 “GO”，表示且执行 “提交”，问过研发的同学，尽管是英文键盘，依然可以显示成中文 “前往” 的，但考虑到是英文键盘，“前往” 可能会让人觉得这是中文键盘，还是 GO 吧 [+24] 。
因为密码只输入一次，手机的输入又相对困难，为了更确认自己的密码输入，所以索性预设用明文显示 [+25]，我记得亚马逊 kindle 和小米盒子设定密码的时候也都是预设显示，输入麻烦嘛，如果您真的要在大庭广众下注册，输入框右边有个 “隐藏” 按钮可以切换 [+26] 。
反馈状态设计如下：
这里可以说说反馈的规则了。
规则一、出错的标签视觉区分对待 (变红)[+27] 。
规则二、按下提交按钮后再验证并作出可能的反馈 [+28] 。
输入域少，就两三个，没有定位的大问题，在输入过程中，切换输入域的过程中，所有的正确与否的干扰我都不希望出现。
规则三、彻底解决完一项输入，再去下一项 [+29] 。
什么意思呢? 多数做法是，提交时先针对某一类问题全域性检查一遍，比如是否为空，等都不为空了，再对下一类问题检查一遍，比如格式。这样的结果就是多用户可能因为一类问题，填完一遍表单，又因为另一类问题，从头到尾来多一遍，整个过程在多个输入项之间来回切换。而我不想让切换这个事情导致多用户焦点来回，于是，就做了这么一个决定。先验证个输入域，比如这里的 “验证码”，一定是验证码不为空且正确了，才开始提示下一项 “密码”，也就是：
四、细节设计，注册第 3 步 (基本资料)
预设状态设计如下：
三个控制组件是输入框、单选按钮和时间选择器。
暱称作为比较灵活的输入栏位，我们想给多用户大的自由，也就是 “随便” 输入 [+30]，想来想去，实在想不出为什么要限制字数什么的，以后多用户自然会根据暱称显示的效果决定改成什么名字。为什么前面的 “随便” 要加双引号，因为不是真的随便输入，总不能让您贴上一篇文章来当暱称吧，服务器还要装暱称，load 暱称出来还要频宽，其实这里默默地限制了 100 个汉字/200 个字元，当输入溢位，输入框就会输入不了。但这一切，对于绝大多数多用户来说，是透明的 [+31] 。对了，原版本的提示文字 “输入暱称是为了……” 直接废掉，您会阅读这种文字吗?
性别是单选，一般就是提供两个选项 (也有 3 个的。。。)，为了让注册过程有意思一点点，也好辨认一点点，用图示代替了文字选项，其实这里抄了忘记是哪个应用的 [+32] 。
生日是拨出时间选择控制组件，貌似没什么好考虑的，有看过用输入代替选择的，确实是不用滚动那么麻烦，但看上去复杂，就放弃了 [+33] 。
后这三个按钮都是必填，原版本的设计是，为了高效，预设选择了性别和生日，多用户直接填个暱称，就能提交了，但这样 “必填” 就没意义了，因为将得到一堆无意义的性别和生日。于是预设全部不选 [+34] 。
按钮标签是 “完成”，因为这是后一步了 [+35] 。
输入状态设计如下：
暱称是中文键盘，右下角按钮用中文 “完成”，点选是关闭键盘 [+36] 。
性别单击选择，这里有一个运营规则，性别以后不能再改了。于是在选择后有这么一个动态提示 “此后不可更改” 出现在右侧。为什么预设不显示，预设显示介面复杂度多一分，且可能没人看 [+37] 。单击后以动态的方式出现，从无到有且带动作，多用户的眼神就能被吸引过去 [+38] 。
反馈状态设计如下：
暱称没限制，性别和生日的控制组件又天然限制，所以没有出错提示，只有空值提示，依然采用标签标红，从上到下逐个解决的提示规则，提示设计为 [+39]：
因为是后一步，有一个提交的过程需要缓缓，于是需要一个提示 [+40]，提示的组成元素用了我们系统的标准元素，就不做解释，想说的是文字，不是 “注册中”，而是多用户的暱称，让新多用户感受一丝关怀吧 [+41] 。然后，因为刚才的暱称输入是没有限制的，而我们的标准控制组件有所限制，所以可能超量溢位，对于太长暱称的多用户，只好省略号啦 [+42]，根据我们对存量多用户的暱称观察，这里被省略号的机率并不高。
四、其他补充
注册流程还没有走完，还差后一步，就是提交后到达哪里 [+43] 。注册介面原本设定的触发时刻是 “次启动应用拨出” 或者 “非登入状态使用过程中拨出”，所以结论是在哪里拨出，注册后就回到哪里，延续使用场景。
另外，漏讲了一件事，所有视窗的转场动画 (进入方式)[+44] 。从简处理，就是各种横滑，遵循临时视窗上下滑、层级之间左右滑的规律。也就是步的介面从萤幕下方向上覆盖原介面滑出，第二、三步就从右边滑进来推走原介面，后提交后，介面向萤幕下方滑出。
另另外，关于输入时键盘遮挡的问题也考虑了 [+45]，设计时刻意把内容往萤幕上半部分布局，基本不会出现键盘遮挡现象。如果万一真的遮挡了，在遮挡时是允许介面上下滑动的，滑动时键盘不隐藏，这一招也只对第二步填密码或者按注册按钮有效，第三步的后两个输入项是单选，完成时控制组件早已消失，不可能遮挡。
另另另外，还有两个注册外部介面，但也作为流程的一部分被设计。先是步时的协议详情，临时视窗，点选从下方滑进就好 [+46] 。另外一个是简讯验证码的内容，从简设计为 “[WordPress APP 名称] 验证码 22222，十分钟有效”，十分钟的 “十” 特意使用中文，避免跟前面的验证码阿拉伯数字混淆 [+47] 。
以上就是整个过程的全部设计点，设计的时候当然想过更多的解决方案，自己一边发散一边收敛，后出来原型再跟 PM 过一遍，再修改，终定稿。
终效果如何，还得持续观察，这也不是问题的答案，我想说的只是，把细节一遍遍打磨，打磨到自然，正是设计的乐趣所在而已。