与开发在一起的日子1：站在用户这边

前两天晚上，我组织了一次设计评审，对其中的一个交互我和开发小伙伴有较大的分歧。如图1所示，这是一个网站首页上各广告位的管理，每个广告位只能上架一个广告。用户可以对广告进行批量上下架的操作，需要校验当前广告位是否已上架了广告，是的话就需要提醒用户当前位置已上架广告，需要先下架之前的才能继续。

分歧点在于，我希望在选中数据再点击上下架按钮的时候，判断当前位置是否已有广告上架了，有的话就及时给一个Message提示用户，让用户提前知道操作有异常。如果没有的话再弹出一个二次确认对话框。如图2：

后端开发工程师认为，所有数据在点击对话框里的「确定」后，始终是还要再校验一次的，不需要在点击上下架按钮的时候提前校验一次，如果这个项目中所有需要提前校验的操作都这样处理的话，要多写很多接口，增加了开发工作量。所以他们坚持一开始就弹出一个二次确认对话框，点击确定之后再告诉用户操作结果。

我认为用户看到二次确认的时候，已经认为是可以进行该操作了只不过是再确认一下是否要做，如果以开发思维来设计，确定做了再告诉用户不能这样操作，肯定是不符合用户心理预期的（极少数由多人操作导致的并发问题除外）。但开发工程师所说的也不能完全不顾及，如果大家能达成一致的话有利于团队氛围和项目推进。这就是日常工作中经常会碰到的问题，用户体验与开发工作量之间怎么平衡与取舍。

于是我建议后端开发进行工作量评估，并确认是否会影响现在前端的进度，同时动之以情晓之以理，给大家讲用户操作的场景，体验做好了对整个产品都好，最终受益的还是我们自己。

最后，大家达成了一致，后端开发工程师们同意了统一加上这个提前校验的接口。

产品的整个团队中，产品可能更注重商业模式、产品盈利，开发团队更注重业务逻辑与产品的实现，而我们交互设计师是产品走向用户的过程中很关键的一环，我们要多站在用户的立场与团队成员进行沟通与协调，确保我们做出来的产品是用户想要的，在工作中可以多和团队成员讲用户场景、分享体验思维，当大家有一个共同目标时，别人会更容易接受你的观点。

当然，最重要的是我们的设计方案是经过深思熟虑，经得起质疑的。