场景化设计培训
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
基于场景的设计（Scenario-Based Design，SBD）作为可以满足有效地管理客户 需求，并且更容易地在客户环境中集成产品的关键学科出现。它的主要目标是推动 技术集成。虽然此方法是好的开端，但其还不完全。为了避免创建与现有的客户角 色和过程不一致的解决方案，SBD 必须对用户、它们所做的事情，以及他们所处 的环境更加重视
概念设计：第七步
系统用例以两种不同方式得以实现 传统用例图：类图和交互图 用例情节串联板 这种 图表示了窗口中的静态与动态关系。每种关系如下： • 静态关系是一个screen由一些compartments组成 • 动态联系是由用户行为决定的两个screen间的导航
概念设计：第八步
可视化设计实际的图形界面
”
“我不知道为什么要开发这个功能，不过
我还是按照文档完成了。
”
“团队里的每个人对于一个项目该做什
么，先做什么，为谁而做……都有不
同的想法。
”
“我们可以做的功能太多了，到底如何取
舍呢？
”
“客户的需求不断变化，我们很多工作都
白做了。
”
“这个版本我们增加了许多新的功能，但
用户反响并不理想。
”
什么是USBD
• 讲述一个故事 • 包含用户情感和环境因素 • 揭示用户真正的需求 • 不谈解决方案 • 作为设计的基石和标杆，帮助团队沟通和交流。
SBD 好处
• 允许您将业务环境及其目标看作是管理软件设计所遵从的约束条件的关键决定 因素
• 为以下方面提供可能性： • 确定业务目标是否得到正确的支持 • 确定哪个领域需要更多投资 • 发现冲突的目标 • 验证用户执行的任务如何支持业务需求 • 设计符合用户需求和目标的用户接口
理解客户：第四步
操作者功能的系统用例的实现
理解客户：第五步
创建业务建模及系统建模工件之间的追溯。此处的最佳实践，通过序列图中的引 用方法把将要自动化的业务操作者所提供的每个方法关联到系统分析模型中相应 的系统用例实现。这大大地增强了模型可导航性。此外，发起那些方法的业务操 作者将追溯到相应的位于系统用例模型中的系统参与者（用户角色）
场景化设计培训
杨朝令
用例驱动的设计问题
• 业务和应用程序层之间存在着鸿沟 • 抽象层之间缺乏可追溯性 • 用户体验的质量通常很低 • 仅仅使用用例驱动的 UML 规范对系统进行建模不会提供良好的业务反应性级别
想用
享受且渴望
可用
简单、易学、高效
有用
能解决问题
ቤተ መጻሕፍቲ ባይዱ
“我根本不知道谁在用我们的产品，也不
知道用户对我们的产品评价如何。
头脑风暴，集思广益
自由畅谈 延迟评判 禁止批评 追求数量
选择影院和电影 付款
选座位 取票
视觉化用户场景
三大步 8小步
理解客户 理解用户
概念设计
理解客户：第一步
在业务模型中确定并获取了五个主要的元素： 业务流程图（Business Process Maps） 业务流程（Business Processes） 业务参与者（Business Actors） 客涉众（Customer Stakeholders） 业务目标（Business Goals）
USBD 是被提议的覆盖软件开发端到端范围的统一的设计方法。目标是能够设计出 覆盖所有或部分被建模的业务过程的产品，以及帮助预期的用户利用最可能的经验 实现所确定的目标。USBD 所描述的开发的另一方面是如何通过简洁，而完全的形 式化文档集支持生产者和消费者之间的沟通渠道。
场景是什么？
一个用户场景就是一个描述某个用户在某个环境中 完成某个任务的故事。
理解客户：第二步
完成业务模型 用例图显示所有已确定的业务用例 追溯客户涉众、他们设定的业务目标，及支持那些目标的业务用例之间关系
理解客户：第三步
开发业务分析模型
业务用例参与者 — 包括业务操作者和业务参与者 — 以及他们的关系的静态 视图 序列图（每一个表示不同的业务用例场景或子流程）表示存在于业务操作者 之间，用以实现业务用例的交互
Outside-In Design（OID）方法和过程代表了以用户为中心的设计（UserCentered Design）和 用户工程（User Engineering）最后的演进步骤。主要的 焦点在于产品线所处于，或计划处于的业务环境。更确切地说，OID 的目标是定 义此类产品的用户，以更好地设计他们的交互体验。这使得 OID 在用户接口设计 领域中非常有效。如果在 OID 方法中寻找弱点，那么其弱点是缺少业务环境、系 统环境，和用户接口之间的正式连接
理解用户：第六步
创建角色，这是用户原型，封装了通过与许多具体的当前或潜在的产品用户进行 面谈而收集的所有知识 针对每个被确定为需要一个产品的具体接口的用户，来创建不同的角色来详述典 型的用户目标、任务和技能
每个角色显示为拥有一组 skill 原型技能属性的类。每个角色都与它覆盖的所有用户（用户角色）相关联，并且由主 要角色（primary persona）、次要角色（secondary persona）, 补充角色（supplemental persona）、负面角色 （negative persona），等等的原型进行标记。建立连接并验证角色和分析阶段中确定的（或者可能是反向工程）实 际系统参与者之间的关系是有用的
就令软件产品快速地响应业务中的变更的能力而言，从业务过程元素到系统元 素的正式追踪为您提供更大的灵活性。您可以使用为系统建模的同样形式来为 业务过程和目标建模，通过利用这样的事实，您现在可以获得整个端到端的视 图的单一的描述，从业务需求到软件产品。 • 通过正式的、基于 UML 的用户和用户接口建模，在参与软件开发生命周期的不 同团队之间创建明确的文档及通信 • 为您提供将用户接口和系统模型链接起来的能力，使您更容易地找到错误。这 使您可以将所有设计软件系统的最佳实践应用到用户接口的设计中来。
• 产品是有场景的 目标完成业务流程完成业务的人完成任务
• 一个场景是由多个情节组成的，将情节串联起来就是情节板 人情节GUI（元素）GUI导航
• 场景并不都只有happy story 基本流备选流 • 始终不要忘记你的目标是什么？客户的目标是什么？
概念设计：第七步
系统用例以两种不同方式得以实现 传统用例图：类图和交互图 用例情节串联板 这种 图表示了窗口中的静态与动态关系。每种关系如下： • 静态关系是一个screen由一些compartments组成 • 动态联系是由用户行为决定的两个screen间的导航
概念设计：第八步
可视化设计实际的图形界面
”
“我不知道为什么要开发这个功能，不过
我还是按照文档完成了。
”
“团队里的每个人对于一个项目该做什
么，先做什么，为谁而做……都有不
同的想法。
”
“我们可以做的功能太多了，到底如何取
舍呢？
”
“客户的需求不断变化，我们很多工作都
白做了。
”
“这个版本我们增加了许多新的功能，但
用户反响并不理想。
”
什么是USBD
• 讲述一个故事 • 包含用户情感和环境因素 • 揭示用户真正的需求 • 不谈解决方案 • 作为设计的基石和标杆，帮助团队沟通和交流。
SBD 好处
• 允许您将业务环境及其目标看作是管理软件设计所遵从的约束条件的关键决定 因素
• 为以下方面提供可能性： • 确定业务目标是否得到正确的支持 • 确定哪个领域需要更多投资 • 发现冲突的目标 • 验证用户执行的任务如何支持业务需求 • 设计符合用户需求和目标的用户接口
理解客户：第四步
操作者功能的系统用例的实现
理解客户：第五步
创建业务建模及系统建模工件之间的追溯。此处的最佳实践，通过序列图中的引 用方法把将要自动化的业务操作者所提供的每个方法关联到系统分析模型中相应 的系统用例实现。这大大地增强了模型可导航性。此外，发起那些方法的业务操 作者将追溯到相应的位于系统用例模型中的系统参与者（用户角色）
场景化设计培训
杨朝令
用例驱动的设计问题
• 业务和应用程序层之间存在着鸿沟 • 抽象层之间缺乏可追溯性 • 用户体验的质量通常很低 • 仅仅使用用例驱动的 UML 规范对系统进行建模不会提供良好的业务反应性级别
想用
享受且渴望
可用
简单、易学、高效
有用
能解决问题
ቤተ መጻሕፍቲ ባይዱ
“我根本不知道谁在用我们的产品，也不
知道用户对我们的产品评价如何。
头脑风暴，集思广益
自由畅谈 延迟评判 禁止批评 追求数量
选择影院和电影 付款
选座位 取票
视觉化用户场景
三大步 8小步
理解客户 理解用户
概念设计
理解客户：第一步
在业务模型中确定并获取了五个主要的元素： 业务流程图（Business Process Maps） 业务流程（Business Processes） 业务参与者（Business Actors） 客涉众（Customer Stakeholders） 业务目标（Business Goals）
USBD 是被提议的覆盖软件开发端到端范围的统一的设计方法。目标是能够设计出 覆盖所有或部分被建模的业务过程的产品，以及帮助预期的用户利用最可能的经验 实现所确定的目标。USBD 所描述的开发的另一方面是如何通过简洁，而完全的形 式化文档集支持生产者和消费者之间的沟通渠道。
场景是什么？
一个用户场景就是一个描述某个用户在某个环境中 完成某个任务的故事。
理解客户：第二步
完成业务模型 用例图显示所有已确定的业务用例 追溯客户涉众、他们设定的业务目标，及支持那些目标的业务用例之间关系
理解客户：第三步
开发业务分析模型
业务用例参与者 — 包括业务操作者和业务参与者 — 以及他们的关系的静态 视图 序列图（每一个表示不同的业务用例场景或子流程）表示存在于业务操作者 之间，用以实现业务用例的交互
Outside-In Design（OID）方法和过程代表了以用户为中心的设计（UserCentered Design）和 用户工程（User Engineering）最后的演进步骤。主要的 焦点在于产品线所处于，或计划处于的业务环境。更确切地说，OID 的目标是定 义此类产品的用户，以更好地设计他们的交互体验。这使得 OID 在用户接口设计 领域中非常有效。如果在 OID 方法中寻找弱点，那么其弱点是缺少业务环境、系 统环境，和用户接口之间的正式连接
理解用户：第六步
创建角色，这是用户原型，封装了通过与许多具体的当前或潜在的产品用户进行 面谈而收集的所有知识 针对每个被确定为需要一个产品的具体接口的用户，来创建不同的角色来详述典 型的用户目标、任务和技能
每个角色显示为拥有一组 skill 原型技能属性的类。每个角色都与它覆盖的所有用户（用户角色）相关联，并且由主 要角色（primary persona）、次要角色（secondary persona）, 补充角色（supplemental persona）、负面角色 （negative persona），等等的原型进行标记。建立连接并验证角色和分析阶段中确定的（或者可能是反向工程）实 际系统参与者之间的关系是有用的
就令软件产品快速地响应业务中的变更的能力而言，从业务过程元素到系统元 素的正式追踪为您提供更大的灵活性。您可以使用为系统建模的同样形式来为 业务过程和目标建模，通过利用这样的事实，您现在可以获得整个端到端的视 图的单一的描述，从业务需求到软件产品。 • 通过正式的、基于 UML 的用户和用户接口建模，在参与软件开发生命周期的不 同团队之间创建明确的文档及通信 • 为您提供将用户接口和系统模型链接起来的能力，使您更容易地找到错误。这 使您可以将所有设计软件系统的最佳实践应用到用户接口的设计中来。
• 产品是有场景的 目标完成业务流程完成业务的人完成任务
• 一个场景是由多个情节组成的，将情节串联起来就是情节板 人情节GUI（元素）GUI导航
• 场景并不都只有happy story 基本流备选流 • 始终不要忘记你的目标是什么？客户的目标是什么？