
什么是用例?
推出新产品时,设计初衷往往与用户实际使用方式存在差异。气泡膜发明者最初将其作为壁纸销售,却未预见其包装用途。这种用例思维是明确产品价值、锁定目标受众的关键。
用例描述了用户如何利用系统完成特定任务,在项目早期规划中极具价值。一个完整的用例包含四要素:
- 参与者:即用户。
- 产品:被使用的系统。
- 动作:正在发生的行为。
- 目标:期望达成的结果。
该概念由伊瓦尔·雅各布森于1987年提出,现已成为软件设计及统一建模语言(UML)的标准组件。如今,各行业均通过用例确定核心受众。例如开发智能咖啡机时,可定义如下用例:
- 参与者:忙碌的晨间通勤者。
- 产品:智能咖啡机。
- 动作:前夜通过App或机器预设定时,早6点自动冲泡。
- 目标:醒后即享热咖啡,节省早晨时间。
清晰的用例描述能为团队提供解决客户问题的具体工具。
软件开发中的用例逻辑
科技领域的用例记录了用户达成目标的步骤。由于操作路径非线性,单个用例通常涵盖三种场景:
- 基本流程(快乐路径):理想状态,用户无障碍实现目标。
- 替代流程:达成同一目标的其他路径,如点击不同按钮或使用快捷方式。
- 失败场景:产品故障或用户误操作时的应对机制。
以银行登录为例:
- 基本流程:输入正确账号密码,登录成功。
- 备选流程:使用指纹或面部ID免密登录。
- 异常流程:连续输错三次密码,系统锁定账户保障安全。
识别异常流程能让开发人员在发布前实施解决方案(如密码重置功能),规避潜在风险。
实体产品行业的用例应用
与软件不同,实体产品用例更侧重理解并连接目标受众,而非单纯定位错误。开发者通过用例识别产品解决的具体问题。例如,新冰箱的人体工学把手专为关节炎患者设计,经用户测试验证后,营销材料便可精准触达该群体。
📖阅读更多: 如何找到可销售的产品:17种经过验证的研究方法
什么是用例图?
用例图是基于UML的可视化表达,简明展示用户与系统的交互及系统功能,避开复杂技术细节。图表能为团队提供清晰度,帮助尽早识别缺失功能并就范围达成一致,从而提升项目成功率。数据显示,注重视觉沟通的企业在效率、品牌一致性上表现更优。
识读用例图需掌握以下符号:
- 参与者(Actors):代表人物或外部系统的火柴人图标。
- 用例(Use cases):标有具体目标的椭圆。
- 系统边界(System boundary):区分构建内容与外部的方框。
- 关联(Associations):连接参与者与目标的线条。
- 关系(Relationships):虚线表示目标间连接,«include»为必需步骤,«extend»为可选步骤。
图表如同布局地图,文本则是详细说明。两者结合可确保团队在开发前对职责分工达成共识。
用例 vs 用户故事 vs 测试用例
三者虽常并用,但目的各异:
用例
- 定义:结构化描述参与者与系统的交互以实现目标,侧重行为、范围和流程。
- 适用:复杂系统或受监管行业,确保团队对构建内容保持一致。
用户故事
- 定义:敏捷设计中简短的价值导向需求,格式为“作为[谁],我想要[什么],以便[为什么]”。
- 适用:迭代交付与客户价值优先场景,作为讨论基础而非完整说明书。
测试用例
- 定义:包含输入、步骤和预期结果的验证集,用于确认需求是否正常运作。
- 适用:质量保证(QA)和回归测试,证明产品符合相关要求。
建议将用户故事与用例草图配对阐明复杂交互,再据此创建测试用例,确保产品达标。
用例类型
业务用例
描绘宏观价值创造流程,聚焦业务成果与跨部门协作,不涉及具体软件。
💡示例:端到端订单追踪,涵盖下单、库存检查、履约及发货全过程,展示跨团队运营如何为客户创造价值。
系统用例
解释软件如何支持用户目标,定义系统边界内的输入、验证及错误处理。
💡示例:订单管理系统(OMS)中,用户输入详情,系统验证、查库、计价、保存记录并显示确认信息。
用例的核心价值
- 聚焦产品价值
- 优先关键功能
- 获取营销洞察
- 加强产品对齐
聚焦产品价值
用例详述产品如何助用户达成目标,虽不直接面向客户,却是独特价值主张和营销素材的依据。探索多元用例能发现意外价值与新受众。例如桌面迷你冰箱原用于饮料,后发现护肤品冷藏需求;软件领域也存在消费者“误用”带来的新场景。
优先处理关键功能
了解用户使用方式有助于识别核心优势,集中资源进行项目规划与预算编制。关键益处也是测试用例的基础。若核心卖点是速度,应优先开发一键结账,并通过测试验证用户能否在5秒内免填信息完成购买。
获取营销洞察
产品营销依赖用例向不同受众传递价值。定制化的语言和场景描述能让受众产生共鸣,使其更易将产品视为解决方案。
加强产品对齐
用例是团队的指南针。提前定义目标与限制可防止范围蔓延,指导设计师基于真实需求构建体验。共享具体计划能避免交接混乱,确保解决方案精准匹配问题。
如何编写产品用例
- 选择用户
- 描述用户目标
- 展示产品助力路径
- 确定关键要点
- 重复迭代
零售领域的用例通常描述假设客户与产品的互动及获益。以下模板可作为撰写框架:
1. 选择用户
回答“产品面向谁”,为目标受众中的假设用户撰写简要描述。用户(参与者)可以是员工、客户或与产品互动的软件系统。例如,可折叠自行车头盔的参与者可能是骑共享单车前往联合办公空间的都市职场人士。
2. 描述用户目标
从用户视角出发,结合反馈或调研捕捉其真实痛点,而非主观臆测。对于通勤骑行者,痛点在于头盔笨重难收纳。他们既求安全,又需在下班社交时保持便利。前置条件可能包括:
- 用户已到达目的地
- 头盔处于完全展开并锁定状态
3. 展示产品助力路径
详述用户解决问题的步骤。先从基本流程(理想场景)开始:
- 抵达联合办公空间
- 折叠头盔
- 滑入背包
接着考虑替代流程。若背包已满无法放入怎么办?梳理此类路径能凸显改进点。例如,提前识别此场景后,可增加登山扣夹以便外挂。
4. 确定关键要点
用例不仅服务于功能开发,还能支持营销。例如,通勤骑行者用例的关键点是“易收纳”与“切换便捷”。这些卖点可直接转化为社交媒体视频广告素材,向潜在客户直观展示。
📖阅读更多:广告类型:推广产品的14种方式
5. 重复迭代
针对每个目标受众重复上述过程,并将所有用例汇编成单一文档供推广参考。
产品用例实战示例
护肤品牌Topicals的唇膏Slick Salve便运用了多场景策略。据产品营销主管Roxana Ontiveros介绍,该产品不仅针对干燥人群,也适用于服用异维A酸(Accutane)的患者,以及追求光泽妆效的美容用户。“Slick”传达美容吸引力,“Salve”强调治愈特性,在保持故事具体的同时最大化触达受众。
以医疗需求用户为例,用例框架如下:
- 角色:使用强效痤疮药物(异维A酸)的客户。
- 目标:防止疼痛性开裂,舒缓极度干燥。
- 前提条件:嘴唇因药物副作用出现干燥、紧绷或脱皮。
基本流程:
- 用户感到刺激或紧绷。
- 涂抹厚层润唇膏。
- 配方锁住水分。
后置条件:
- 用户获得即时缓解,并形成保护屏障。
常见问题解答(FAQ)
场景和用例有什么区别?
软件开发中,场景是用例的单个实例,描述一次具体交互;用例文档则由多个场景组成。实体产品开发中,两者常通用。
用例的目标是什么?
概述未来用户如何使用产品实现目标或解决问题,辅助确定开发策略与营销受众。
用例和案例研究有什么区别?
案例研究是面向客户的宣传文档,讲述真实故事;用例是内部文档,描述假设用户及其目标。
用例图用于什么?
可视化展示系统使用者及其意图,帮助团队识别缺失功能并在构建前达成共识。
商业中的用例是什么?
描述高层级业务流程,侧重跨团队协作以实现公司目标(如订单履约)。

