我们如何设计企业软件

原文地址:https://blog.usejournal.com/how-we-design-enterprise-software-916124fb73db
原文作者:Lee Munroe

 

Mesosphere 产品设计团队负责 Mesosphere 产品的用户体验。通常情况下,这个用户体验主要与我们的旗舰产品 DC/OS相关,但同时也涉及我们的 CLI(命令行界面)、API(应用程序编程接口)、文档和其他开源产品的用户体验。

我超喜欢设计团队写他们的工作流程。阅读和学习其他团队是如何做的、他们遇到的问题以及他们是如何克服这些问题是非常有帮助的。

 

受到 Buzzfeed、Airbnb 和 Shopify 等团队的启发,我们最近记录了我们的产品设计工作流程。我们并不是第一个将工作流程在博客上的人,但是我认为这是一个有效的练习,因为它迫使我们将工作流程写下来,与他人分享,并对其进行评论。

我们的目标不是强制执行一种新的工作方式,而是观察和编撰当前有效的方法,并创建足够的结构来帮助在项目整个生命周期(包括设计团队内部和外部)中进行沟通、明确和透明。

——Tom Harmon, Buzzfeed 的设计主管

关于 Mesosphere

简单介绍一下。在 Mesosphere 我们提供产品和服务,帮助像 Yelp、Verizon 和 Bloomberg 这样的公司管理他们的信息技术和基础设施。我们的旗舰产品 Mesosphere DC/OS 是一个数据中心操作系统,它跨多个服务器共享和管理处理器、内存和存储资源。公司在他们的技术设备上运行 DC/OS(例如亚马逊网络服务、微软云服务、谷歌云平台、本地部署),然后在我们的平台上运行他们的工作负载(例如应用程序、容器、网络服务器、机器学习、大数据)。

鉴于我们软件的关键性质,以及它是跨公司服务器安装的操作系统这一事实,我们没有每天更新发版的奢侈。我们有一个相当罕见的发版周期,每年发行三次大型版本。

产品设计师的角色

我们与产品管理工程紧密合作,为了向我们的客户提供有价值、可用和可行的产品和功能。每一个项目都是一个三脚凳。一个成功的项目,需要表示这些产品团队中的每一个。当然他们并不是唯一参与其中的代表,但是处于项目核心,他们必不可缺。

  从一开始就融合工程、产品和设计...团队应该就像三脚凳一样,每一条腿都代表三个领域当中的一个,可以帮助构建产品。如果从一开始就这样做(图A),那么每一个功能够随着更广泛的组织规模以并行和适当的比例增长(图B)。

——Alex Schleifer, Airbnb 的设计总监

我们实践双轨产品开发,我们有一个与交付轨道并行运作的发现轨道。交付轨道的重点是为了下一版本的开发特性,发现轨道的重点是下个版本之后的事。

设计师花费他们大部分时间在与产品经理和技术主管的发现轨道上,专注于快速学习和验证。

来自 Jacob de Lichtenberg 的插图:敏捷双轨制

为什么文档化你的设计工作流很重要

随着公司和设计团队的成长,我们注意到了一些事情。

  • 设计师在他们的项目中使用不一致的工作流;
  • 整个公司对我们的团队到底是如何工作的,甚至我们都做过什么都缺乏了解;
  • 新晋设计师,无论是新员工还是其他设计师,在一个正在运行的项目当中提供帮助,并不像他们本可以做到的那样天衣无缝;
  • 我们脑袋里有一大堆未成文档或是公开的问题,我们都有自己的假设,但是一直都没有写下来;
  • 设计师并没有像他们所能做到的那样快速移动,因为他们不确定什么时候登记,或者是否需要许可才能做出某些做决定。

我们是怎样做到的

这不是你一个人做的事。这需要作为一个团队来完成,同时也需要跨职能部门的支持。我们拿了一些记号笔和便利贴,在日历上划出 2 个小时,开了一个设计工作坊。

我提出了上述问题的概述。然后我们查看了来自其他设计团队的一些博客文章(例如 Buzzfeed、Airbnb、Intercom 和 Shopify),看看他们他们正在做什么,以及来自 Ideo、Google Ventures、Design Council 等一系列业内工作流。然后我列出了我希望通过这个练习来完成的内容:

  • 调整团队并记录我们的工作流程;
  • 教育公司;
  • 使新设计师更容易的融入团队;
  • 加速设计师开始新项目的速度;
  • 授权设计师做决定,这样他们可以加快进度。

我们有一个白板会议,写下哪些阶段成为工作项目的一部分。一旦我们使用不同颜色的便利贴为各个阶段分组,就明确了设计师在每个板块应该做些什么,并为我们想要讨论并有明确答案的开放问题使用另一种颜色。

设计工作坊的设计阶段,设计师在每个阶段所做的工作,和任何开放性问题。

一旦我们作为一个设计团队对它的结果感到满意,我们就会与产品管理和工程领域的同行分享这些结果,以征求他们的意见。

为什么我们不采用一个已经存在的设计流程?

Design Council’s双钻设计法

 

斯坦福大学设计学院、Ideo、设计委员会、谷歌风投。当然我们可以采用一个完善的设计流程,它也可能帮助我们达到 80% 的目标。但是每个公司和团队的工作方式都是不一样的。

有许多因素有助于优化设计工作流。我们在公司的哪个阶段、我们多久发布一次新功能、团队的规模、产品和工程团队的工作方式、敏捷开发或流程开发或者两样都有。拥有不仅仅适用于 UIs(用户界面),而且还适用于 CLIs(命令行界面)、APIs(应用程序编程接口)和其他一些项目类型的工作流。还有很多因素需要考虑。

这一点以及作为一个团队设计工作流的行为是非常有益的。每个人都有机会发表自己的意见,整个团队都参与到结果中来。

从这个过程当中产生的是一个 8 个阶段的设计流程,我将为你分解一下。

定义

设计主管

我们认为确定设计主管的确切角色至关重要,这样从设计的角度来看,谁拥有决策权以及期望是什么就很清楚了。设计主管应该:

  • 是某个项目的指定设计所有者;
  • 负责为任何给定的设计项目提供令人愉悦的、有用的、可行的解决方案;
  • 不仅仅负责交付设计工件,还负责将最终产品交付到我们的用户手中;
  • 是设计联络点,通常来说与产品经理、技术主管、工程经理和工程师们密切合作;
  • 与产品管理和工程部门合作,从视觉设计和用户体验的角度做决策;
  • 负责收集所有利益相关者的反馈,确保所交付的内容反映了公司的业务目标、设计原则和品牌。

设计项目

必须有某种组织和项目优先级系统来帮助我们定义什么时候在活跃储备中确认某个项目。设计项目通常由产品路标图(产品经理拥有)驱动,但它们也包括设计或其他团队希望驱动的项目。例如改进特定组件的用户体验。

  • 设计项目是设计团队已经接受的一项活动或是工作;
  • 通常情况下,这是一个设计未来体验的计划,它将在即将发布的版本中构建,这个版本可能包含 GUI(图形用户界面)和 CLI(命令行界面)组件,也可能不包含。这个计划可能是对未来想法进行的一次探索,而这个想法我们可能希望推进,也可能不希望推进。
  • 每个项目都有一个专门的负责人,但可能有很多设计师都参与其中;
  • 一旦设计就绪,项目就被认为是“完成的”。然而,设计主管的工作就是继续跟踪面向用户的功能质量评估和开发,并设置任何可以提升该特性所需要的附加项目。

Mesosphere 的产品设计工作流

第一阶段:定义问题

确认你理解了问题,并且它是由最初的需求、范围和用户故事定义的。当然也确保了跨职能团队在这个问题上的理解是一致的。

  • 理解客户是谁,谁是提出这个或者遇到这些问题的人;
  • 与跨职能部门的人开会;
  • 确保角色清晰;
  • 想象成功的项目是什么样的;
  • 创建与此项目相关的文档(例如范围文档、wiki 页面以跟踪进度、会议、任务和待办事项)。

第二阶段:研究问题

我们使用 Dropmark 收集灵感

理解用户现在遇到的问题并为他们建设同理心。尽可能搜集更多的信息,并将其转化为团队可消化的知识。

  • 与符合用户画像和有过类似问题有经验的用户/客户交谈;
  • 与内部专家与利益相关者交谈,谁在支持这个?
  • 查查看其他人是如何解决这个问题的。竞争对手或类似的工具和模式;
  • 在 wiki 里记录并与团队其他成员分享你所学到的知识,这样你们对这些问题就有了共同的理解;
  • 了解存在哪些技术限制。这些 API 现在还存在吗?

第三阶段:初步概念

和跨职能部门团队一起使用 6 步法进行设计工作坊,来鼓励更多的想法。

概念过程包括在解决问题之前,把大量的想法摆在桌面上来分散你的想法。让整个跨职能团队都作出贡献。他们脑袋里有你没有的想法。

  • 草图、线框图、流程图;
  • 促进与跨职能部门一起进行头脑风暴和设计工作室会议;
  • 从设计同仁那里得到反馈和建议;
  • 检查可行性。什么是可实现的?与工程部和产品经理紧密合作,确保这一点。

第四阶段:集中完善

我们使用 InVision 做可点击的原型

采用你最好的设计并创建可测试的方案(比如原型)。围绕最好的解决方案进行更详细的设计。

  • 创建可以被验证的方案,比如框架图、流程图、可点击原型(InVision、Framer 等);
  • 在每个环节中逐渐提升保真度;
  • 早期过高的保真度不太好,因为它会让你对解决方案感到疲倦,而批评的焦点经常是按钮颜色,而不是这否是一个正确的流程;
  • 过低的保真度会影响人们的反应和反馈,他们可能无法完全掌握最终的设计。

第五阶段:验证问题

与利益相关者、用户和客户验证解决方案和风险最大的假设。把你的知识带回到之前的阶段,直到你达到你自信的解决方案。

  • 运行或参与用户测试会议;
  • 与用户进行电话沟通;
  • 与开源社区和用户体验研究邮件列表共享工作;
  • 与整个团队确认当前方案的可行性;
  • 与核心利益相关者一起评审。

第六阶段:交付设计

对于我们的大多数项目,我们提供了一个很好的 Confluence wiki 页面文档,可点击的 InVision 原型和包含任何新的或相关图形的 Sketch 文件。

在每个发版开发周期(提醒:我们每年有三个版本)之前,都有一个发版计划阶段,在这个阶段我们将概述即将发布的版本的可行性。这个计划包含了很多公司的代表。

一旦我们知道规划的范围,我们就可以增加优美像素和清除我们的设计。我们知道在开发过程中随着约束条件的出现而发生改动,我们可以学到越多。但是我们应该考虑我们的设计已经为工程实现做好了“准备”。

  • 增加精良的设计。检查品牌和设计系统的一致性;
  • 确认原型是最新的;
  • 确保任何流程或附加的设计工件都符合修改后的范围;
  • 更新 wiki 包含设计用户故事和行为,并使用他们帮助工程师为他们的工作创建任务;
  • 确保状态被全面考虑,并在需要的时候提供设计,例如错误状态、空白状态,开源与企业;
  • 与参与项目工作的工程师和文档团队进行详细的演练。

第七阶段:进行开发

我们的前端堆栈包括 React、Node 和 Webpack

一旦项目进入开发阶段,工程部门就会积极地实施解决方案。设计提供持续的 QA(质量保证),并在需要的时候提供指导。

  • 坐下来协助开发人员一起积极开发功能;
  • 为出现的问题快速的提供解决方案。此时,Sketch 或 quick mocks 是首选;
  • 进行演示;
  • 此时设计师可能会将他们 80% 的时间用于下一个版本的设计并发现上。

第八阶段:衡量结果

只有当功能被交付给用户并且用户能够实际使用它时,才会认为它已经完成。然而,一旦发布,你仍然应该继续收集关于解决方案的内部和外部反馈。

  • 对任何相关问题创建事件(任务、错误、建议);
  • 与产品和分析部门合作,衡量解决方案作的影响;
  • 继续通过用户测试和研究继续收集定性数据;
  • 与跨职能部门进行回顾。

产品设计反馈环

 

在每一个阶段我们都被鼓励经过一个设计反馈环。反馈环的灵感来自 Buzzfeed。当你制作一些东西(草图、白板或模型),并展示给其他人(同事、工程师、用户),得到他们的批评与反馈,综合(你同意他们的观点或者你同意谁?)然后迭代。

设计是一个不断迭代的过程。重要的是我们要有这样的心态,这就是它的工作原理。

项目时间表

这取决于项目的类型和规模。小项目和小团队可能很快。跨多个团队的大型项目为了一个大型版本,然后与多个利益相关者有许多迭代和反馈会议。

 

这是一个关于时间线的示例。这对每个项目都是有变化的。重要的是我们接触的每一个阶段,并始终记住反馈环。

一些经验教训

  • 你的工作流程需要你的跨职能部门团队的参与,特别是那些你基本上一整天或整个星期都在一起工作的人。
  • 有前端工程加入,我们能解决诸如“何时设计被认为是完整的?”之类的问题。我们的回答总是“设计从未完成。”显而易见这对他们没有用。但是,讨论会帮助我们定义设计“准备好”,即“准备好让你接受并实现它”的时候。
  • 有产品管理加入,我们能够解决我们没有及时参与的问题。或者产品经理们没有在可用性测试或者用户体验走查时参与完全。我们可以跟他们讨论更多工作流程当中他们真正在意并想参与的环节,同时设计师也希望参与更多与产品讨论的部分。
  • 将这些放在 wiki 上很好,但是显然不够。你需要不断教育和传播这些东西。在博客当中写出来,在邮件里、在 Slack 中发出去。向新的(跨职能)团队成员当中展示、在会议上站起来谈论它。

总结

如果你还没有为你的团队做这些,那么我非常建议你这么做。你可能认为你们在事情的工作方式上是一致的,但是像这样去做一个练习并记录结果会帮助你解决任何可能存在的问题或不一致的地方。

把所有人叫到房间并讲述你的工作流。使用便利贴,这样所有人都有机会作出贡献。在每一次之后进行回顾并决定什么是有效的而什么不是。继续迭代并设计你的工作流。

最后,继续在公司内传播你的工作流程。不要期待其他人只知道你是如何工作。推销它是你的工作。

作者: nano

双鱼座,猫,设计师,间歇性视觉动物,酒窝,纹身,无知少女,画画

发表评论

电子邮件地址不会被公开。 必填项已用*标注