时间: 2021-07-30 10:29:32 人气: 11 评论: 0
不知道身为「用户体验设计师（UX Designer）」的诸位是否也有过和我一样的困惑：初入行时兴冲冲觉得自己就是那个为一切产品用户体验问题负责的「真命天子」，积极主动去搜集反馈访谈用户，可当真正卷起袖子打算为解决这些「体验问题」大干一场的时候，却发现有些无从下手。
随便拉几个用户角度吐槽「体验差」的例子：启动慢、运行卡、索要一堆奇怪的权限、不知所云的错误、通知推送烦人、好多功能用不上……而这些用户体验问题，看上去似乎和用户体验设计师的本职（交互+视觉）关联不大，而和技术、产品、运营同学的关系相对更加紧密。
两年前在M厂实习期间参与某 App 项目设计时，涉及到大量不同类型的内容卡**，而因为上线时间相对较急，没有时间对每张卡**都进行完整的设计（设计出来开发也没法都按期实现上线），于是就只做了框架层的设计，而卡**内容部分，则是让开发直接把其他平台相关产品的内容拉过来，再缩放处理了事，这一部分未经过交互视觉层的重设计优化（Review 时把关也不太严），最终上线的体验自然也好不到哪里去。
项目上线后卡**内容部分的体验被吐槽，当时我的 Manager & Mentor 也把我叫了过去，质疑这样的体验怎么能上线。起初我从赶工期、技术限制等方面进行了解释，而 Mentor 的回答大意则是用户不**知道这些，不**理解各种限制的苦衷，他们只看最终的结果，最终的界面交互体验不好，他们只**觉得是用户体验设计师有问题，而不是什么开发来不及不好实现之类。
承上文，有时我们确实不可避免地**遇到一些客观限制（时间紧、人手不足、技术实现成本高），影响到最终的产品体验，可偏偏「用户只看最终结果」怎么办？除了在沟通中守住合理的体验标准底线、在后续迭代中及时优化外，其实也可以通过用户更容易理解接受的方式，来向其表达和说明具体缘由。
比如去年双11期间淘宝的「秋裤弹幕」，在公司里听相关负责人分享时，提到项目当时面临设计资源不足的问题，灵机一动想出了包括文案「设计师跑了」在内的弹幕形式，虽然没有了高大上的视觉效果，却多了趣味性，反而得到不少用户的讨论与传播。
设计师跑了_(:зゝ∠)_
权限问题一直是国产 Android App 们受诟病的一点，用户不明白为什么 App 要索取一大堆看上去和产品核心功能关系不大的权限，进而怀疑对方是否想利用这些权限做什么不好的事情，甚至失去对产品的信任。
其实在请求权限的场景里，我感觉是有很多体验设计上的优化空间的。比如界面文案上可以更清晰礼貌地告知用户产品具体需要哪些权限，权限具体用于什么功能场景（而不是逼用户自己去猜测，进而出现窃取隐私之类的推论）；保留用户自主选择入口（可以选择不给权限，但是某功能**受到影响，用户自己决策）并具备易发现性（Findability），而不是硬邦邦地说「需要X权限」或偷偷开启，而在产品里又找不到任何解释；请求的时机也需要把握，在确实需要用到的时候再出现。
「出错场景」是交互设计中经常要考虑到的一点，如果交互考虑得不全面，设计得不周到，则难免出现晦涩难懂的情况，用户知道产品出错了，却不知道为何出错，如何解决，甚至连错误本身也看不懂。错误既然已经发生，那就真诚地解释清楚错误，引导用户进行解决，甚至考虑一些趣味、情感化的手段，减轻用户因此产生的烦闷情绪。
Chrome断网时的小恐龙游戏
我之前设计过一个平台网站首页，里面有一个模块是用户的排行榜单。在视觉评审的时候给前三名（共五人上榜）的用户增加了1、2、3的排名标记，而我当时也觉得加上这个似乎也问题不大；但发布前验收的时候却发现，前三甚至前五用户的真实排名参照数据之间差距非常微小，还出现了数据完全一致、排名却分成了第2和第3的情况，这样显然第3的用户**有感到困惑与不公的风险。
于是基于公平激励用户的考虑，在真实数据差异细微的场景下，我提出了去掉排名标记、所有上榜用户一视同仁的解决方案。这件事也提醒了我真实数据的重要性，在有条件的情况下尽量「基于真实数据做设计」，而不是填一些理想的虚拟数据导致一些潜在问题被掩盖。
古人说「文以载道」、「字如其人」，其实用在设计和所有创造性工作中也是一样，很多优秀的设计多多少少也是作者内心价值观追求的体现。我们在追求真诚、善良、公平、幽默等美好事物的同时，也可以多想想怎么投射到自己的设计思考与表达中去创造更美好的用户体验，而不是耍小聪明避免承担责任或赚取短期的数据光鲜。
本文由人人都是产品经理专栏作家 @鸿影 原创发布于人人都是产品经理 。未经许可，禁止转载。
