重新思考设计交接
我已经工作了一年多来改善网页设计师和工程师之间的工作关系。当前最佳实践的特点是“设计交接”，设计师将应用程序屏幕的图片提供给工程师以供实施。接近这个问题，很难不注意到一个到处都是墓碑的草丘：其他人死在山上，试图“消除交接”但未能成功。
在我研究的早期，我与一位在这座山上占有一席之地的企业家进行了交谈（而且还不错，他的企业在他们的产品下架之前就被收购了）。他的观点与谷物背道而驰：也许交接并没有那么糟糕。也许很多人都失败了，不是因为时间、团队或技术，而是因为他们正在努力消除的交接是构建产品过程中有用的部分。
这些保留使我从讨厌交接变成喜欢交接，最终——以辩证的方式——通过综合解决矛盾。有了这种调整后的心态，并在对创作过程的热情的推动下，我创办了一家对工程师和设计师之间的关系持全新态度的公司。我们的目标不是消除切换，而是改变它。
交接的乐趣
切换是一个有用的检查点。在交付设计之前，产品团队通常会与工程师协商，进行多次迭代。 “最终”设计规范是设计和工程之间的合同。工程师“接受”设计，这意味着他们承诺建造符合该规范的东西。通过交接，团队可以在工程师开始实施之前确保设计是完整的、高质量的并获得利益相关者的批准。
移交的合同性质使各种工作关系正式化。在最极端的形式中，移交实际上是合同的一部分，因为设计机构聘请外部团队以固定费用实施此规范。如果缺少某些东西，该机构可以指向规范并说“这里，你错过了一些东西”。同样，如果该机构要求新的东西，签约的工程团队可以说“嗯，那不在设计中”。
更常见的是，设计是在组织内传递的。客户/供应商的权力动态反映在一个不太正式（但仍然有些争议）的产品/工程部门权力动态中。
这种交接巧妙地融入了工业时代的流程思维方式：一系列有序的步骤走向结果。任何读过彼得·德鲁克或敏捷宣言的人都知道，信息在一个方向上流动的自上而下的过程在数字时代并不理想。主导市场的产品通常是由非分层工作的集成团队分小步创建的。组织中的每个人都在他们的洞察力重要的确切时间根据他们的专业知识做出贡献。
这种交接在使用从经理到工人的传统、军国主义、自上而下的信息流组织的团体中表现出色。利益相关者批准的设计清楚地向工程部门发出信号：“做到这一点”。当规范与工程约束完全一致时，产品就可以高效地构建。当移交设计在技术上不可行，或者比替代解决方案成本更高时，结果很弱。
交接，由于其分裂性质，可以分裂原本没有压力在孤岛工作的团队。最好的团队通过尽早将工程师带入设计过程并保持沟通渠道畅通来对抗这种分离。
对于不太关心质量的团队来说，交接是轻松的。设计工具提供的图片和动画没有说“完全像这样”，因为它们与复杂的代码不匹配。然而，切换是设计师说“让它有点像这样”的好方法。在我的采访中，设计师对细节和质量越是痴迷，他们就越有可能因交接而感到沮丧。在低标准的公司中，设计师被检查并领取薪水，工程师自由地解释设计，似乎没有人注意到最终产品质量低下。
更好的行业标准不仅会提升顶级团队，还会提升无法在产品设计上大量投资的组织。也许交接最有害的方面是它倾向于促进团队之间的分歧，否则这些团队会无缝协作。
无切换世界
更换切换远非简单。如果没有交接，就没有任何沟通！每个人如何为最终产品做出贡献？也许有这么多初创公司在消除切换的山上死去，因为他们的解决方案用更糟糕的新问题代替了旧问题。
网络团队的无切换世界是什么样的？我们不知道。没有人成功地消除了需要工程师的复杂网络体验的切换。我们可以从其他行业（例如游戏设计中的关卡设计过程）中寻找灵感。我们看到了一个趋势：设计师在实现本身中工作，微调每个细节。
对于更简单的站点，不需要工程师，也没有切换。超过一半的网络由 NLC（无代码和低代码）解决方案提供支持，范围从 Squarespace、Wix 和 WordPress 到 Bubble.io、Reflow 和 Webflow。设计工具生成浏览器代码，设计者的工作与实现本身是1:1的。这些过程消除了切换的许多弱点：
- 利益相关者审查完全互动的最终产品。由于实际实施是设计审查的重点，因此产品出货时不会有任何意外。
- 用户测试可以在完整、准确的网站版本上进行。原型可以非常接近最终用户的体验。
- 当设计师看到他们的工作被实施时，他们并不感到惊讶。在设计时可以充分评估交互的复杂性。
- 没有通信开销（因为没有工程师可以与之通信）。
- 工作不必重复两次（一旦设计好，就设计好了）。
尽管有这些好处，但无代码工作流程仍有局限性：
- 无法实现复杂的产品。今天的大多数团队正在构建无法使用无代码工具构建的东西，并且至少需要工程师构建一些部分。 NLC 工具的功能越来越强大，但无法赶上工程应用程序不断增长的功能。
- 设计师必须做更多的工作，因为他们必须在迭代时管理交互的细微差别。这不可避免地比制作设计图片要慢，并且可以通过在创意过程中充斥着实现细节来分散设计师的注意力。
最后一点是当我听到“也许切换不是那么糟糕”时想到的。在构建复杂应用程序的大型团队中，交接使设计人员免受确切实施的所有混乱细节的影响。这使设计人员可以专注于用户的目标，而不必担心低级设计细节。在设计中有时间和地点。对于创意人员来说，采访用户并讨论抽象目标很重要。但设计师控制产品实现的细微差别不是同样重要吗？
解决方案：选择
这些天来，我们不断被提醒设计不仅仅是细节。大约 15 年前，“UI 设计”的实践更名为“UX 设计”，以强调设计师不仅仅关心字体、颜色、大小和间距等低级问题。设计师指导整体用户体验（UX）。
在过去的 5 年里，随着 UX 设计与小细节联系在一起，设计师们将自己重新命名为“产品设计师”，再次强调对产品的高级指导，而不是小细节。
虽然这种对高级用户目标和动机的关注很重要（并有助于证明公平薪酬的合理性），但设计不能将自己作为一种实践与最小的细节分离：Helvetica vs. Roboto，10 或 12 像素边距，动画是否需要 0.5 或
我们可以将设计可视化为一系列决策。链顶部的选择（用户对产品的感觉）与链最底部的复杂实施细节完美关联。
我说“美丽”是因为这条链使设计作为一种实践如此令人惊叹，并且对于非设计师来说是一件如此迷人的事情。我们都知道欣赏车身线条的连续性、完美的排列、与车辆的功能方面的和谐结合是什么感觉，并且会想“这辆车是天赐的”吗？当沿着这条链的整个长度做出设计决策时，效果是崇高的。我们在各种设计的工件（包括 Web 应用程序）中都看到了这种卓越的品质。
网页设计过程应该允许设计师轻松地沿着这条链的整个长度移动。有时设计师需要并且想要完全控制细节。有时，团队中有具有设计经验的工程师可以填补空白。理想的解决方案允许设计和工程之间的重叠。
我们没有分裂的交接，而是合作。如果团队想要进行分工和分离（出于合同或其他原因），他们可以自由添加。流程遵循团队的需求，而不是设计工具的约束。
这种新的工作方式的好处一直延伸到链条的顶端：用户研究。设计师可以通过功能齐全的应用程序增强现有产品以探索用户行为。与当前的原型设计工作流程不同，设计人员不必设置场景，而是可以在整个应用程序的上下文中评估用户行为。
这种对设计交接的重新构想需要一种新型的设计师，当然还有一种新的工具集。我希望在以后的帖子中分享更多关于这两个方面的信息。如果您喜欢这篇文章，请务必鼓掌并查看我的 先前的想法 关于这个话题。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
本文链接：https://www.qanswer.top/3072/19073109
标签：工程师,交接,切换,思考,设计,设计师,团队 来源： https://www.cnblogs.com/amboke/p/16641810.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。