目录
设计漫谈
前言
全部课程
目录
设计漫谈
相信有不少同学，有在手机上玩过密室逃脱类的游戏的经历。一般这类游戏都会在关卡设定中，参照真实世界的物理模型，为玩家提供一些破解线索。比如在一款名为「密室逃脱·迷雾」的游戏中，当玩家进入到某一幕场景时，就会看到画面的正中部分，有一台虎钳，如果你在真实世界中，对虎钳有相关的了解，那么一定能够发现，图中的虎钳明显少了一根可以使虎钳正常工作转轴。即便是没有见过虎钳的玩家，当看到虎钳中那个充满暗示的孔洞时，也会下意识的在道具袋中，找出那个可以穿越孔洞中的道具进行尝试。
同样，在互联网产品设计中，设计者也会通过经常借助用户的常规“使用经验”，亦或是客观世界的物理模型参照，向用户传递一些“隐含”的信息，通过这些隐含信息的引导，用户便可以更加轻松的完成任务。下面我们就以表单设计中，几组常见的输入暗示为例，加以说明。
输入框是表单设计中，不可缺少的组成元素。用户通过在输入框中输入文字，来完成表单的填写。输入框很常见，但是很少有人意识到，输入框的框体长度，是不可以随意设定的，输入框的框体长度需要和用户可能填涂的文本长度，大体保持一致，不能偏离太多。输入框体的长短设定，可以看做是用户输入时的某种心理参照，他需要贴合用户的填写预期。
在输入框体的选择上，如果单行输入框，在框体长度上，已经可以很好的满足用户的输入要求，那么我们就要在设计方案中，选用单行输入框。如果有大量的文字需要用户输入，并且文本数量远超单行长度，那么我们需要为用户提供多行输入框。
当然，现实的方案设计，可能还会受其他客观因素制约，比如表单设计有严格的高度要求，那么我们就不得不选用单行输入框。在这种情况下，在单行输入框内，提供必要的字数参照引导，也可以帮助用户建立明确的输入预期，减缓焦虑。
在表单信息完善的过程中，我们经常会遇到纯数字内容输入的要求。比如，在某些网银接入类的应用中，需要我们完成银行卡账号信息录入。在一些社交类应用中，会要求我们填入电话号码，在一些应用的注册页，会要求用户填入手机验证码信息，这些输入场景下，我们都需要进行数字输入。
当我们在表单填写中，键入大量数字时，因数字之间无强关联关系，这就导致输入完成后，我们很难借助相邻数字，判定输入结果的准确性。所以，大多数情况下，我们在输入数字时，会遇到多输或是漏输数字的问题。
也正因如此，一些表单的设计者通过使用和数字数量相同的输入框，来帮助用户鉴别多输或是漏输的问题。在这些设计方案中，输入框的数量暗示了需要输入的数字数量，如果两者数量无法一致，那么我们的数字输入一定有错。
现实的物理世界里，我们习惯于找寻不同物体之间的关联关系，通过关系，我们可以更好的理解外部世界。物理上，距离相近的两个物体，我们会天然的认为二者之间存在某种联系。也正因如此，我们在进行表单设计时，会将不同的问题组通过间隙加大，来加以区分。这种间隙的加大，能够让填写者认知到，这属于不同的问题项。而相近的标签和输入框，则暗示了两者的关系更加紧密。
同样，在使用分组线的表单设计中，分组线可以强化不同分组间的区别，借助于分组线，用户会比较自然的意识到，同一分组内的信息，其相关性更加紧密。
在很多表单页设计中，会出现选填题目。当出现选填题目时，为了方便用户理解，我们会在选填标签后使用选填文字加以标识。
后来，随着表单设计的不断进化，设计者和用户之间慢慢的达成了某种“共识”，在表单设计中，通过在标签后缀中使用*号来表达必填信息，而不加*则代表选填题目。这一“共识”对于经常填写表单的老用户而言，并不会产生认知上的障碍。但对于不经常录入表单的新用户则不够友好，尽管很多表单设计中，会在表单的某一位置对*号加以注释，但对比明确的“选填”文案，这种设计显然还不够直白。
在表单页设计中，唯一不可能缺少的构成元素，就是提交性质的命令按钮。在表单设计中，提交按钮常常会被设计成不同的按钮状态。当我们没有完成表单填写时，提交性质的按钮通常为置灰的不可用状态，只有当表单项被逐一填写完毕后，按钮的状态才会变成可用态。用户可以借助动作按钮的状态变化，来判定信息填写的完成度。
在互联网产品设计中，按钮的多态最常见的使用情景，是在某些客户端产品的登录页的设计中。这种登录页通常包含，手机号码输入框，验证码输入框，登录按钮，以及协议勾选框。
有的产品的登录页设计，会将协议勾选框设计在页面的最下方位置，这个位置设定非常不好。因为当我们在完善登录信息时，通常会激活键盘，而这个勾选框正好被键盘完全遮挡，当用户完成电话号码以及验证码输入后，登录按钮仍然保持为置灰的不可用态，用户此时便会发懵，他们根本无法通过当前的页面信息，找到任何的解决方案。
后来，为了避免这类事件发生，有的产品变更了设计方案。比如，当验证码被输入后，即便是用户没有勾选协议按钮，这个登录按钮也会呈现可用态。这样用户就会点击登录按钮，这时键盘会收起，在勾选框位置，就会出现一个勾选同意协议的提示气泡，告知用户需要勾选协议，才能登录。
这种方案的不足之处是，按钮状态明显有悖于编码逻辑，而键盘退出后，仍需要用户通过两次点击，才能完成登录（点击勾选后再次点击登录），这很像是用户做错了什么，然后不得不去改正。
目前，主流的比较友好的设计解决方案是，当用户执行完验证码输入后，登录按钮随即被激活，用户点击该按钮后，会出现一个是否同意协议的弹窗，当我们点击同意后，便可以直接进入到应用的主页面了，用户可以通过一次点击（同意），即可完成登录，这种方案的“完美度”，要好于以上两种方案。
还有一些产品为了避免键盘对勾选协议按钮的遮盖，主动调整了按钮的位置，比如抖音的登录页设计，将按钮至于电话号码输入框上方，这在一定程度上也减少上述问题的发生。
以上六个案例是我们在表单设计中，挑选出的几个带有暗示色彩的设计案例。在互联网产品设计中，通过使用“暗示语言”，来引导用户成功完成任务的案例非常多。这些暗示性的设计“语言”，大都依据用户群体对客观世界的共同感知。
作为设计者，我们需要在具体的产品方案设计中，审慎的对待界面语言，我们应该时刻谨记，正确的设计暗示有益于引导用户完成任务，而错误的暗示往往会加重用户的焦虑。