设计的“臭虫”是一个不好的信号吗？

29

如果用户针对设计出的问题提交错误报告，这是一个不好的信号吗？

它是否通常意味着应用程序混乱或不清楚，或者除非特别说明，我是否应该将其归因于一次性用户错误？

（我实际上没有任何此类报告。这是一个纯粹的假设性问题，关于存在由设计引起的“错误”是否是一件坏事。）

bug users

— 麦克斯
source

19

也许Lotus Notes的一些程序员会在意发表评论，因为标准回答是“它不是bug，它是您不了解的功能”。

— 詹姆斯·安德森

5

它向我表明，提供给开发人员的用户要求与用户认为的要求不符。

— temptar 2011年

7

@temptar“这是我要的，但不是我想要的。”

— StuperUser 2011年

5

最近，我为行为指定了一个“错误”工作项，它的行为恰好是规范中明确说明的行为（在规范阶段已进行了讨论）。从用户的角度来看，这种行为很可能是出乎意料的（忽略了在其他地方关注的特定设置），但如果规范实际上只是说“让我们暂时忽略它以节省时间”，对我而言，这不是错误，而是变更请求。当然，希望进行更改是一个很好的例子，但不要把它称为bug。

— CVn

7

@Dunk：我已经实施了一个假设每天24小时运行的系统，因为我们未能说服客户存在夏时制。他们只是不相信会有25小时的日子。那是程序中的错误吗？

— MSalters 2011年

54

这是一个坏兆头吗？我认为这是值得研究的警告，但我也认为它一定会发生。

当人们向我提交任何反馈时，我会尝试将其分为三个部分：

虫子
功能要求
沟通错误

虫子

错误是指某些东西显然无法按您期望的方式运行，也不符合用户的预期。就像，它问我我的名字，我输入“ Scott”，按回车，然后说，“嗨，乔！”

功能要求

这就像“我知道我们从未谈论过，但是程序可以从我的鼠标手势中推断出我是惯用左手并将OK按钮移到屏幕左侧吗？” 这是当前行为符合您和用户的期望，但他们希望更改期望的时候。

沟通错误

在这种情况下，您希望从某个场景中获得一个结果，而用户却期望一个不同的结果。如果他们只是没有传达他们的期望，但有时他们以为是他们的话，有时这会成为功能请求。如果您的期望被证明是错误的，有时这将成为一个错误。

但是，很多时候您都知道该用户没有。如果他们说：“在此屏幕上，我可以用自己的名字和姓氏为自己添加两次记录！这显然是一个错误！” 您的回答可能是：“世界上有很多人的名字和姓氏相同，因此我们不需要这种组合是唯一的。我们有一个清除任务，该任务在夜间运行，并通过电子邮件将可能的重复报告发送给客户服务部门认为它检测到名称和地址相似的重复项，并要求他们手动检查。”

因此，您应该阅读每个错误报告，但是大多数复杂的系统都将具有实际上只是功能请求或可能是对要求的错误传达的错误报告。不了解现实世界的潜在复杂性可能是这些问题的最大根源。

— 斯科特·惠特洛克
source

3

错误的沟通还包括错误地记住（或完全忘记）已传达并达成共识的期望。

— 彼得·泰勒

1

有很大的区别，但我仍然认为该应用程序应尽可能解释这种误通信。在您的多个人同名的情况下，该应用可能会说：“我们已经有3个John Smiths，您确定它不是其中的一个”，并带有“否，我确定这是一个新的John Smith”选项。

— 亚历克斯·安德罗诺夫

@Alex Andronov-沟通不畅并不表示您无需采取任何措施：更改文档，工具提示等，更新培训材料，或者可能只是简要说明并继续。

— Scott Whitlock

7

到目前为止，以前的答案都没有涉及到这一点，因此我要补充一点，这也可能是用户群愚昧的标志。我不会以贬义或屈尊的方式使用“无知”一词，而只是表示他们在其领域或软件本身的复杂性方面没有适当的知识或知识而表达的方式。

大多数用户并不知道要满足某些要求就必须多么复杂。只有80％的工作量会影响功能的20％（附带和例外情况）。

他们有时不理解为什么软件固有地需要以某种方式运行多次，以防止多种缺陷或数据损坏等。

不必担心，因为有了清晰简洁的文档和交流，情况会变得更好。

— maple_shaft
source

2

+1，但请查看复杂与复杂之间的区别...软件根本不需要复杂，但是通常很复杂。

— Marjan Venema

这是真的。我遇到的最常见的情况是用户没有意识到多对一与多对多关系之间的区别。我收到的一个常见请求是：“您可以让报告在标题中显示订单号吗？” 我必须解释一下，尽管在大约95％的情况下，他们处理的商品上只有一个订单号，但在许多情况下，查询中可能包含多个订单的数据。然后我要问，您是否要在标题中列出所有订单号（以逗号分隔），还是要在报告中的每个明细行上列出订单号？

— 斯科特·惠特洛克

@ScottWhitlock是的，是同一回事。那么，优秀的开发人员或业务分析师不仅应该按照客户的要求进行操作，还应尝试揭示他们正面临的核心问题，即为什么他们首先提出这样的要求。一旦确定了他们的问题，就可以确定适当的解决方案并编写适当的要求或用户案例。

— maple_shaft

5

如果您的用户是其领域的专家，则可能会遇到重大问题。想象一下，一名会计师在设计上发现您的软件时没有遵循一般的会计程序，或者工程师发现您的公式不正确。要研究它们是否正确，应该不难研究。重新设计并根据需要快速修复。

至少在您获得更多反馈之前，应考虑对他们认为应该具有货币符号或其他格式的特定UI功能或字段的意见。研究这可能会有点困难。

— 杰夫
source

1

我想没有一个答案。应根据具体情况进行评估。我想了很多。

— Maxpm 2011年

5

根据我的经验，设计错误意味着您的用例不适合实际用户。尝试阅读有关在用例中使用真实用户的信息（仅给他们提供名称和缩略图说明确实会提高用例的质量。）

当著名的OS供应商说“这种行为是设计使然”时，他们通常会想到易于实现或具有商业优势。如果不是您，请尝试找出用户的真正技能和与软件的关系。他们整天使用它吗？为了娱乐？是否因为每周更换一次TPS表格？

— 蒂姆·威利斯克罗夫特
source

5

用户界面应遵循“最小惊讶原则” -有关按设计工作的功能的重复错误报告表明该原则未得到正确遵守。

— 乔里斯·蒂默曼斯
source

3

或者，有一个分散的用户组。例如，假设您的网络应用模仿了桌面。您是否希望关闭窗口会关闭程序？Windows用户为“是”，Mac用户为“否”。

— keppla 2011年

1

@Keppla-你说的很对。您不能取悦所有人，因此对于“错误”（如此处所述），需要进行一些调查，以确保在“修复”之后不会收到比以前更多的错误报告。

— Joris Timmermans

1

也许吧，但是引用“数百人为此提交错误”的数据要强大得多。而不是让一些狂热的用户告诉您，您违反了他们对“最少惊讶的神奇原理”的个人解释，因此他们感到惊讶。我对后者有些厌倦，因为一个人的“惊讶”是另一个人的“直率”。

— 杰夫·阿特伍德

@Jeff Atwood-俗话说“一口吞下一个夏天”，“一个错误报告并不意味着设计错误”。一项关于某项功能的错误报告并不需要重新设计，甚至关于一项共同功能的几份报告也不一定意味着您的大多数用户如果没有“修复”就不会感到高兴。特别是如果您的原始发行版已经很流行并且人们已经习惯了“那样”使用它。

— Joris Timmermans

2

有两种错误：功能与程序员的意图不符，或者功能与要求不符。程序员倾向于把重点放在前者上，而损害后者。简而言之，如果您的用户报告了很多“设计错误”，那么您的需求就不是您认为的那样。

— 卡尔·比勒费尔特
source

2

不必要。所报告的错误可能是由于该软件的使用超出了其最初定义的范围。考虑设计用于A，B和C的软件（举一个简单的例子，画线，三角形和矩形）。如果D是合乎逻辑的下一步（例如，五边形），则用户可以认为D也应该这样做，并且不这样做是一个错误。但是，如果这超出了原始范围，则不是错误。相反，它可能是设计中的疏忽（错误），或者是规范中的灰色区域，或者是开发人员和用户所做的一组不同的假设。

（编辑-根据@Marjan Venema的建议将我的评论添加到答案中。

— 詹姆斯·麦克劳德
source

我真的看不到被标记为错误报告。更像是建议或功能要求。（尽管，对于某些错误跟踪系统，无论如何它都可以算作一个。）

— Maxpm 2011年

1

我大部分时间都同意，但这可能意味着设计上的疏忽（错误），规范中的灰色区域或开发人员和用户所做出的不同假设。

— 詹姆斯·麦克劳德

1

詹姆斯，如果您在评论中添加该评论，则整个答案会更好。

— Marjan Venema

1

我认为这是一个不好的信号，主要是因为该设计不是通用的，并且用户需求没有得到充分的理解/分析。

我看到了两种设计方法：-偶然设计。-故意设计。

偶然的设计经常导致此类问题，并且无法持续。

— 18字节
source

1

我想在maple_shaft关于用户“无知”的答案中添加一些内容。您还必须记住，90％的用户只会在乎自己的体验和使用系统的方式。他们不在乎其他用户，为什么要这么做？作为设计师/开发人员，我们的工作是吸收所有不同类型用户的意见，并做出最适合所有人的内容。在大多数情况下，您无法为所有人提供最佳解决方案。

但是，当然，您需要阅读和评估用户的反馈！毕竟，他们是那些使用您的创作的人！

— AndSoYouCode
source

0

通常，在设计上不咨询提交错误请求的用户，因此将其视为错误是经过深思熟虑的设计决策也就不足为奇了。对于用户而言，任何无法正常工作的东西都是一个错误。

我发现问题通常是表明BA或PM仅从管理人员而不是实际用户那里得到要求的迹象。管理人员对系统的期望通常与输入数据的人的实际需求有很大不同。我被教导要直接从实际用户那里收集数据，但是最近我遇到的大多数BA都只与经理（通常是那个相对高级的经理）交谈。

— 赫尔格姆
source