交互设计实例之文本框交互分析

    当交互设计师完成一份自以为详尽的交互输出物，前端的开发结果总是不那么另人满意。交互会抱怨：为什么会做成这样呢，很多常识性的东西也会做错。显然因为领域不同，对“常识”的理解不尽相同，我们不能把希望寄托在前端工程师的可用性觉悟上。所以交互设计师必须站在对方的角度，在提交输出物前补充交互细节，以免日后不必要的迭代。

    下面是一张PM提供的自制电商卖家客服系统的原型图：

    

    图中将必要的信息架构已罗列完毕，看似可以直接提供给技术进行开发了，但如果这样做可能会产生很多的问题，比如图中客服昵称的点击触发时的样式是怎样的呢？是不是有什么限制？发生错误时该怎么办呢？

    在很多没有交互设计师的团队中，这些问题需要产品经理自己来思考，如果产品不思考，就会将这样问题丢给技术来思考，如果技术不思考直接进行开发，那么就会将问题丢给用户来思考，等到让用户来思考时，这款产品的体验可想而知该有多差。

    说好的“Don't Make Me Think"呢！

    那么我们该怎样来对这个小小的文本框进行设计和处理呢？

    先不急着下手来设计，我们先思考下这个产品的针对用户以及用户可能会出现的场景：

    用户群目标：使用该电商服务的卖家人群，希望能够借助该系统进行客服的设置和管理。

    那么再回头看看这个原型，一个客服管理的页面，除却主导航的部分，可进行编辑操作的当前区域只有对客服的昵称编辑。

    

    在网页上对该页面进行操作的逻辑一般会是如此：

    编辑客服昵称—点击保存/取消按钮—结束。

    很简单的一个逻辑，但站在用户角度在对客服昵称进行编辑的时候却可能出现以下的场景和问题：

    1.我该怎样得知现在可以进行输入编辑了呢？

    2.编辑昵称时发生错误该怎么办？

    站在技术开发整理数据库的角度来思考，又会遇到以下的问题：

    我们对昵称的字符有规范，超出字符我们可能无法记录名称，还可能会引起其它的问题，所以我们需要对字符进行规范。

    UI同学则表示如果不进行一定的规范制定和限定的话，她们的工作将会出现很大的障碍，对于千奇百怪的各种长度的昵称，设计和整理将极具挑战。

    产品君还需要投入到产品的大方向中，这些细节都是需要你——我们的交互同学需要考虑到了。

    那么我们整理下用户的操作方式以及场景问题、开发和UI提出的可能性问题，总结出以下文本框编辑时的几种情况：

    1.鼠标点击—激活文本框的样式（需要提示用户现在已经可以进行输入了）；

    2.键盘输入—改变文本框的内容（根据用户的输入内容和性质决定是明文还是暗文显示）；

    3.错误提示—文本框内容不符合规范时（需要及时发现不规范的内容和原因，防止用户进一步发生错误）；

    4.正确提示—文本框内容符合规范时（让用户明确目前的操作进度和正确性）。

    然后针对这四种情况进行细分并提出对应的解决方案，确保用户在场景中的感知符合自身的心理模型，也要确保业务逻辑的完备。

    为了便捷的工作效率，我们直接在原型图上进行标注合理的文本框样式：

  如果这样看上图并不够直观和具备交互性的话，附上了可以进行点击操作的Axshare文本框交互（含WEB昵称编辑文本框、PHONE昵称编辑文本框和WEB公告板的交互）链接和RP源文件，诸位同学以后在进行类似的设计时可以将该交互控件直接调用演示。

  下面是Axshare的链接：http://ymrdsh.axshare.com/#p=输入框交互设计

  

  现在针对常见的WEB文本框交互进行详解：

  一.默认样式：文本框和按钮置灰，暗示用户当前为无编辑状态。

  二.激活样式：文本框高亮（颜色可由UI来配），表示已被激活，但因为无输入内容，所以按钮依然置灰不可点击。

  

   三.错误提示：当文本框内容为空或超出限定的字符限时，文本框变为警示的红色，下面出现错误发生的原因，按钮置灰不可点击触发，避免用户继续进行错误的操作。

  四.正确样式：当满足文本框内容不为空且小于10个字符时，文本框仍保持绿色激活状态，且按钮为启用状态，表示随意可以点击保存。

  整理清楚以上的逻辑后，将交互稿交付给开发和UI同学，他们就可以HAPPY的去进行下一步的工作了，而对于我们的上帝—用户们，仅仅这些还是不能够满足他们的，所以加油好好从这些设计的细节入手，好好和产品小伙伴们努力，总有一天，我们也可以拥有让用户真正满意的产品。