为您的组织带来更好的设计流程

已发表: 2022-03-10
快速总结 ↬想想你最近的几个软件项目。 在具体的业务目标、满足用户需求和及时交付产品之间是否存在健康的平衡? 实现这种平衡的关键是设计过程能够考虑复杂性、及早解决设计问题并避免过度依赖第三方。

作为用户体验 (UX) 设计师和研究人员,我们从用户那里听到的最常见的抱怨是:

“他们为什么不考虑我需要什么?”

事实上,许多组织都有团队致力于提供用户和客户需要的东西。 越来越多的软件开发人员渴望与 UX 设计师合作,以便编写客户将使用和理解的界面。 问题在于,复杂的软件项目很容易陷入相互竞争的优先事项和对下一步做什么的困惑中。

结果是糟糕的设计阻碍了生产力。 例如,电子病历 (EMR) 阻碍了医疗保健的效率。 对这些软件系统的投诉数不胜数。 波士顿皮肤科医生、耶鲁医学院校友 Steven Ugent 博士也不例外。

自 2010 年起,Ugent 博士使用了两套 EMR 系统: 2010 年之前,他每天 5 点 15 分准时完成工作。 自从他和他的同事开始使用 EMR 后,他通常会在晚上多工作半小时到 1.5 小时。 “我不知道有哪个医生对他们的病历系统感到满意。 疯狂的是,当我使用笔和纸时,我的效率要高得多。”

拿着笔在纸上的男人

EMR 系统笨重、不灵活且难以定制。 例如,Ugent 无法将照片直接嵌入到他的图表笔记中。 相反,他必须打开带有痣照片的文件夹,然后打开另一个文件夹才能看到文字。 对于在治疗患者时严重依赖照片的皮肤科医生来说,这种设置特别麻烦。

Ugent 简洁地总结了 EMR 的问题:

“设计它 [EMR 系统] 的人不了解我的工作流程。 如果他们这样做了,他们会设计一个不同的系统。”

对笨重的软件感到沮丧的不仅仅是医生。 世界各地的消费者和专业人士都有类似的抱怨:

“为什么我找不到我需要的东西?”

“他们为什么这么难?”

“当我只是想购买这个产品时,为什么我必须创建一个登录名。 我给他们钱。 这还不够吗?”

笨拙软件的主要贡献者是有缺陷的设计过程。 在本文中,我们将概述四个设计过程问题并解释如何解决它们。

  1. 复杂
  2. 下一次释放综合征
  3. 设计迭代时间不足
  4. 将控制权交给外部供应商
跳跃后更多! 继续往下看↓

1. 复杂性

规模、多个利益相关者以及对复杂代码的需求是导致大型软件项目复杂性的众多因素之一。

然而,有时会忽略复杂的法律和法规。 例如,保险在州一级受到严格监管,给在多个州经营的保险公司增加了一层复杂性。 银行和信用合作社受监管,而公用事业必须遵守州和联邦环境法。

受 FDA 法规约束的医疗保健产品和软件带来了更大的挑战。 问题不在于规定不合理。 安全至上。 问题是时间、预算和满足 FDA 要求所需的计划。

正如在医疗保健领域拥有丰富经验的 UX 顾问 Jeff Horvath 博士解释说:“这些要求使编写测试协议、测试设置、数据收集、分析、质量控制和首先获得批准进行研究。” 例如,单轮可用性测试从六周(标准可用性测试的合理时间范围)跳到六个月。 这就是单轮可用性测试。 通常,需要两轮或多轮测试。

这种严格程度对于刚开始与 FDA 合作的公司来说是一个警钟。 Horvath 不止一次面临与客户的艰难对话,他们没有为满足 FDA 要求所需的延长时间表和额外预算做好准备。 这很难,但很有必要。 “彻底是值得的,”霍瓦斯说。 2018 年,FDA 仅批准了 11% 的上市前申请。

与传统软件产品相比,需要 FDA 合规性的医疗保健软件对研究人员、设计师和开发人员的要求更高。 例如:

  • 用户体验研究人员每天只能进行一到两次可用性测试,而标准软件每天只能进行五到六次。
  • UX 设计师必须高度关注用户与软件交互的各个方面。 即使是一次令人困惑的互动也可能导致临床医生犯下可能危及患者健康的错误。 出于同样的原因,UI 设计师必须绘制忠实于每次交互的界面。
  • 更长的设计和可用性测试时间意味着必须仔细计划开发人员的编码工作。 熟练且善意的开发人员通常渴望在新信息可用时立即修改代码。 虽然这种方法可以在快速迭代中得到良好实践的组织中工作,但在设计和编码复杂系统时会带来风险。

未能管理复杂性可能会产生致命的后果,正如丹妮尔·麦克雷在即将分娩时被送入塔拉哈西纪念医院时所发生的那样。 为了缓解她的不适,医护人员将她连接到一个病人控制的镇痛机,一个可编程的输液泵。

八小时后,麦克雷因过量服用吗啡而被宣布死亡。 这场悲剧的一个主要因素是用于给药的输液泵设计有缺陷。 该泵需要 27 个编程步骤。 未能通过设计更直观的用户界面来解决这种复杂性导致了不必要的死亡。

解决方案

解决方案是承认并解决复杂性 这点听起来合乎逻辑。 然而,如上所述,复杂的 FDA 法规常常让公司领导感到惊讶。 否认是不行的。 未能计划意味着您的组织可能会落入 2018 年 FDA 拒绝的 89% 的上市前提交。

在进行可用性测试时,用户体验研究人员必须采取三个步骤来管理与 FDA 法规相关的复杂性:

  1. 主持人(运行可用性测试的人)必须非常专心。 例如,如果 MRI 扫描要求技术人员在使用相关软件时遵循严格的步骤顺序,则主持人必须仔细观察以确定参与者是否完全按照说明进行操作。 如果不是,则该任务被评为失败,这意味着界面设计和相关文档都需要修改;
  2. 主持人还必须跟踪近距离通话。 例如,参与者最初可能会乱序执行步骤,发现错误,然后按照正确的顺序恢复。 FDA 认为这是一个近乎未遂的事件,版主必须如此报告;
  3. 主持人还必须评估参与者的知识。 她相信她遵循了正确的顺序吗? 这种信念准确吗?

2. 下一次释放综合症

未能承认复杂性的一个因素是我们称之为“下一个版本综合症”的稍后修复的心态。 软件错误不是问题,因为“我们将在下一个版本中修复它。” 强调速度而不是质量和安全,很容易推迟解决难题。

任何参与产品设计和开发的人都必须解决下一次发布综合症。 两个例子说明了这一点:

  • 我们发现客户的医疗保健跟踪软件存在严重的设计缺陷。 该公司选择在不解决这些问题的情况下发布该软件。 毫不奇怪,客户不满意。
  • 我们为一家位于美国的大型信用合作社进行了可用性测试。参与者是经验丰富的财务顾问。 测试揭示了严重的设计缺陷,包括混乱的状态图标、用途不明确的按钮以及阻止参与者显示重要数据的几乎隐藏的链接。 请记住,如果用户没有看到它,它就不存在。 当我们报告调查结果时,得到的回应是:“我们将在下一个版本中解决这个问题。” 正如预期的那样,Web 应用程序并没有受到好评。 用户的回应包括:“如果您无意进行更改,为什么要让我们审查该应用程序?”

解决方案:拒绝“Fix-It-Next-Time”的心态

解决方案是现在解决严重的设计问题。 听起来很简单。 但是,您如何说服决策者改变根深蒂固的“以后再修复”的心态?

关键是将关于成就的讨论从产品交付转向创造的价值。 例如,花时间根据用户研究修改设计的团队可能会看到更好的客户反应,并随着时间的推移提高客户忠诚度。

通过使用定量数据向决策者展示用户研究与增加收入和积极的客户体验之间的直接联系来加强案例。

使用数据将研究和设计改进与特定业务目标联系起来
使用数据将研究和设计改进与特定业务目标联系起来(大预览)

重新定义价值实际上是一种流程改进,因为它建立了一组新的优先事项,可以更好地服务于客户和贵公司的长期利益。 正如麦肯锡在《设计的商业价值》中报告的那样:“前四分之一的公司拥抱完整的用户体验; 它们打破了物理、数字和服务设计之间的内部障碍。”

3. 设计迭代时间不足

与下一个版本综合症相关的是,没有足够的时间根据研究结果或不断变化的业务需求来迭代设计。 “我们没有时间做那个”,这是开发人员和产品所有者的常见说法。 在敏捷环境中工作的设计师经常面临避免“阻碍”开发团队的压力。

开发速度加快,软件发布。 我们都看到了从令人困惑的电话应用程序到笨重的医疗记录软件,再到上面提到的财务顾问繁琐的用户界面的结果。

解决方案:设计尖峰

一种解决方案来自编码世界。 在他的文章“将大图 UX 融入敏捷开发”中,Damon Dimmick 提出了设计尖峰的想法,“让设计师专注于复杂的 UX 问题的时间泡沫”。 它们通过临时代替常规冲刺来适应 Scrum 框架。

设计迭代
设计迭代(大预览)

设计尖峰具有几个优点:

  • 它们允许用户体验团队专注于整体问题,避免陷入有时在单个 sprint 中强调的细化设计问题;
  • 它们提供了从高层次探索复杂用户体验问题的机会。 如果需要,用户体验设计团队还可以随时进行以设计为中心的思考,以解决更大的用户体验挑战;
  • 通过采用设计尖峰,用户体验团队可以利用开发团队在敏捷过程中使用的相同灵活性,并将所需的时间用于专注于并不总是适合标准 Scrum 冲刺的设计问题;
  • 开发不太可能受到设计决策的影响,可以继续进行。

自然,设计迭代通常会影响网站、应用程序或软件产品的某些代码部分。 出于这个原因,在设计尖峰期间,任何可能受设计尖峰影响的代码都无法继续前进。 但是,正如 Dimmick 明确指出的那样,这种“延迟”可能会通过避免返工来节省时间。 现在编写代码然后在团队同意修改后的设计几周后重新编写它根本没有意义。 简而言之,推迟一些编码实际上可以节省时间和预算。

4.过于依赖供应商

解决复杂性、抵制下一个版本综合症并为迭代留出时间对于有效的设计过程至关重要。 对于许多公司来说,另一个考虑因素是他们与软件供应商的关系。 这些供应商在开发过程中发挥着重要甚至至关重要的作用。 然而,给予他们过多的影响力会使您难以控制自己的产品。

外包给软件供应商
外包给软件供应商(大预览)

当然,我们应该尊重同事和供应商,并提出合理的要求。 然而,这并不意味着有必要像我在一家大型金融公司任职期间那样放弃所有杠杆。

在这家公司担任 UX 设计师时,我经常遇到这种动态:

经理:“嘿,Eric,你能评估一下我们打算购买的这个索赔软件吗? 我们只是想确保它按预期工作。”

:“当然,我会在本周末之前将我的初步调查结果发送给您。”

经理:“太好了”

下个星期:

经理:“感谢您的评论。 我看到您发现了三个严重的问题:难以找到现有索赔的编号、屏幕上有太多难以阅读的文本以及在处理新索赔时难以返回到前一屏幕。 这是令人担忧的。 你认为这些问题会阻碍生产力吗?”

:“是的,我认为这些问题会增加理赔中心的压力和处理时间。 我非常担心,因为我之前与珍妮特团队的合作表明,理赔中心的代表已经压力很大。”

经理:“真的很高兴知道。 我刚寄了支票。 我会要求供应商在发货前解决问题。”

(在里面尖叫):“Nooooooooooooooo!”

这位好心的经理做错了事。 他在寄出支票要求更改。 供应商从未做出要求的更改也就不足为奇了。 他们为什么会? 他们有他们的钱。

这种情况不仅在那家公司反复上演,而且我在我的 UX 职业生涯中见证了它。

解决方案

解决方案很清楚。 如果供应商产品不能满足客户和业务需求,并且您请求的更改在范围内,请在供应商进行更改之前不要付款。 真的就是这么简单。

结论

在这篇文章中,我们确定了质量设计和相应解决方案的四个常见障碍:

  1. 复杂的法规和标准
    解决方案是通过为研究和迭代设计设计现实的时间表和足够的预算来承认和解决复杂性。
  2. 发布带有错误的软件,并承诺稍后修复它们
    解决方案是避免下一次发布综合症并立即解决严重问题。 通过重新定义组织内价值的含义来说服决策者。
  3. 设计迭代时间不足
    解决方案是在敏捷开发过程中包含设计峰值。 这些时间泡沫暂时取代了冲刺,让设计师能够专注于复杂的用户体验问题。
  4. 过度依赖供应商
    解决方案是通过扣留最终付款来保留杠杆,直到供应商做出请求的更改,只要这些更改在原始项目范围内。

第四种解决方案很简单。 虽然前三个并不容易,但它们是具体的,因为它们可以直接应用于现有的设计过程。 它们的实施不需要大规模重组或数百万美元。 它只需要致力于提供更好的体验。