第2403篇:AI产品的UX设计原则——工程师需要懂的用户体验思考
第2403篇:AI产品的UX设计原则——工程师需要懂的用户体验思考
适读人群:参与AI产品开发、需要理解用户体验设计的工程师 | 阅读时长:约12分钟 | 核心价值:掌握AI产品UX设计的核心原则,避免「技术上成功、体验上失败」的AI功能
我们团队有一段时间特别骄傲:AI摘要功能在技术测试上准确率89%,延迟P95在1.8秒,各项指标都很好。
然后上线了。
两周后,产品经理过来说:「用户反馈功能没什么用,DAU只有0.8%。」
我去看了用户的使用录像——这是我们做用户测试时录的。
看完之后,我沉默了很久。
用户的问题不是AI不准,也不是速度慢。问题是:用户根本不知道这个功能在做什么,也不知道什么时候应该用它。
AI在默默「处理中」,没有任何进度提示;摘要出来了,但和原文放在一起,用户不确定哪个是AI生成的哪个是原始内容;遇到AI不确定的内容,系统直接给出了答案,但没有告诉用户「这个可能不准确」。
技术做得很好,体验做得很差。这是AI产品最常见的失败模式之一。
AI产品UX的特殊性
传统UX设计有成熟的原则:可发现性、反馈及时性、防止错误等。
AI产品需要在这些基础上处理几个特殊问题:
问题一:AI的不确定性如何传达 AI不是100%准确的,用户需要知道什么时候该信任AI,什么时候要自己核实。
问题二:AI的处理过程如何可视化 AI的「思考」是不可见的,用户不知道AI在干什么、还要等多久。
问题三:AI失败时如何优雅降级 当AI给出错误或低质量答案时,如何让用户感知到并有路径修正。
问题四:如何设计合适的控制感 用户需要感觉到自己在控制系统,而不是被AI控制。
AI产品的8条UX设计原则
原则1:明确告知用户「这是AI生成的」
用户需要知道他们看到的内容是人工写的还是AI生成的,这是信任的基础。
好的做法:
- 在AI生成内容旁边加上明确标记(「AI生成」「由AI摘要」)
- 用视觉区分(不同背景色、左边框、特殊图标)把AI内容和非AI内容区分开
- 在功能入口处清楚说明「此功能由AI驱动」
常见错误:
- AI生成的内容和人工内容混在一起,用户分不清
- 只在隐私政策里提到使用了AI,用户不会读
原则2:展示处理进度,不要让用户面对黑盒
AI处理时间通常比普通接口长(1-10秒),必须给用户清晰的进度反馈。
分级反馈策略:
- 0-1秒:显示「思考中...」或简单的加载动画
- 1-3秒:流式输出(逐字显示,让用户感觉AI在实时生成)
- 3-10秒:显示具体的处理步骤(「正在搜索相关资料...」「正在整理答案...」)
- 10秒以上:必须重新考虑架构,或者提供后台处理+通知的机制
流式输出是AI产品体验提升的最大单点改进:
@GetMapping(value = "/api/v1/ai/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<ServerSentEvent<String>> streamResponse(
@RequestParam String sessionId,
@RequestParam String userInput) {
return Flux.create(sink -> {
// 发送处理开始状态
sink.next(ServerSentEvent.<String>builder()
.event("status")
.data("{\"status\":\"processing\",\"message\":\"正在思考中...\"}")
.build());
// 流式获取AI回答
chatClient.prompt()
.user(userInput)
.stream()
.chatResponse()
.subscribe(
response -> {
String token = response.getResult().getOutput().getContent();
sink.next(ServerSentEvent.<String>builder()
.event("token")
.data(token)
.build());
},
error -> {
sink.next(ServerSentEvent.<String>builder()
.event("error")
.data("{\"error\":\"生成失败,请重试\"}")
.build());
sink.complete();
},
() -> {
sink.next(ServerSentEvent.<String>builder()
.event("done")
.data("{\"status\":\"completed\"}")
.build());
sink.complete();
}
);
});
}原则3:传达置信度,而不是假装100%确定
AI有时候是在「猜」,用户需要知道AI的确定程度。
置信度传达的方式:
高置信度的回答:正常展示,不加额外说明 中置信度:「根据现有信息,可能是...,但建议核实」 低置信度:「我对这个问题不太确定,以下是我的理解,请以官方资料为准」 极低置信度:直接告诉用户「这个问题超出了我的能力范围,建议直接咨询专业人员」
@Service
public class ConfidenceAwareResponseService {
/**
* 根据置信度调整输出格式
*/
public FormattedResponse formatWithConfidence(String rawResponse, double confidence) {
return switch (classifyConfidence(confidence)) {
case HIGH -> new FormattedResponse(
rawResponse,
null, // 不加任何提示
ConfidenceLevel.HIGH
);
case MEDIUM -> new FormattedResponse(
rawResponse,
"以上内容基于AI分析,重要决策建议再次核实",
ConfidenceLevel.MEDIUM
);
case LOW -> new FormattedResponse(
"以下回答可能不够准确,请参考后自行判断:\n\n" + rawResponse,
"建议通过其他渠道验证此信息",
ConfidenceLevel.LOW
);
case UNKNOWN -> new FormattedResponse(
null,
"这个问题超出了我的知识范围,建议查阅专业资料",
ConfidenceLevel.UNKNOWN
);
};
}
private ConfidenceLevel classifyConfidence(double score) {
if (score >= 0.85) return ConfidenceLevel.HIGH;
if (score >= 0.60) return ConfidenceLevel.MEDIUM;
if (score >= 0.30) return ConfidenceLevel.LOW;
return ConfidenceLevel.UNKNOWN;
}
}原则4:让用户容易纠错
AI错了,用户应该能方便地纠错,而不是束手无策。
纠错机制设计:
- 提供「重新生成」按钮,但不要让它太显眼(避免用户觉得AI很不稳定)
- 支持用户编辑AI生成的内容(尤其是文档生成、邮件起草等场景)
- 提供「这个答案有问题」的反馈入口,并请用户说明哪里有问题
关键设计原则:纠错的代价要低。如果用户要纠正AI的错误需要很多步骤,他们会直接放弃,以后也不再用这个功能。
原则5:明确AI的能力边界
用户经常不知道什么问题能问AI,什么问题不能问。这会导致两种问题:
- 不去问AI本来能很好回答的问题(功能利用不足)
- 去问AI根本回答不了的问题(失望后不再使用)
设计建议:
- 在功能入口处列出「我能帮你做的事」(3-5个典型使用场景)
- 对超出范围的问题,明确说明「这个问题我不太擅长,你可以试试...」
- 提供示例问题让用户了解AI的能力范围
原则6:避免让AI成为必须路径
如果AI功能出问题,用户应该有替代路径完成任务,不能因为AI挂了用户就什么都做不了。
反模式:把AI做成强制流程的一部分,AI挂了整个功能就用不了。这对用户体验和系统可用性都是灾难。
原则7:尊重用户的控制感
AI的自动化能力越强,越容易让用户感觉失控。
设计建议:
- 让AI的操作是可预览的:在AI执行操作之前,先展示「AI将要做的事」,让用户确认
- 提供「撤销」功能:AI的任何操作都应该可以撤销
- 避免AI主动触发关键操作(发邮件、删除数据等),这类操作必须有用户确认
原则8:首次使用的引导
很多AI产品因为没有好的新手引导,导致用户第一次使用就遇到挫折,然后不再回来。
AI功能的新手引导要解决:
- 这个功能是做什么的?(30字以内说清楚)
- 第一步应该怎么开始?(一个具体的引导动作)
- 一个「哇,原来这么好用」的时刻(第一次成功体验要设计好)
工程师能做什么:把UX原则落地成代码
UX设计是工程师和设计师协作的结果,但工程师也可以主动推动这些原则:
- 在代码中实现置信度计算,为前端展示提供数据支持
- 实现流式输出,让前端能够逐字展示AI响应
- 设计完善的错误响应格式,包含用户友好的错误信息和建议操作
- 提供回滚/撤销接口,支持用户纠错
- 记录用户交互事件,为UX迭代提供数据依据
总结
AI产品的UX失败,通常不是因为AI不够好,而是因为设计没有考虑AI的特殊性:不确定性、处理时间、失败模式、控制感缺失。
8条原则:
- 明确标识AI生成内容
- 展示处理进度(流式输出)
- 传达置信度,不假装确定
- 提供容易的纠错路径
- 明确AI的能力边界
- 保留人工降级路径
- 保持用户控制感
- 设计有效的新手引导
工程师不需要成为UX设计师,但理解这8条原则,能让你在技术实现中做出支持好UX的架构决策。
