电子商务产品查找者应该问多少问题?

计算改变决定的问题,而不是屏幕

当每个问题都使用不熟悉的语言时,一个简短的发现者仍然会感到困难. 如果每个答案都简单、明确相关且明显地将客户推向结果,那么较长的发现者会感到直截了当。 因此,有益的衡量标准不是屏幕总数,而是每个买方需要合理努力的数量.

对于每一个拟议问题,写下每一个可能的答案变化. 如果没有答案去除不合适的产品,改变有效产品的顺序,改变显示的证据或触发支持路径,问题可能不属于查找者. 以后作为结果页的首选可能有用.

保持不同的客户路径分离. 买方知道确切的制造商参考材料,不应被迫与只知道该申请的人走同一路。 两者都可以达到相同的目录,但他们需要不同的问题.

在第一个问题之前写入停止规则

没有停止规则的发现者倾向于收集信息,因为它是可获得的,而不是因为它能改进决定. 界定成功结果必须包含哪些内容:一套有效的产品、确认的要求、使用的证据、各种变体之间的任何区别以及客户仍然需要检查的条件.

发现者可以用一种产品,几种有效的替代品或人交接来阻止. 单一的结果并不自动更好:当两种产品仍然有效时,它可能会产生虚假的确定性。 短名单并不自动安全:它可能只是将尚未解决的技术决定转回给客户.

• 当确认的事实支持这种匹配时,停止使用产品.
• 当每个项目都有效,剩下的差异是偏好时,请先列个短名单.
• 当所需事实不明、冲突或未列入核准的目录时停止支持.
• 如果确认的要求排除了所有可用的产品,则无果而止.

先问最高值的简单问题

第一个问题通常应该是客户可能知道并且有意义地将目录分开的问题。 产品类型,应用,机器制造,预期用途或已知的参考,可以是强烈的开口问题. 需要工具或手册的模糊度量很少是值得欢迎的第一步,除非每个有效决定都取决于它.

通过对照真正的目录记录进行测试来估计一个问题的价值。 它是否清除了许多不合适的产品? 这能防止严重不匹配吗? 顾客能可靠回答吗? 如果买家猜到答案,造成平分的问题不一定有价值.

解释为什么在要求之前需要一个陌生的事实. 如果客户必须测量直径,显示测量地点,指定单位并表明一个大约值是否可以接受。 良好的指导既会减少被抛弃,也会减少自信但错误的答案.

单独的资格、排名和列报

资格问题可以决定是否包括某一产品。 排名问题订购已经有效的产品 。 演示文稿选择会改变显示结果的方式,而不改变基本匹配. 混合这些角色可以让偏好凌驾于相容规则之上.

例如,工作压力或经核准的申请关系可能是一个资格条件,而品牌偏好,交付速度或颜色可能排列出有效的选项. 价格可以帮助客户比较合适的产品,但降低价格绝不能使不合适的产品看起来可以接受.

• 硬性要求:不包括无法满足确认需要的产品.
• 优惠:重新订购仍然有效的产品.
• 显示选择:更改选取的查看或比较方式.
• 未核实输入:在经过审查之前无法安全确认或排除产品.

使用分店,所以客户只看到相关问题

一个好发现者是决策树,而不是固定的问卷. 选择已知模型的客户可能不需要输入维度. 客户选择具有若干未解决变式的申请可能需要一个后续问题。 分会使路径与决定相称.

将每个分支写成一条明确的规则并测试数据缺失时会发生什么. 不要推断后一种偏好需要的答案。 在客户返回时保留更早的答案,但在一个答案改变时重新计算每个依赖的结果.

避免在路由可以分出时承诺固定数级步骤的进度指标. 使用诸如“少数细节”之类的措辞,或在已知的章节中显示进展情况。 不应告诉客户,他们处于第五步中的第四步,然后收到出乎意料的三次后续.

把“我不知道”当作一个设计好的答案

客户往往缺乏目录使用的确切信息。 删除未知选项会鼓励猜测,这比放弃更糟糕. 预先决定一个未知的答案是否可以通过另一个问题、一个说明的衡量、一个参考物查询或人类支持来解决.

未知不得无声地表示“所有产品”。 如果缺失的事实控制了资格,请说明尚不能提出安全建议。 显示什么证据可以解决它,并保存已经提供的答案,因此当支持响应时客户不需要重新开始.

保持每个步骤清晰, 仅分组相关细节

GOV.UK Design System提出问题页面,作为让用户关注某项决定的一种方式,并称用户研究应当确定何时相关问题可以共享一页. 对于一个产品查找者来说,这是一个有用的起点:当答案改变下一个分支时,每步一个明确的问题就很有效,而紧密相联的维度可能更容易一起输入.

使用问题本身作为主标题,提供可见后行并保持帮助接近它所解释的控制. 在更小的屏幕上,避免细小选择的长网格. 大型控制器,短标签和单一明显的连续动作使得路由更容易被扫描和纠正.

与真正的客户进行测试分组,而不是假设页数会减少,这意味着工作会减少。 在一个贴有标签的图表上进行三项测量可能比较简单;在看到有效的短名单后,三项无关的商业偏好可能比较容易.

提供说明和标签

W3C的"网络无障碍倡议"建议确定所需和可选的投入,预期格式和其他相关指示. 它还警告说,占位符文本不是取而代之的标签,因为它消失,并且没有被辅助技术作为标签一贯地对待.

给每个控制者一个持久的标签。 关联帮助和错误消息与相关输入,支持键盘操作,保留可见焦点,不只依赖色彩. 如果图表对计量作出解释,请提供等同的文字解释。 用缩放,键盘导航和一个屏幕读取器测试完整的行程.

无障碍测试属于接受标准。 一个在技术上返回正确产品但阻止一些客户回答问题的发现者是不能正确运作的.

根据核准的目录事实提供所有答复

问题逻辑和产品数据必须使用相同的定义. 常态化单位,属性名称,选项值和相容性关系后再依赖它们. 保持客户化措辞与存储值相分离,这样更清晰的标签不会改变规则.

通过匹配和交接,携带稳定的产品和变异标识. 永远不要使用可编辑标题作为推荐项目的身份. 当某些产品缺少所需的字段时,发送这些记录,以有记录的理由审查或排除这些记录;不要发明一个值来保持发现者移动.

M.I.A.I 产品查找器旨在指导买家从要求到相关的、可解释的短名单。 这一解释应指明影响结果的经证实的事实,并将其与偏好或未经核实的信息区分开来.

将引导问题连接到 Shopify 过滤器和变体

Shopify's Search & Discovery的指南解释道,存储前置过滤器可以基于产品选项,元场,分类元场和变体元场. 被引导的查找者可以就相同的被核准属性向客户提出方便的问题,然后将客户交给正确的活出产品或变体,而不是创建目录被断开的拷贝.

也shopify 将不同过滤器的值通常作为AND条件组合在一起的文档,而同一过滤器内的多个值通常使用OR逻辑. 将这种行为刻意地转化为发现者。 “红色和大小8”与“红色或绿色”不同,隐藏的逻辑错误可以产生一个可信但错误的短名单.

只询问授权存储数据能够一致支持的属性 。 通过现场Shopify集成,保持价格、可用性和产品页详细信息流畅,同时根据其核定来源处理兼容性或要求规则.

防止死胡同并让答案可逆

每条路线都需要一个有用的结果,包括没有结果. 显示哪些确认要求删除了最终产品,让客户改变答案而不失去剩下的行程. 在验证错误或回放动作后, 不要将查找器重置为起始 .

在显示结果之前,考虑对错误代价高昂的决定作一个简短的回答摘要。 让客户编辑任何值并重新计算短名单. 在结果页上,重复重要要求,以便客户能够认识到建议是否反映了其含义.

支助路线应载有结构化的答案和候选人记录。 发送通用的“请与我们联系”信息,不附带任何内容,浪费客户的工作,为支助小组重新提出同样的重复问题.

一个具体的例子:选择工业水管

想象一下一家商店在水、空气、石油和化学应用中销售工业用软管。 向每位访客询问材料、内部直径、长度、工作压力、爆破压力、温度、连接和监管要求,将形成一种很长的固定形式。 有些答案对于许多路线来说是不必要的,而另一些则是关键的.

发现者从转移物质开始,因为这决定了哪些经批准的材料相容性记录可以保留. 然后要求工作压力和内部直径。 温度仅在选定应用程序有多个有效物质范围时出现. 当它们识别一个可购买的变体而不是后期配置时,会询问连接和长度.

如果客户选择一种没有经批准的相容性记录的化学品,发现者会停下来并请求专家审查,而不是通过受欢迎程度来排名软管. 如果三根软管仍然有效,结果页将解释其压力、温度和连接差异,并允许价格或交货优先。 最短的路线使用三个答案;另一个路线使用五个答案. 两者都是正确的,因为每个问题都会改变决定.

衡量每个问题是否占据其位置

逐个分支审查旅程,不仅作为整体完成率。 记录顾客离开的地方,选择“我不知道”,更改早先的答案,没有结果,请求帮助并选择产品。 将证据连接起来,支持提问,更正订单,并确认企业可以合法这样做的错误产品回报.

高出站率并不能证明这个问题应当被去除. 它可能显示语言不明确、没有资料、目录空白或确实不相容。 观察客户会话或进行可用性测试,在改变硬要求之前了解原因.

退休问题不会改变结果。 当客户可以更可靠地更早地回答时,重新排列问题. 当同一个未知的球场阻断了多趟出行时,改进目录. 发现者应该变得更短或更清晰,因为证据支持变化,而不是因为强加了目标屏幕计数.

在发射前测试每个分支

建立真实客户案例和核准产品记录的测试矩阵. 包含每个开通路由,每个硬排除,多个有效结果,缺失数据,未知答案,回向导航,改变答案,没有结果和支持交接. 确认最终链接打开正确的活产品或变体.

在移动和桌面上进行测试,使用键盘导航和辅助技术. 如果商店是多语言的, 请检查所翻译的标签和值 。 当产品数据、匹配规则或Shopify选项和元场结构发生变化时,重复测试.

1. 列出寻找者必须支持的客户决定.
2. 将每个问题都映射到规则上或排序改变它的控制.
3. 界定停止、无结果和人文审查的结果.
4. 构建代表性分支和数据质量测试案例.
5. 与真实用户进行可用性和无障碍性检查.
6. 监测证据并去除无法改进决定的问题.