用户体验与开发实现之间的博弈——半年交互工作心得体会

本文来自网易云社区

作者：任琼瑶

入行互联网8年有余，但真正开始了解整个产品开发流程中的细节、困扰、各个角色之间的合作，还是在转岗交互之后的短短半年里。

之前8年一直做的是用户研究工作，接触最多的角色是产品经理和交互，但一直有这样一种困惑：我们发现了许多用户体验问题，在给出问题以及解决建议后，总是很难看到有效的产品改进。

那时候总是怀疑是自己推动不力，后续工作不到位，但真正处于产品流程之中，才发现，产品经理和交互也在竭尽所能地推动产品体验的升级，然而太多因素阻碍着这种推进，包括工作节奏、开发实现、产品整体规划等等，其中尤其以开发实现逻辑上的阻碍最为明显。

在听了众多开发大牛对代码逻辑和架构的初步说明后，深深体会到，原来用户体验和开发实现之间真的是相爱相杀，彼此互相依赖共生，同时又有着不一样的期许……

从用户体验层面来说，产品经理和设计师需要考虑多种不同的用户使用场景，以此给出适合每种场景的不同解决方案，同一个功能在不同场景下可能存在不一样的表现；而开发逻辑，则希望更多的是整合的、统一的解决方案，这样能减少代码量，也能让整体架构的拓展性更强，不至于在日渐增多的新功能新需求面前，代码越来越复杂，最后变成一团乱麻。

举个最简单的例子，在某一个按钮的点击反馈中，可能存在弹窗、toast等不同的反馈形式，在用户体验层面，我们会判断反馈内容对用户的重要性，如果是轻量级反馈，则用toast更为合适，而如果是必须要确保用户知道的反馈，则使用弹窗更为合适。但在开发实现层面，不同的反馈形式需要后端做不同的定义，势必增加工作量和代码的复杂度，能用同一行代码来跑不同场景自然是开发们所期望的，这就势必与用户体验的理念背道而驰。

但这种表象上的“背道而驰”只是短时性的，从长远来看，大家的目标都是一致的，都是为了让产品更加好用，更新迭代更快捷。不可否认的是，用户体验的好坏，除了人机交互层面的设计，还必须包含系统的稳定和快速，如果代码冗余复杂，显然对系统性能会有很大的影响，代码的架构可拓展性差，那么开发迭代的成本会越来越高，用户需求的落地性也就越来越差，这些都应该是用户体验的一环，也必须是产品经理和交互需要权衡利弊的一环。

期望上的不同导致了部分问题无法理想化地去解决，另一个方面的阻碍，则是功能实现的逻辑无法支持交互方案。

我们的设计工作，大部分还是在已有产品上进行修修补补，确保以最小的成本去实现新增的用户需求，极少设计师有机会实实在在地从零开始搭设产品框架。那么我们的设计就会套上“产品已有实现逻辑“的枷锁，尤其是新人设计师，对产品本身的实现逻辑不熟悉，在做出一些看似完美和用户体验很好的交互方案后，开发一评审，发现在现有框架下根本无法实现。

在前期交互评审时发现这些问题还为时不晚，但若到了开发进行中，甚至版本即将提测，才发现这些设计细节，在改动的过程中就有可能牵一发而动全身，看似只有交互稿上的一点小改动，也许对程序员们来说是几天的工作量。因此，什么是交互的工作经验，除了掌握和灵活应用各种需求的解决方案外，还有对产品的熟悉程度，包括对底层开发逻辑的熟悉度。

当然这不代表缺乏经验的设计师就一定会把项目搞砸，知道自己的不足，在设计过程中对不确定的问题，与前后端开发做实时的沟通，一定能事半功倍。

产品经理之所以被戏称为“产品狗”，也是因为时常需要为频繁变更需求而求爷爷告奶奶，变更需求之所以这么受抵触，但却时常发生，主要原因也是在于，变更需求本身，对于产品经理来说只是轻易的一句话，而对于交互设计师来说，需要重新修改交互稿，设想和穷尽需求变更之后可能出现的不同情况，再交由开发的话 ，又会变成更为庞大和繁杂的一通代码修改，会让下游的人产生“前期做了很多无用功”的沮丧感。

交互设计师，夹在产品经理和开发之间，比开发更为了解产品经理在满足用户需求层面的理念，同时也比产品经理更为了解开发们在细节实现上所做的大量工作，那么也就更为适合做用户体验和开发实现之间博弈的主导者。若产品经理发起需求变更，可与其明确需求的优先级，与开发一起，共同商量成本最低的实现方式。如果一味地从源头开始推进工作，先出需求，再做设计方案，最后交由开发实现，则一定会出乱子，也一定是在增加各个角色的工作量。

经验、流程、博弈，任重而道远。

网易云免费体验馆，0成本体验20+款云产品！

更多网易研发、产品、运营经验分享请访问网易云社区。