这个问题提的太好了！

长期来说， 建议一套内部的界面UI标准，会大大有利于确保常用UI的可用性不是设计的首要问题。 在此，我真心的建议设计部门应该与开发团队密切合作，建立代码库，以支持这套用户界面UI的标准。

至于现在， 我会用一些过去行之有效的方法，恳求他们：），或更多的外交手段。 开始创建一种团队意识。 认同他们，告诉他们这的确有点麻烦，但如果他们现在帮助你，你保证之后他们会得到更好的UI设计说明书，这将意味着减少返工跟麻烦。

借此机会可以了解一下，为什么重构这段代码很困难？ 是不是因为他们没法保证改了代码会不会影响系统的其他部分？

您也可以尝试做某种程度的妥协，问问他们有什么建议， 是不是有办法可以实现比现在这个要好，又不会给开发团队增加更多的问题？

顺便说一哈，

我越是思考这个问题， 就越是觉得创建UI设计模式很重要， 要具体描述跟展示实际的功能和实施的细则。

就像我曾经在什么是邮编查询最好的实践 里提过的英国邮编查询模式。

--Matt Goddard

Hi, Alastair,

这是一个非常好的问题，Matt的解答也很棒！ 所以，我只是想补充说，想让开发人员为了解决用户的一点小麻烦而做某件事，确实不易。

如果开发人员没有很好而且详细的设计说明，他们会趋向于用最简单的方法完成代码。他们通常不会花时间去考虑用户会怎么看产品，做事的方式没有那么主观能动。

在我对用户体验感兴趣前，我自己也是只想简单的完成代码（没经验啊！），从来不会去关心用户真实使用该产品时会是怎么个状况。

因此，良好的设计说明书才是阳关大道。如果没有他们，我相信使用换位思考始终是个好方法，在这里，就是要让开发人员能换位思考一下用户。 ：）

--Renata Neira

我认为在解决方案的早期探索阶段就让开发者参与进来是个非常好的方法。这么一来，他们就能够建议有用且可行的框架/解决方案。此外，这也能让开发人员们更重视用户体验的观点。

当然了，有个完整详细的规格总是有帮助的。不过如果光有规格，但用户体验部门和开发部门间没有任何的讨论，有时还是会导致更高的成本支出。

-- Zoltán Gócza

我在成为目前公司的信息架构总监之前，我是个开发人员，也已经写了15年的代码。如果UX们的建议是在早期提出的，我会很容易接受。我认为开发人员在开始写代码之前就应该被告知东西要做成什么样子，有哪些具体的要求。

信息架构师和交互设计师们可能不知道，有时候一个很小的界面改动，就会导致巨大的代码变更。如果之前整个代码已经完成了，那程序员多半是会抓狂；如果开发人员对于UX本来就没有多少认同感的话，这个挫败感还会更强。他们会和你说：“我花了4个小时来重写代码，仅仅是为了让用户可以通过拖拽来重新整理分类？？”

在开始写代码之前，就能获得带有详细功能说明的线框图，对我来说是一件很幸福的事情，因为这样就可以从一开始规划好整个代码怎么写。相反，如果没有具体得到一个详细而准确的最终产品描述，我想大多数和我一起工作过的程序员都会感觉很不舒服。所以，当产品还在线框图阶段时，UX或者IA们就应该尽可能多的和程序员沟通，让他们理解要开发出一个什么样的东西。

你一直都这么做（每一次设计，每一个产品，都提供很详细的说明，确保程序员们一开始就非常理解东西要做成什么样子），程序员们的日子就会好过一点。那么之后遇到需要麻烦他们的时候，你也能得到他们相对温和的反应，合作起来也就能更和谐一些了（这不是说现在去详细的线框图什么的，而是要从一开始就这么做，人情策略，你关注了程序员的难处，那么程序员也会关注你的难处）

-snipe