因为技术限制而导致的问题，往往需要设计来弥补改善。文章分享了一些“填坑”的小方法，一起来看看~

最近有一幅图在我朋友圈和群里传播：人生就是不断的挖坑和填坑的过程。（图片来自于网络）

想想，交互设计师的工作也是不断填坑的过程，项目不断给坑，设计师不断填坑。回顾交互设计的历史，就不难发现，交互设计催生于机器最难用的时候，最开始的时候因为机器都是实现模型，与用户心理模型实在相差太远，于是需要交互设计作为调节剂，缩小实现模型和心理模型的鸿沟。

在我们实际项目中会有很多的限制，这当中会有很多技术上的限制，不外乎：

1. 可能是因为时间和人力问题，还没有更好的技术方案；
2. 可能是历史遗留问题，改动起来难度大，甚至需要推翻，但是现阶段没法做；
3. 可能是合作问题，改动需要其他部门配合。

……

因为这些技术限制问题而导致的问题，往往就需要设计师用设计的方式来改善，我们戏称为填坑。

但是方法各式各样，在这里可以分享实际项目中遇到过的技术限制坑和用过的方法。

1、用户教育

用户教育就是直接“臣妾错了，请你原谅”的姿态，和用户直接明了地说明情况，希望用户能理解和体谅。

这是对付技术限制成本最低的做法，但未必优雅，有可能会让用户厌恶。关键就看教育是否真的能触动用户，赢得用户体谅。

举一个实例：在做【安卓手机游戏充值】（想看界面可以打开任意一款腾讯安卓的手游），使用话费支付时，因为运营商（中国移动、联通、电信）后台限制，充值的金币是无法实时到账的。

这个时候需要告知用户，这笔订单由于运营商限制，未能实时到账，但是到账了会通知。

值得注意的是，教育也需要看产品的用户群体，“见人说人话”：

1. 比如产品主要用户是年轻人，卖萌式的文案教育可能适合。
2. 比如产品主要用户是白领、中年人，那沉稳、陈述性的文案教育可能即可。

2、“假”文案

这也是教育的一种，但是不是直接告知，而是杜撰一个假的理由告知用户。原因在于：

1. 有的时候技术限制实在难以描述完整和清楚；
2. 或者涉及到专业背景知识，用户无法理解。

这个时候不必真的告诉用户完整的前因后果，可以用一个“假”的话术来说明这个限制。

举一个例子，在做【web端的游戏充值】时（想看界面可以打开任意一款腾讯web端的游戏），在做网银支付方式方式时，遇到一个坑：银行CGI不支持立马回调，API本身也有bug不是一时可改……导致可能查询不到支付结果。

这些这么专业的原因真的要告诉用户吗？？诚然不是，所以我们当时用了一个假原因。当真的查不到支付结果时，告知用户是“网络”原因，然后引导用户重新查询或者重新支付。

PS：这里可以引起一个“道德”的讨论，看起来我们好像在欺骗用户，但是如果我们想想，这何尝不也是一种“善意的谎言”，毕竟综合起来，要是用户看到真实的原因，看到一堆不知所措的名词，反而会造成困惑。

3、动效

动效也是为技术限制擦屁股的手段，它是一种很好用的设计工具。

动效的主要作用是信息层级的过渡引导，即让用户感知信息的变化。在此之下，遇到一些和信息变化有关的技术限制，可以采用动效这个“润滑剂”来帮助解决技术限制的问题。

举一个例子，在做【腾讯积分周边商城】购物车功能时候，遇到一个技术限制：商城的商品是多个供应商提供（可以类比淘宝的店铺），但是购物车不能做合并支付（只能基于供应商进行支付，不能跨供应商），因为公司分成系统决定，如果要改，需要改动整个公司的系统，这个对于一个部门来说不现实也做不了。

什么意思呢？平时大家逛电商，购物车是可以跨店铺合并生成一个订单进行支付的：（图片来自于京东）

但是，对于腾讯积分周边商城来说，后台不支持这个功能。结果就是，必须分开订单来结算。

因此，最后只能基于供应商来支付，所以最终设计结果推导为如下，直接分开两个供应商结算。

同时为了让用户能看到两个供应商，使用了一个“抽纸式”的动效，让用户可以同时看到两个供应商（商城实际上也只有两个供应商），滑动过程中供应商①会被供应商②顶走，点击①还是会展开。

庆幸的是，这个设计还是能让用户理解和接受。用户原话：

“为何不能合并支付，和我逛电商习惯不一样”——预料之中

“明白怎么用，就是区分供应商来支付”——验证设计可用性

4、灵活的设计

灵活的设计就是具体问题具体处理，通过设计把技术限制隐藏得无影无踪。（好像很玄的样子）这类情况是对设计师的挑战，但恰好最能锻炼设计师对技术限制带来问题的把握和处理能力。这是处理技术限制的最高方式。

举一个例子：也是【安卓手机游戏充值】，使用话费支付时，有10%的手机号是需要用【编辑发送短信】这种古老的方式支付的。因此技术限制需要对手机号进行甄别，用户需要触发检测手机号是支持“短信验证码”还是“发送短信”。

什么意思呢？90%的用户手机是支持验证码，很顺利完成支付的：

但是10%的用户，手机号不支持，他们只能用【编辑发送短信】这种n年前的古老方式。当时最初的做法是，把后台判断的过程放在“获取验证码”这个操作，即：点击获取验证码，识别到不支持验证码就使用编辑发送短信的方式：

这种做法让大家陷入了道德和哲学纠结。其实对10%的用户来说，牺牲了体验，让用户犯了错之后再支付，好像告诉他：你的支付方式好low好古老；您的手机号很旧……

所以最后采取了更“顺滑”的方式，用户输入手机号后，触发后台判断，进入相应方式：

其实我们会担心对于90%的用户来说，相当于多了一步操作。但是我们用了“使用手机安全支付”的文案，在可用性测试和访谈过程中，用户并不觉得这是多一步的负担，反而是猜想觉得是步骤的一部分。

用户原话：“是不是为了安全检验手机号”？“感觉更加安全”

（满意脸）

小结

为技术限制擦屁股还有很多方式，不局限于这些方式。当然，最最最最最佳方式当然是推动工程师们把技术限制直接解决掉。不过具体问题具体分析，当真的遇到人力、时间、成本问题不得不为技术限制擦屁股时，用户体验设计师的作用也真正能发挥。

欢迎讨论和补充~

作者：hey熙，微信公众号：heychen思录

本文由 @hey熙 原创发布于人人都是产品经理。未经许可，禁止转载。