开发人员“拥有”代码，那么设计师不应该“拥有”体验吗？

我们都去过那里。 您花了几个月的时间收集业务需求，制定复杂的用户旅程，制作精确的界面元素并在具有代表性的用户样本上进行测试，结果却发现最终产品与所需体验几乎没有相似之处。

尽管您认为组织还没有准备好，但也许您应该更加有力并坚持采用敏捷方法？ 也许您应该在模式组合方面做得更好，确保开发人员使用您的模块化代码库，而不是创建五种不同的轮播变体。 或者，也许您甚至应该每天都坐在开发团队旁边，确保您的设计真正实现。

关于 SmashingMag 的进一步阅读：

• 为什么你应该在设计过程中包括你的开发人员
• 团队协作和缩小响应式设计中的效率差距
• 设计师和开发人员玩得很好
• 如何与开发者有效沟通

取而代之的是，您只剩下一堆混乱的 UI 元素，所有的微妙之处都被去掉了。 难道他们没有看到你工作了好几天才使过渡效果恰到好处，只是为了让他们放入默认动画库中吗？ 这个额外的结帐步骤到底是从哪里来的。 我敢打赌，市场营销是在最后一刻把它扔进去的。 你知道整合会很困难，需要做出妥协，但我们应该让用户在这里生活更轻松，而不是技术团队。

当然，网站采用这种方式有很多充分的理由。 具有不同技能水平的不同团队在项目的不同部分工作，最后一分钟的更改缩短了开发周期，以及一大堆技术挑战。 不过，为什么开发团队不能来就他们的 UI 更改征求您的意见？ 你不会弄乱他们的代码，那么他们为什么要改变你的设计呢？ 尤其是当业务影响可能很大时！ 您只是在拐角处，如果他们刚刚提出要求，您会很乐意提供帮助。

虽然上面的故事可能是虚构的，但这是我从设计界的各个角落听到的一种情绪，无论是内部还是代理方面。 一个精心制作的经验被一个严厉的开发团队毁了。

这段经历让我想起了几年前在美国当地新闻频道看到的一个新闻故事。 一个县集市正在举办一场耐力比赛，最后一个把手放在皮卡车上的人获得了奖品。 我经常认为设计就像一场“碰车”的大型游戏，开发团队总是在比赛结束时拿着钥匙离开。 就像争论中的最后一句话一样，最终与该网站接触的人拥有所有权力，可以决定它的工作方式或外观。 特别是如果他们声称特定的目标体验不是“技术上可行的”，这通常是“非常困难”、“我不介意那样做”或“我认为有更好的方法可以做到这一点”的简写所以我要拉开发卡”。

现在我知道我在这里对开发人员不公平地苛刻，我不是故意的。 那里有一些非常有才华的技术人员，他们真正关心可用性并希望为用户做到最好。 然而，由于认为设计很容易，因此每个人都可以发表意见，而开发是困难的，并且只针对特别发起的人，因此人们常常感觉学科之间存在不对称的尊重程度。 因此，虽然鼓励（有时期望）设计师让每个人都参与到设计过程中，但他们往往得不到同样的奢侈。

老实说，我不怪他们。 毕竟，我知道开发足够危险，所以如果你想要我对数据库结构和代码性能的看法（除了我在很大程度上认为性能是一件好事），你就是个白痴。 再说一次，我确实知道足够的知识来判断开发人员何时在捏造东西，并且带着他们认为不可能或需要几个月才能实现的工作原型回到他们身边总是很有趣 - 但我离题了。

问题是，我认为很多开发人员在设计方面都处于相同的位置——他们只是没有意识到这一点。 因此，当他们根据几年前在一次会议上听到的内容对界面元素进行更改时，他们可能缺乏重要的上下文。 也许这是您已经测试过并打折的东西，因为它表现不佳。 也许您出于特定原因选择了这个元素而不是另一个元素，比如可访问性？ 或者，也许开发人员的意见是错误的，基于他们作为超级用户而不是普通用户体验网络的方式。

现在让我们直接在这里。 我并不是说开发人员不应该表现出对设计的兴趣或对设计过程的投入。 我坚信跨职能配对，并认为一些最好的可用性解决方案来自技术团队。 那里也有很多才华横溢的人，他们跨越多个学科。 然而，在某些时候，体验需要被拥有，我认为它不应该被最后一个打开 HTML 文件并“触碰卡车”的人拥有。

那么，如果优秀的设计师尊重优秀的开发人员带来的技能和经验，那么稍微平价又如何呢？ 如果设计师乐于让开发人员“拥有代码”，为什么不表现出类似的尊重，让设计师“拥有体验”呢？

这样做相当简单。 如果您发现自己不确定为什么以特定方式设计某些东西，并且认为可以做得更好，请不要一头扎进并开始进行更改。 同样，如果你遇到了技术障碍，并认为用不同的方式设计东西会让你的生活更轻松，那就去和你的设计师谈谈。 他们可能对您建议的更改完全满意，或者他们可能想离开并考虑解决同一问题的其他方法。

毕竟，合作是双向的。 因此，如果您不希望设计人员在您的版本控制过程之外开始“优化”实时服务器上的代码，请停止对他们的设计做同样的事情。