交互案例实战！三个按钮背后由小见大的交互思考

详细了解需求背景之后，方案三首先被排除了。原因很简单，本身置灰就已经表示不可选了，『暂不可选』文案所表达的内容太少，既没有展示出不可选的原因，也没有告诉用户什么时候恢复该投诉选项。同时，我们得知反馈的文案会比较长，大约有十几个汉字，按钮本身的空间有限，并且直接在原因字段内拼接『暂不可选』也会有点技术成本。

方案二在流程上是顺畅的，但是和案例一中提到的类似，我们一般希望用户在操作之前就能预期到交互的结果，而不是让可选的按钮点击后出现提醒再告诉用户不可选。

同时考虑方案一，对于按钮置灰有一个问题需要考虑，可以看到无线端使用的是这种滚轮式的选择组件，其本身置灰能不能做是要打个问号的，事实上和开发沟通之后发现确实无法实现。最后，综合考虑下，还是采用了方案二。

总结：通过案例二可以看到，设计中常常会有一个最优解，但又总会因为技术成本、其他业务原因的影响去妥协，最后得到的方案也许不是交互上最佳的，但确实整体效率最高的。这也说明了，新人不要轻易对其他产品做体验分析，因为你并没有这些真实限制，所得出的结论也是空中楼阁。

案例三

虚拟场景：某些操作是有时效的，比如某个商品限量销售，如果还没有到付款的时间节点，付款功能是不可用的，那么付款按钮能否优化处理。

现状：当商品不在支付时间段内，付款按钮隐藏。

目标：不要让用户找不到付款按钮，令操作更加顺畅，可见性更强。

设计过程：

和案例一一样，这也是一个设计师自发想要改善体验的过程，正好有其他业务需要对这些页面进行改造，能否把这个按钮隐藏的过程优化呢?原因相信大家都能理解，把不可用的功能藏起来，总归不是最好的做法。

仔细查看线上的样式我们发现，这个案例和案例一还不太一样。最重要的一点是，付款的时间是有倒计时的，也就是说即便付款按钮本身是隐藏起来的，但其附近依然有文案提醒现在不在支付时间内，所以用户不太容易迷惑。

比较简单的解决办法就是，把支付按钮暴露出来，并且置灰。看来今天三个案例都和置灰杠上了。经过交互小组和产品小组的讨论，都一致觉得把不可用的支付按钮置灰更加合适，并且线上已有文案提醒说明，用户也更容易理解。

但是这个案例最后的结论有些出乎意料，首先，因为线上所有类似业务都采用了隐藏不可支付按钮的做法，所以如果这类交易要改，其他全都要改(时间成本);其次，这个按钮组件在早期开发过程中，并没有设计、开发 disable 的状态，也就是没有置灰的样式，如果要做，需要重新设计和开发(开发成本);最后，线上这个隐藏的样式已经存在很长时间了，用户大部分都其已经习惯，并且没有发生普遍的反馈表示认知困难(用户理解成本)。所以，结论还是保持线上的样式。

总结：有时候设计是对的，所有人都认可，但是依然会有各种因素前来制约。尤其在较大的产品团队，业务节奏快、需求多、上线紧，这类优化体验的工作常常优先级不够高。与此同时，很多朋友可能会说一个按钮而已，加一个 disable 的样式又有何难?然而很多团队的流程规则导致业务工作是一条线，组件优化新增样式又是另一条线，想要一步把两件事都做了并没有想象中的容易。

怎么样，简单的三个按钮，是不是让你有些晕了?交互设计的难点常常就在于体验、产品、开发各个内容的协调，相互妥协，最后达到一个平衡的状态。由小见大，小按钮我们能应付了，慢慢就可以面对大问题啦。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!