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

交互案例实战 ！三个按钮背后由小见大的交互思考 @窒息红Leo n ：初入交互设计工作 ， 常见的需求就是——放按钮。放按钮看起来是超级 简单的事 ，无非就是设计按钮的样式、摆放按钮的位置、确定按钮的状态与反馈等 ，但殊不 知其 『麻雀虽小 ，五脏俱全』 ，小小的按钮设计中也蕴含了很多交互设计的思维 ，当然除了 设计本身之外 ，还能看到如何平衡开发、产品以及用户各方的需求。 所以 ，本文章会通过三个真实但抽象的例子说明工作中 『放按钮』是怎么做的。真实说的是案例来 源于实战 ，抽象就是提炼出思维但讲的场景都是虚拟的 ，免得透露机密。有趣的是 ，三个按理都和 时间、时效有关。 案例一 虚拟场景 ：某订单页面 ，商品订单以卡片的形式罗列 ，每个卡片下方有若干操作按钮 ，如支付、 取消、投诉等。根据规则 ，投诉按钮必须在订单产生2天后才可使用。 现状 ：目前产品线上的设计方案是 ，几个按钮同时呈现可点击状态 ，当投诉按钮处于可用时间段 内时 ，点击就会去往一个投诉页面填写投诉申请 ；当目前处于不可投诉时间段内 ，投诉按钮点击后 弹窗提醒用户 ：还有 XXX 时间才可发起投诉。 目标 ：提出这个案例时 ，我们希望让这个操作过程更加自然 ，不要让用户点击了之后才告诉用户这 个功能不可用 ，而不要脱离用户的交互期望 （如果按钮可用 ，交互期望就应该是实现相应的功能 ） 。 设计过程 ： 开始考虑这个案例时 ，我的第一反应就是如果一个按钮当前是不可用的 ，就应该隐藏起来 ，这个 场景按钮还是挺挤的 ，明明不能用的东西为什么要放在界面中吸引视线呢 ？ 但是很明显 ，这个第一感觉有严重的硬伤。首先 ，对于一个按钮或功能 ，告诉用户这个东西不可用 ，和不告诉用户有这个功能 ，是完全两码事。尤其是一个存在可用/不可用两种状态的按钮 ，在特定 时间将其隐藏的风险非常大——你不知道这个功能的被需要度多高。 于是 ，我们去查阅了一下数据和之前的设计方案。首先得出的结论是 ，这个按钮的点击率不低 （超 过10%的用户 ，而且这个页面的总 pv 非常高 ），其次 ，以前有尝试过把这个按钮直接在不可用时 隐藏的设计 ，但是立刻引来了大量的客服投诉——用户找不到投诉入口在哪里了。 所以 ，似乎数据和历史方案帮助我们排除了第一种做法 ，也就是直接隐藏按钮。那在不可用期间把 按钮置灰怎么样 ？ 置灰的好处在于 ，用户一眼就能看到这个功能的存在 ，同时又能知道这个功能暂时是不可用的。但 是问题也来了 ，怎么知道这个按钮什么时候可点什么时候不可点 ？一个解决方案是在置灰的按钮中 加上文案提醒 ，另一个是点击置灰的按钮后给出文案提示 ，但是前者似乎没有足够的空间进行展 示了 ，而后者看起来不错……但是好像又回到了原点 ？（后来还讨论过一些更复杂的方案 ，比如 后半天置灰 ，更早的时候隐藏等 ，但我们并无法判断用户对时间点的真实感受和期待。 ） 所以 终的结论就是 ，由于当前的线上形式并没有什么致命的问题 ，也没有收到太多关于体验方面 的投诉 ，而考虑到开发成本、设计成本和迭代周期 ，还是选择保持线上的样式不变。 感觉走了一圈走回原地 ？在实际工作中经常遇到这样的情况 ，设计师通过本能和直觉判断某些内容 的体验可能不是 佳的 ，但经过资料搜集、自我批判、成本评估后发现 ，似乎保持现状是 好的 做法。 总结 ：这个案例告诉我们 ，设计时不要总想着找茬 ，第一反应往往可能漏过了诸多细节 ，思考清楚 再做行动。 案例二 虚拟场景 ：对商家或商品进行投诉之后 ，需要用户选择投诉原因 ，如态度不好、价格变动、缺货等 。其中 ，在某些特殊时间段内 ，如该商品本身就是秒杀商品 ，用户发起投诉时则不能选择 『缺货』 原因。 现状 ：线上目前没有这个功能 ，即所有的投诉原因都是可选的 ，选择组件使用的是 picker ，大概如 下图的样式 （ 常见的就是选择时间啦 ）。 目标 ：对于 『缺货』这个投诉原因进行交互处理 ，令其在特定时间段内 （商品秒杀阶段 ）无法选择 ，并给用户相关提醒。 设计过程 ： 乍一看和案例一非常相似 ，但其实差别还是挺大的。案例一属于设计师自发尝试对体验改进 ，而案 例二确实明确的业务需求 ，需要把没有的功能融入到现有方案中。拿到这个需求时 ，首先看到大概 会涉及两个页面可以用来设计 ，分别是投诉页面和投诉原因选择页 （这两个通常不会直接在一起 ， 但是后者有可能以弹层的形式出现 ，当然也可能新开页面 ），于是闪过几种可能的处理方案。 方案一 ，在投诉页面提前进行文案披露 ，告诉用户 『缺货』原因不可选 ，同时进入原因选择页时