it-swarm.cn

我们应该杀死用户不经常使用的功能来提高性能吗?

根据我们为应用程序(广告服务器)生成的热图,用户很少对列表中的项目进行排序,他们通常使用搜索来查找要查找的项目。开发人员表示,如果我们删除排序功能,它将大大提高应用程序的性能。

我对此变化表示怀疑,因为这是能够对长列表中的数据进行排序的最佳实践(我们的列表可以达到100个项目),但与此同时,应用的性能(加载时间)对于公司。

有什么建议么?

注:

感谢kettch提出以下问题:

您的用户是否知道这些列是可排序的? -是的,在用户测试中,几乎所有用户都注意到可排序标题

数据集的平均大小是多少? -通常,您每页可获得50行,但是现在,标准广告系列经理(我们的目标)每页仅需要4-5个项目

为什么进行排序的用户使用该功能? -我对此没有明确的答案,我想说的是,他们试图通过按节奏或点击率对广告系列进行排序,以找出效果不佳的广告系列

数据网格是否如此缓慢以至于用户从未使用过它? -不,实际上它很快,但是-显然-排序功能正在引起数据库问题并在数据中造成差异

开发者注意事项:

  • 由于实际上只有不到5%的用户正在使用此数据进行排序,因此更新数据所需的调用数量使该问题在postgresql中出现,以便我们可以对其进行排序。
  • 不会像现在这样永远扩展

同样,通过按照我们计划的方式进行操作,我们将获得的收益:

  • 即时的。喜欢,真的是实时的。每次刷新页面时,您都会看到最新的效果(而不是2分钟后)
  • 不仅对于清单,而且对于整个产品都有更好的性能。减少部分应用程序的“冻结”
  • 成本优化,因为我们不需要每2分钟计算一次,尽管没有人实际看到数据(在夜间或其他任何时间)。我们只会在必要时进行计算

enter image description here

101
Deniz Erdal

除了这里其他好的答案所说的以外,您还有一个更基本的问题。您误读了数据。

热图通常会汇总像素上的所有单击,而不管是谁制作的。而且您(以及其他答案)似乎将此热图解释为曾经点击该像素的用户比例,这是一副完全不同的茶。

想象一下,您有一家网上商店。标准的热图将在与浏览,查看评论等相关的功能上显示大量点击,而对“结帐”按钮的点击则很少。这并不意味着没有人使用该按钮,而是意味着人们在访问期间单击了很多其他东西,然后只下了一次订单。这正是您希望他们采取的行动!在您的情况下,您的每个用户完全有可能使用排序,但是每次访问只需要进行一次排序-仍然认为排序对他们的任务非常有帮助。 (我并不是说这一定是正在发生的事情-但是对于您的数据,您不能排除它)。

为了获得所需的信息,您将必须生成完全不同的信息显示,该显示将点击与创建该点击的用户相关联,并且每个用户只计算一次给定元素的点击。这将告诉您有多少用户未使用该功能。

一旦获得了这些信息,就可以开始考虑是否应删除少数访问者使用的功能。 (如果您发现只有10%的用户曾经在您的网上商店中结帐过,是否会删除“结帐”按钮?)

205
Rumi P.

表现很重要,但更重要的是要达到目标。

考虑什么样的用户正在使用排序功能。例如,因为可能会遇到这些用户,尽管人数很少,但却是您有兴趣支持的用户。

我建议 A/B测试 来查看删除排序如何影响您的目标。您可能会发现您想增强搜索功能,但仍然保持排序。

86
Alvaro

您的用户知道列是可排序的吗?

我之所以这么问,是因为即使第一列上似乎有一个排序指示器,用户也可能没有意识到他们可以单击标题。

数据集的平均大小是多少?

如果在搜索后,我可以在一个数据屏幕中获得所需的所有信息,则可能不希望进行排序。

为什么(使用该功能排序的用户?

这是 分类 与上一个问题有关。并非所有用户都喜欢搜索。我见过用户只是采用默认数据并按“ n”键滚动滚动至幸福状态。

数据网格是否如此缓慢以至于用户从未使用过它?

由于性能问题,用户是否可能不喜欢排序?作为涉足UX的开发人员,我不确定我是否会购买性能障碍。除非您的应用程序在每次排序时都执行巨大的聚合,否则没有理由不能先对数据进行聚合然后对结果进行排序。您甚至可以定期预先计算聚合。排序的存在不应该成为问题。

40
kettch

这可能与主题无关,因为它更多地位于事物的开发方面。作为一个全栈开发人员,我可以说搜索功能可能会提高性能。所有这些都取决于要搜索的内容,要搜索的数量,最初要执行的筛选等等。我希望开发人员重新评估初始搜索功能,并查看可以改进的地方。通常总会有改进的空间。

如果操作正确,可能来自开发人员的注释不准确。 “排序功能会在数据库中引起问题并在数据中造成差异”仅此注释会使我感到厌倦。对我来说,这是一个懒惰而又不想改善的方法。

如果这些选项对页面很重要,那么我不会删除这些选项,因为它们对于搜索选项的启动方式影响不大。我只看到3个过滤器,但这对性能没有太大影响。

也可能是过滤器的位置影响了它们的使用,改变它的位置可能会产生不同的结果。您可能会考虑哪些过滤器对于用户实现目标并根据需要进行调整最重要。

25
Micah Montoya

一些好的想法已经被分享了,所以我只添加一件事,我没看到。尽管有关功能使用的定量数据很重要,但它并不能揭示为什么用户正在排序或未排序。听起来像您一样,设计师在排序功能中假设了一些可感知的价值,因此弄清楚这些假设是否与您的用户的想法相符(超出数字范围)可能是一个有益的下一步。

10
Josh Olsen

您应该对极端始终谨慎对待删除功能。对于为什么客户选择他们的产品而不是竞争对手的产品,大多数公司并不十分了解。总是有可能您不小心删除了一项杀手级功能并使自己破产。您需要有很好的业务理由才能删除功能。从您的问题来看,听起来好像您实际上没有删除任何功能的business原因。因此,简短的答案是,不要删除它。

现在,如果性能really很重要,例如在您的客户中抱怨,然后因为产品太慢而离开竞争对手……那么您可以开始考虑将应用程序的某些部分拆掉以修复性能。这是一个实际的业务决策,需要利弊和预期结果,需要进行计算和考虑。在这种情况下,您需要考虑由于失去客户而实际上损失了多少钱,加上解决问题要花费多少钱,或者如果移除功能X来完成,您期望损失多少客户?所以。

但这是一项业务决策,需要大量(我的意思是很多)有关您的业务和客户的特定信息。基本上,我们不太可能为您解答。

从正面看,从您的问题来看,听起来像NO REASON WHATSOEVER可以删除此排序功能。

同样,通过按照我们计划的方式进行操作,我们将获得的收益:

Realtime. Like, really real-time. Every time you refresh the page you would see the latest performance (and not 2 minutes after or whatever)
Better performance not only for the list, but for the whole product.Less "freeze" in part of the apps
Cost optimisation, because we wouldn't need to compute it every 2 minutes, altough no one would actually see the data (during night or whatever). We would compute it only when necessary

这些都与排序无关,或与排序无关。特别是,我想说的是“而不是2分钟之后”或“因为我们不需要每2分钟计算一次”。这非常有力地表明您的数据库体系结构存在主要问题。首先,您应该从不将计算值存储在DB中,因为这样数据一致性成为噩梦。由于您还偶然提到:“显然,排序功能会导致数据库出现问题并在数据中造成差异”,因此,我要大胆地说出真正导致数据差异的原因是将生成的/计算得出的值存储在D B。

但这实际上是比这糟得多,因为它甚至不应该[〜#〜]可能[〜#〜]进行排序,以导致后端数据不一致。排序是作为select语句的一部分完成的,select语句通常是只读的。无论您如何对搜索结果进行排序,从中获得结果的表都不会改变。

10
industry7

看来,如果删除排序功能,用户将很难在执行活动中找到问题。这听起来像是一项重要的操作,即使不是主要的操作,因此您应该支持排序。

我认为,性能提升不会像它将给用户带来的困难那样大。他们最好缓慢加载0.1,但能够快速找出效果欠佳的广告系列。

同样,可以通过各种不直接影响可用性的方式来提高性能。但这是另一个领域。

4
Kristiyan Lukanov

对我而言,决定终止或重新设计现有功能时的关键问题很简单:可用性的净收益是多少?一般的经验法则是,如果您看不到至少20%的收益(无论对您的网域而言很重要的指标),您可能都不应该这样做。 20%的数字并不重要,重要的是您要考虑应用程序可用的意义,根据此定义衡量当前用户的表现,然后衡量建议的变更的影响并确定收益是否合理。更改。

听起来像是您所做的更改,从开发人员那里获得的收益比从用户那里获得的收益更大。作为UX专业人士,我会竭尽全力反对。即使只有5%的用户正在使用该排序,也肯定不会使您的应用对其他用户的可用性降低。但是您可以打赌,这5%的可用性将造成直接后果(愤怒的社交媒体和应用程序评论,可能的客户/收入损失,增加的支持成本等),并因此严重损害其可用性?

界面的任务是解决用户问题,而不是使开发人员的工作更轻松。

4
Andy Rice

保持界面不变,但要求开发人员将排序过程移至客户端。

这将减轻数据库的负担,对于不进行排序的人,该应用程序将快速运行。

2
Robyn

在考虑删除功能(需要花费大量资源)之前,请考虑以下事项:

  • 谁使用它?取决于应用程序的排序,可能是仅高级用户使用的功能,而将高级用户从该功能中删除是一个不好的举动。根据我的经验(我很确定这也适用于许多其他开发人员),高级用户是为您提供有关您产品最有建设性的反馈的人。高级用户是持久的用户。他们不仅签出您的应用程序,然后移至下一个。这些是您希望用户群泛滥的客户。如果用户对您的应用程序不满意,那么他成为高级用户的机会就会消失。

  • 这是一个无意间隐藏的功能吗?也许您的应用程序UI的当前使用设计并没有真正向用户显示排序甚至是可能的,所以大多数用户并不真正了解它,因此不使用它。在这个方向上做一些事情可能会产生积极的结果,或者至少给您更具体的评估此功能的使用情况。如果您的应用程序具有某种形式的教程,或者至少具有关于什么内容的有用信息的覆盖,请尝试将有关排序的信息添加到可见的某个位置(如果已经存在,则更多)。我经常感到惊讶的是,有多少用户错过了明显的事情(对我而言)。良好的用户互动始于以最快,最无缝的方式教用户如何使用您的产品。有时找不到某个功能实际上可能导致用户抛弃您的应用程序并走向竞争对手。

至于开发方面(因为我本人是软件工程师):

由于实际上只有不到5%的用户正在使用此数据进行排序,因此更新数据所需的调用数量使在postgresql中获取数据时出现问题。

如果很少使用某些东西,但又会产生经常性的开销,则您的呼叫工作方式有问题。如果您的用户中有5%使用该功能,而仅在这5%中使用该功能,则将产生开销。

不会像现在这样永远扩展

此处有多个选项:对子集进行排序,然后合并结果(->合并排序排序),创建预先排序的视图(如果数据不变,那么您经常可以为用户提供一个非常快速的排序列表,因为您拥有已经在服务器上完成此操作),对可以排序的数据量设置上限(例如,如果您发现在1000个条目之后进行排序会产生过多的开销限制,则只能排序到1000个条目->允许用户仅对选定的子集进行排序也是一种选择)等。

即时的。喜欢,真的是实时的。每次刷新页面时,您都会看到最新的效果(而不是2分钟后)

我认为我们对实时是有不同的理解。如果您确实具有数据的实时视图(用户可以通过网页查看),则意味着必须以非常少的延迟来不断更新页面。在这种情况下,排序将是您最少的问题(每个人都喜欢使用移动应用程序,该应用程序会很快耗尽可用(且昂贵!)的带宽...)。同样,您在此处描述的内容看起来更像是架构的实施问题或一般设计问题(此处主要是后端),然后是与排序功能有关的问题。

不仅对于列表,而且对于整个产品都有更好的性能。在某些应用程序中减少“冻结”

请参阅上面的先前报价。

成本优化,因为我们不需要每2分钟进行一次计算,尽管没人会真正看到数据(在夜间或其他任何时候)。我们只会在必要时进行计算

这完全取决于应用程序及其处理的场景。由于我们对此一无所知,因此无法给您任何反馈。

让我感到奇怪的是,您提到您的列表甚至可以达到100个项目。让我告诉你一些东西-即使对于一个应用程序,列表中的100个项目也不多。我要说的是,如果对100个项目的列表进行排序,您的开发人员将无法正常工作(我想每个项目都不包含兆字节的数据,但是如果这样,那么即使在移动应用程序中,这些数据也能做什么?!)带来了很大的问题。我不知道您所使用的技术(JS + HTML,Qt,Java等),但是有许多现成的列表组件已针对处理大量项目进行了优化。也许您的开发人员为该工作选择了错误的工具?

2
rbaleksandar

第一,排序是用户理所当然的一项功能。因此,没有用户会告诉您该排序功能有多出色-他们will告诉您,如果该功能消失了,您将非常不高兴。

第二,如果开发人员声称删除某些功能将使应用程序更高效,我将非常非常小心。 (而且我在Apple的应用商店上有一个应用程序,它没有问题,而在iPhone 4上以各种方式对大约10,000个项目进行了排序,这比现代设备慢了大约十倍。他们的申请下)。

1
gnasher729

已经有了很好的答案,但是我忍不住要加两分钱。

问题在于使用功能的用户百分比不是功能重要性或价值的准确度量。

这个问题对于软件开发来说并不是新问题。我认为每个企业都会在某种程度上面临此类决策。例如,在以前的职业中,我经营一家自行车店。为了能够用奇怪的自行车和设备为客户提供支持,我经常不得不购买工具和设备,而这些工具和设备可能永远不会产生足够的收入来支付自己的费用。因此,可以说有一种昂贵的工具可能永远无法收回成本,至少在第一个排列中,投资回报率是可怕的。我应该买吗?

答案是“取决于”。在自行车店里,我面临的问题是,如果我不支持足够广泛的客户群,他们会去其他设施更好的地方,一旦他们与另一家自行车店有关系,他们很可能会去那里。即使是简单,高投资回报的东西。如果您始终可以解决客户问题,那么他们很可能会先找您。他们也更有可能将您推荐给朋友。

在确定软件功能的投资回报率时,也会有类似的想法。

  • 当潜在用户评估您的工具时,他们可能会比较功能列表,即使他们从未使用过某个特定功能,如果知道他们是否需要它,也可能会感到宽慰。
  • 假设一家公司正在评估您的工具的使用情况。他们有99%的用户不需要功能X,但只有一个人需要,所以没有它就无法生存。他们将选择提供功能X的工具,尽管有多少用户使用X的统计数据似乎表明这是一项不重要的功能。

很容易提出其他示例,说明使用功能的用户所占百分比不足以做出这样的决定。而是问问自己您的功能对用户和您的业务模型有多重要?这是一个很难回答的问题,可能需要对您的域和用户有一些了解。

1
Spacemoose

不,您应该注意删除此内容。由于排序是一项重要功能,因此您将来可以在更精细的搜索条件下使用它。代替删除它,而使其更加详细,可能用户未获得所需的过滤条件。

1
Jasmin Javia

我不认为它应该像不应该那样简单。性能问题是感知的还是实际的?您是否看到搜索字词的网页加载时间过长,从而产生了大量结果?如果存在一个特定的跳闸点,其中X结果将加载和排序增加X ms,则可能会减少返回到页面的结果数量。

其次,还有其他选择。开发人员应用全部或全部修复程序并不少见,因为他们不会将用户视为页面是否按预期运行的主要指标。

如果如第一段所述存在问题,是否可以通过改进数据加载或将数据保存在缓存中的方式来获得效率?可以提高数据连接的效率吗?

到目前为止,您会注意到一个模式,除非系统中存在特定的缺陷,否则我尚未建议影响用户。

如果加载时间存在问题,并且后端无法改善加载时间,您是否可以允许用户根据自己的喜好禁用排序功能,以减少加载时间和降低性能,因此还可以告知他们可以转向随时重新整理?

1
DarrylGodden

我从您的陈述中得出的主要结论是,排序不够直观,所有人都无法使用。搜索缓慢且耗时,尤其是在等待结果时。我的建议不是删除排序,而是将其进一步发展为用户乐于参与的系统和样式,一个明确的目标是针对过滤器/排序功能改进热图。 。

0
Gray Roberts

问题:我一直在研究这个问题,基本上后端性能没有赶上要求的功能。管理层要求使用诸如排序之类的功能,开发团队中的某人说“确保易于添加”,甚至可能没有基准标记真实世界的数据。一个测试服务器在后端可以有1000行测试数据,但是实时用户可能有数百万个,现在,当有人一天几次单击该按钮进行排序时,您的开发人员可能会害怕看到他们的服务器开始着火。

解决方案:首先,您是看到还是收到实际的性能投诉,还是开发人员只是在展望未来并大喊大叫?如果产品当前或即将陷入混乱,则一定要删除排序并与进行排序的用户交谈,并与开发人员交谈,直到找到解决方案为止。如果有几个月或几年的时间直到这种排序导致严重的产品损害,那么最好的办法就是让开发人员对其进行修复,添加索引,找到另一种类型的数据库来提供帮助。我去过那里,我们让用户等待30秒进行排序已经有几年了,但是最终我们将数据克隆到新的数据库类型“ elasticsearch”中,从而为快速,即时搜索/排序/计数打开了世界。

0
rezand

有很多好的答案。

如果没有足够的方法可以采取不同的方法:

重命名当前版本。代替当前版本,放置一个没有排序的版本,但是它具有一个“启用排序”按钮。如果他们单击以转到旧的昂贵版本,否则,他们将使用新的廉价版本。

0
Loren Pechtel

我同意您不应该删除该功能。我之前已经看到过,有些经理删除了某个功能,因为他认为没有人使用它。用户开始抱怨...所以该功能又回来了,但是由于一些新的错误,因为编码器更改了其他功能而忽略了这些“没人使用”功能。

0
user3719694

热图非常有限。我一直都在随机点击内容,有一半时间效果不佳。最好查看功能用法按用户。也就是说:我们的哪个用户使用了排序?还有一个更好的研究是why他们是否使用了排序?

在亚马逊上进行排序。这是垃圾箱大火。人们搜索,并且搜索结果全是谷壳,因此他们尝试sort将小麦与谷壳分开。 而且永远都行不通,因为糠皮太多了!这就是亚马逊应该认真考虑的事情。过滤,分层排序等。

因此,更好的问题是当人们进行排序时,他们真正追求的是什么?而我们该如何更好地交付that?

我完全同意,您不应该在数据库端进行操作。数据库引擎是宝贵的资源。程序员不应仅仅因为更容易编写代码就不会在数据库上投入繁重的工作。

更好的是,直接在用户的PC /设备上按请求进行排序。这样可以节省网络交易时间-一个经典的设计错误是要在办公室的千兆以太网上进行测试,而用户的iPad 2G只能以11%的丢包率在Edge蜂窝网络上使用。因此,网络活动对可用性至关重要。如果您回拨使用情况报告,请使其成为后台操作而不是关键路径。

0