如何真正地为产品设计流程减脂？【UXRen译#265】

由宝珠 · 发布日期 2018-11-12 · 已更新 2019-04-09

作者：Billy D Stagg | 翻译：Nina 审校：橙儿 & 若初

几年以前，我曾经为一个大的组织机构重新设计他们的传统应用。有机会定义全套web应用之后的用户体验是设计师梦寐以求的任务。发布的第一个应用程序将为之后其他的应用奠定基础。

当时，我没有浪费时间，立即着手去研究用户，了解已有的软件，与产品负责人以及各种干系人一起，整理出了需求文档，使团队得以开始工作。

在几周之后，大家都比较好的理解了当前的挑战，我们开展了工作坊来具象新的产品。与此同时，只要我们验证和细化了需求，并且给出可以开展工作的粗略线框图后，开发团队就可以开始搭建一些必要的基础架构了。

快速推进的几个月，我们经历了从草图到线框图的过程，概述了关键用户旅程的用户流，设计了UI 组件以及详细的规范，甚至有了演示我们所期望产品如何工作的原型。我们也到用户那里去测试了我们的设计，收到了很好的反馈，所有的一切看起来都是在朝正确的方向发展。

只有一个问题，我们能开发出来的东西和我们想要开发出来的东西离了十万八千里。

上述的问题并非罕见，一次又一次，我们看见团队的创新设计是要么做不出来的东西，要么做出来的版本和我们预期的设计和体验相距甚远。

这样来发现或者验证一个概念是没有问题的，但在快速发展的行业中，我们需要快速、频繁地发布产品，以保持在竞争中的领先地位。

在过去的几年当中，为了改进产品开发流程，我调整了我的流程。在这里和大家分享一些关键的变化，期望也能够帮助到你和你的团队。

MVP不只是说说而已

你可能听过“我们需要一个最小可实现产品（即MVP产品）“几千次，但是它不该只是一个流行词。如果你完全理解了什么是最小可实现产品，那么你就可以把团队所有的精力和努力都专注于发布。为一次快速的发布，你的团队必须愿意去发布最基本的产品。这可能对于干系人来说，是比较难以接受的，因为他们给予的预算是为了产生全功能的产品。但是这样做的好处是显而易见的。

越快速的发布，你就能越早地将产品提供给用户，从而得到有用的反馈，同时洞察之前没有思考到的地方。而且，你越早开始获得用户，你的用户群就会越快增长。在获得用户数月之后，你就会领先于比赛。

你需要接受，MVP产品也许不是立刻就有竞争力，但是也不需要立即进行大规模营销。关键是要发布你能快速发布的内容，为持续不断的改进铺平道路，从而为用户提供持续增长的价值。

Slack就是一个很棒的例子，它就是依靠来自用户的反馈来帮助改善他们的产品。在没有CMO（首席营销官）和大规模营销活动的情况下，他们通过倾听和逐步改善产品来赢得用户的心。

不要单打独斗

对于个体创造者而言，我们通常喜欢闭门造车，不考虑超出自己控制范围内的事情。我们的交付成果是我们所关心的，只要交付物能够正常工作并且看起来不错，那我们的工作就算完成了。如果最终的产品看起来或者感觉不像我们的设计，那也不是我们的错，对吧？

人类是情感化的存在，并且受视觉刺激的影响。让干系人惊叹，并且留下长久的印象，是很容易的。作为创造者，我们仍然要根据别人的意见来做取舍。

但是，如果我们忽略高保真的模型和原型，信赖产品发布后的结果而非一些令人惊异的独立环节，这样做会不会更好？

我的意思并不是说，我们放弃做那些每个像素都完美的优秀作品。我之所以执着地追求完美，可以追溯到以前800*600显示器就能清晰地呈现off-pixel 设计的时候，那时候，（大家认为）最终提交的产品都应该是完美的。正如salesforce设计团队所说：

通过体贴优雅的技艺，展示人们对时间和注意力的尊重。

高保真的设计通常可以让我们去测试一个真实的产品，验证我们的假设和确认可用性。但是更重要的是, 我们不用浪费时间去做一些演示片段去吸引干系人，然而却从未真正的去开发它。所以，还是专注于那些实际生活中会用到的产品吧。

找到正确的节奏

为了减少那些不必要的工作，我们需要意识到所有对我们正在设计的产品发生的一切。路线图，备份日志，下一步的开发计划，在每一阶段开发人员具体做什么。坐在外面瞎想想，觉得你表现出团队精神，产品就自己完成了，那是不可能的。

产品团队容易把设计考虑在外，或者认为只是一个锦上添花事后考虑的工作，这些情况并不少见。作为设计师，我们希望创造性地解决问题，利用我们的经验和获得反馈来验证正确的解决方案。我们不想被告知“只是让它看起来不错”。

认识到正在发生的所有事情，并且确保设计是产品开发、发布周期不可或缺的一部分，不仅可以帮助你的设计看见曙光，还可以将其他的团队成员带入其中，这就引出了我下面要说的一点。

分享所有权

如果你足够幸运，在产品开发的初期就加入了，那就确保我们的想法涉及到每个人。这会让团队成员有参与感，并且给予他们作出贡献的机会。没人想要别人来告诉他该做什么，所以分享想法的所有权，用你的专业知识和经验来促进。团队会更加愿意提交一个共同的想法，并且这能让大家保持一致。你也会发现当所有人都同意且有共同的目标的时候，团队的士气就提高了。

如何获得代码

设计师是否应该编写代码一直是多年来的热门话题。有人就乐意做一个UI开发者，就像我自己愿意做一个UI设计师一样。我也许有一些偏见。我理解花很多时间来学习怎么编程是一件很奢侈的事，但是好处是显而易见的。对我来说，能够编程给了我一种能够用代码来表达自己想法的自由。有时不需要去写具体产品的代码，即便写快速粗糙的代码，也向目标平台（的实现）提供了经验，减少了解释或稍后尝试重新创建设计的错误数量。

如果设计师不愿意或者不能写代码，那他们至少应该理解他们为之设计的平台。一个建筑师不考虑材料和环境，是没法设计房子的。

这些怎样帮助你的产品减脂？这应该是显而易见的。拥有能够协调那些产品中要用到的资源的能力，会节省编码所需的精力。如果你理解你为之设计的平台或机构，这将会使你在其约束范围内进行设计。

表的控件有列过滤么？选框控件是否可以读取数据，还是所有的选项都预加载？如果控件X和控件Y均能实现相同的功能，那哪一个最容易在开发中实现？

一系列可复用的控件节约了大量的时间，所以你对这些控件越了解，你越能够通过对其进行定制来满足你的需求。

你的设计离技术上的可实现越远，你就会浪费更多的精力修正设计，开发工程师也会浪费更多的努力去满足你和干系人之前确认过的设计期望。

此外，在过去的几年当中，我们设计和制造产品的方式有了巨大的变化，风格指南，模式库和新的设计工具让我们前所未有的提高了效率。更好的技术知识意味着你现在可以真正的以以前无法做到的方式提高团队的工作效率。那你还等什么呢？

总结：

总而言之，如果你是确实想为产品设计减脂，并且有效的发布产品，减少自己和研发团队工作量的人：

理解向用户提供的交付物的最低限度，接受快速发布、获得反馈和验证少量更改远远比一次就交付大量未使用的功能要好。
为了自己的利益，避免独自工作或者试图给干系人惊喜。
如果你的工作将不会被发布到一个真正的产品中，或者帮助改善一个真正的产品，你的努力就白费了。你的目标是发布一个产品，而不只是一个演示片段。
把自己和产品团队同步起来，了解计划是什么，在每个阶段要提交哪些东西，那么你在需要的时候就能提供适量的交付物。
以团队工作，让每个人都参与到构思中，运用你的专业知识和经验来引导和促进。
你们会相互学习，大家会达成一致，从而聚焦在同一个目标上。
了解你为之设计的平台和机构。
如果你不会写代码，那就和研发人员密切接触。最终产品中的设计间隔越小，研发人员在阐释时发生的偏差就会越小。
和研发人员紧密合作，建立或者识别控件，并创建包含可复用性的风格指南。这将会强化你产品的一致性。
拥抱设计工具的进步，优化你的工作流程。

如果你能分享你的经验，以及你是怎样成功加速产品发布的心得，那就太好了。你可以在下方的评论中留言，如果有什么问题，也可以直接联系我们。

感谢阅读！