有太多的产品设计方案，到了最后，要么来不及执行，要么没有被“正确地执行”。当然，“慢工出细活”并没有错，但是行业发展日新月异，我们只有快速、频繁地发布产品，才能不被市场淘汰。

几年前，作为一名产品设计师，我被派到一个大公司的项目组，负责重新设计一些“遗留”的APP。我想，能够为一整套 App 打造未来的 UX ，这个机会应该是所有“简约主义”设计师都梦寐以求的吧，而且，我所设计的第一版 App 还将为其他设计师奠定基础呢。

接到任务后，我马上开始做用户研究，深入了解产品现状。为了明确设计团队的行动纲领，我和产品负责人、其他同事合作，整理出一份产品需求待办列表。

几个星期后，设计团队对项目有了更好的理解，我们就开始研讨新的方案，验证和细化设计要求，忙得不亦乐乎。 与此同时，开发团队却在一旁苦苦等待，直到我们起草了线框图，才能动工。

又过了几个月，我们已经完成了大量工作——从草图到线框图，再到用户旅程图，紧接着设计了 UI 组件，还附上了详细的说明。为了展示设计方案，我们甚至做了原型。当然，我们也一直在做用户测试，获得了很好的反馈。一切似乎都朝着正确的方向推进。

但尴尬的是， 经过了这么长时间的努力，产品还是没有做出来。做出来的东西离我们所能达到的水平还差了十万八千里。

说到这里，你是否有一种似曾相识的感觉？

有太多的产品设计方案，到了最后，要么来不及执行，要么没有被“正确地执行”。 当然，如果你想有新的发现，或者验证某个观点，“慢工出细活”并没有错。但是行业发展日新月异，我们只有快速、频繁地发布产品，才能不被市场淘汰。 

所以，在过去几年里，我着力改进了产品开发流程。在这里分享一些关键的改进方法，希望对你有帮助。

设计好 MVP 

“我们需要一个 MVP。”这句话你可能听过不下一千遍了，但真的不应该只是说说而已。 如果你完全了解什么是MVP（Minimum Viable Product，最小可行产品），你可以先集中精力把 MVP 做出来，而不是一直等到最终产品“震撼上线”那一天。

要做到快速发布，你的团队必须有发布最简产品的意愿。对于一些为了“完整产品”而投钱的利益干系人来说，这一点，他们会相当难以接受。

但是，换个角度来说，产品发布越快，就可以越快获得有价值的用户反馈，越早得到意想不到的发现。而且，越早开始开辟用户群，也能抢先一步，实现用户增长，在短时间内占领市场。

你需要接受的是，MVP 可能不会马上具有竞争力，但也不需要马上进行大规模营销。做好 MVP 的关键在于，把能做出来的产品快速推向市场，为产品优化铺平道路，为用户带来越来越大的价值。

Slack 是一个很好的例子。它的产品团队利用用户反馈，不断优化产品。虽然没有首席营销官，也没有做大规模营销活动，但通过不断倾听，不断改进，Slack 最终赢得了用户的心。

不要只想取悦老板

很多设计师喜欢自嗨，自嗨起来，更是“事不关己，高高挂起”，他们的关注点仅仅是自己的设计成果。只要交出了一份满意的设计方案，就算大功告成。到了最后，最终产品和设计方案差了十万八千里，他们就开始甩锅：“要怪就怪开发人员，不是吗？”

更可怕的是，人都是感性的，本能地追求视觉刺激带来的快感。所以，要取悦利益干系人并给他们留下印象并不是什么难事。但作为创造者，我们还是应该从用户的声音中汲取养料。

如果有一天，我们终于意识到，高保真的模型也好，原型广告也好，都是为了推出新产品，而不是个人炫技的手段，设计师们还会有好的表现吗？

我并不是说，别再追求更完美的视觉设计效果。 我也有追求完美的强迫症，但我关心的是最终产品是否完美。早在显示器还是800 * 600像素的年代，一处没有达到像素要求的设计就会让我原地爆炸，因为实在太显眼了。最终摆给用户面前的产品，必须是完美的，正如 Salesforce 设计团队所言：

“运用细致和优雅的设计手法，充分展示对用户时间和注意力的尊重。”

我也没有说要放弃高保真。高保真有助于我们验证假设，确认产品的可用性。在这里，我想说的重点是，作为设计师，不要总想着取悦利益干系人，做些对用户没用的东西。相反，我们要把重点放在设计出一个在现实中可行的产品出来。 

紧跟团队节奏 

为了少做无用功，设计师对产品要有全面的了解——路线图长什么样？还有多少待办事项？下一步的计划是什么？开发人员在每个阶段的工作是什么？ 而不是袖手旁观，天真地以为管好自己的“一亩三分地”就可以了。 

在产品团队中，设计师常常坐冷板凳。设计只起到“锦上添花”的作用，很容易被忽视。 其实，设计师希望做的是，运用自身经验，提供富有创见的解决方案，同时收集反馈，进行验证。 谁也不希望，得到的指示永远是一句话——“那个谁，麻烦把产品弄好看点”。

作为设计师，如果你不想被边缘化，就应该紧跟团队节奏，熟悉团队正在做的一切，让产品设计、开发和发布环环相扣。这种做法不仅有助于展示设计灵感，还可以凝聚团队的其他成员。这就引出了下一点。

分享设计想法 

从一开始，每个设计想法的讨论，就应该人人参与，给每个团队成员贡献意见的机会，让他们有被接纳的感觉。 没有人喜欢服从命令，所以，不要急着执行，先跟大家说说自己的设计想法。运用专业才能，促进每个想法的共享。 渐渐地，你会发现，团队上下都达成一致，为了共同的目标而努力，没有人掉队，团队士气也显著提升。

学会编程 

设计师是否要会编程？

这个问题已经被讨论了很多年。 作为具有 UI 开发人员和 UI 设计师“双重身份”的人，我的看法可能有失偏颇。 我知道，会编程的设计师寥寥无几，学习编程需要花费大量的时间。但会编程的好处是显而易见的。

对我来说，有了编程的能力，和开发人员的沟通方便了许多。 设计师的时间有限，有时来不及写标准的生产代码。但是，只要能清晰地展示产品体验构想，减少开发人员的误解，避免重新设计的麻烦，代码混乱并不是问题。

如果设计师不会编程，他们至少应该了解产品运行的平台。这就好比建筑师在设计房屋之前，应该了解建筑材料和周围环境。

学会编程，可以减少设计师的工作量。不仅如此， 如果设计师的方案足够清晰，开发人员打代码的工作量也会大大减少。就算不会编程，熟悉整体的运营平台或框架，也有助于设计师做出更靠谱的设计方案。

表格要设置“筛选”功能吗？ 是在点击“查找”功能后加载数据，还是预加载所有数据？

如果X组件和Y组件效果差不多，哪一个更容易实现……这些都是设计师要思考的问题。

总结出一套常用组件，可以节省非常多的时间。面对不同的用户需求，对这些组件越熟悉，设计时就越得心应手。相反，设计方案越不可行，就要花费越多的精力修改。到头来，浪费的不仅是设计师的精力，还有开发人员的精力。

除此之外，在过去几年中，我们的工作方式发生了很大变化。 可维护的设计规范（living style guides）、设计模式库（design pattern libraries），以及其他新的设计工具，提高了我们的工作效率。 技术的革新，带来了提高团队运作效率的良机。 赶紧行动起来吧！

总结 

总而言之，作为设计师，如果你想要轻装上阵，更高效地发布产品，那就通过以下方式，减少自己和开发人员的工作量吧！

• 确保 MVP 能满足用户最基本的需求，适应“快速发布产品、获取反馈、验证假设、逐步改进”的工作节奏。接受现实，承认自己不可能完全了解客户。因此，与其发布一堆冷门功能，不如“摸着石头过河”，逐步满足用户的关键需求。
• 工作时，不要只顾着自己，或者只想着如何让利益干系人满意。 如果你的设计方案根本不会被执行，岂不是白费力气？ 你的目标，应该落在产品本身，而不是“设计作品集”。
• 和产品团队保持同步，每个阶段的计划和目标，都要烂熟于心，做到在对的时间做对的事情。
• 学会团队合作，让每个人都参与设计方案讨论，运用专业知识和工作经验，引导大家提出更好的点子，做到互相学习，齐心协力，为同一个目标奋斗。
• 深入了解产品运营平台和框架，如果不会编程，就尽可能从编程的角度进行思考。设计方案越接近最终产品，越容易让开发人员理解。 
• 与开发人员密切合作，创建可维护的设计规范，这也有助于保证产品的设计风格一致。
• 大胆引进更先进的工具，优化工作流程。

原作者：Billy D Stagg

原文链接：https://uxdesign.cc/cutting-the-fat-from-product-design-5b01b28ff8ed

翻译：即能，公众号：即能学习

本文由 @即能 翻译发布于人人都是产品经理。未经许可，禁止转载

题图作者提供