OSHB 模型：深度了解功能背后的逻辑.docVIP

OSHB 模型：深度了解功能背后的逻辑 / 一、你可曾遇到过如下场景 在面对某个需求时，需求方要求加入功能 A，理由是我看其他产品有且很好用，我们也要有。可是你觉得加功能 A 不合适，但你又找不出什么原因来说服需求方； 在看待某些产品的功能时，如产品 1 和产品 2，他们都是同类产品，但是在某些相同模块的功能和交互却完全不同，其背后的逻辑关系苦思不得其解； 在做产品功能和交互时，方案 A 和方案 B 不知道怎么抉择，即时最后选择其中的一个方案，领导问起背后的思考逻辑却答不出。 以上这些问题在职业初期也是经常困扰我的问题，但随着职业年限的发展和经验的沉淀，摸索出了一套解决这些问题的思路，我将此思路命名为 OSHB 模型。 1. OSHB 模型分为 4 个主要步骤 1）目的（objective） 顾名思义就是我们要探讨的这个功能或交互它最终所要达成的一个目的是什么，在工作中也是如此在接到任务需求或任务时定要先了解其目的是什么。 2）场景（scene） 理解为要达成此目的所触及的使用场景，在这个场景中分为使用前、使用中、使用后、心理状态。 3）假设（hypothesis） 结合场景分析对于某功能或交互方式进行双向假设，也就是有会如何，没有又会如何。 如：有哪些信誉好的足球投注网站输入款是否需要一键删除的功能，若有一键删除用户在输入错误的情况下可快速删除输入内容重新编辑，若没有一键删除用户会手动删除或光标定位至出错位置进行精确删除。 4）权衡（balance） 通过产品定位、用户人群和用户使用时的心里状态对双向假设进行权衡分析，最终产出的是一个分析的概论，通过这样的一个概论我们再决定此功能或交互方式的取舍问题。 后续将通过两个具体案例带大家深入了解 OSHB 模型。 二、案例 1 微信发消息之后撤回为何还要有提示： 1. 目的（objective） 此功能存在的目的是什么呢？消息撤回后的提示信息，具备什么人、在什么时间、进行了什么操作的属性，因此可以先简单的理解为目的是对操作记录的信息留痕。 就好比张三是个清洁工，因为疫情的原因需要定时对电梯进行清洁消毒，每进行一次作业就要在旁边的本子上进行记录，以便于他人查阅此项操作的情况。 2. 场景（scene） 撤回消息的提示这里分为两种场景： 消息发送者，发送消息后撤回； 消息接收者，看到信息被撤回。 1）场景 1（消息发送者） 使用前：用户看到所发消息内容有误，或者发错了对象； 使用中：既然内容有误或发错了对象，那么需赶紧撤回，以免他人看到； 使用后：若所发信息有误就重新编辑再发送，若发错对象了别人看见后会好奇撤回了什么； 心理状态：别人看见我发消息又撤回会怎么想，会认为我不严谨、有些尴尬。 2）场景 2（消息接收者） 使用前：正做着其他事，看见微信有消息提示，有人给我发消息； 使用中：点开一看，他把撤回了； 使用后：如果消息又重新发送了过来，会认为他打错了字。如果撤回后的消息一直没有再次发送，会想这人想跟我说啥，难道发错人了？ 心理状态：内向具有强烈的好奇心。 3. 假设（hypothesis） 1）消息发送者 若有撤回提示会显得我做事不严谨，有些尴尬；若没有撤回提示的话会认为反正内容撤回了，别人也不知道，所担忧的尴尬也将不存在。 2）消息接收者 若有撤回提示可以知道他人对自己有过发消息的行为，记录了他人的操作记录，具备他人对自己操作的信息掌控力。 若没有撤回提示，产品层会出现逻辑 bug，比如我在做其他事时看到有微信消息推送提示，但打开微信一看什么都没有，以为是产品 bug。如果是正在聊天中，别人把消息撤回，在一些商务谈判或借贷等特性场合，则会导致对方利益受损。 4. 权衡（balance） 如微信起初定位是一款即时通信的产品，随着产品的发展现如今已是一款贯彻我们生活的工具，如支付、电商、医疗、民生….对于这样一款覆盖面全的产品，安全需求也将显得尤为重要。 倘若有撤回信息提示，对于消息发送者来说虽不太友好，但其本身就是一个使用场景的附加功能，此功能的初衷是为了给发送信息有误时进行重新编。 倘若没有此功能在产品层会引发逻辑 bug，在用户层会导致信息断层所引发的安全因素会使得用户对产品的不信赖。 二、案例2 探讨音乐类 app，在音乐列表页，播放音乐后是前往播放详情页还是停留在列表页？网易云音乐播放后是前往播放详情页，酷狗是停留在列表页，他们这背后会存在什么样的产品逻辑？ 我们先将探讨的问题定义为：播放音乐后是否前往播放详情页。 1. 目的（objective） 在播放详情页听歌会的目的是何？会带来什么样的效果呢？如上图网易云音乐听歌详情页，在页面中会有封面、歌词、唱片播放等形式会带来烘托歌曲的氛围。 顾前往详情页听歌的目的是：烘托氛围、带来沉浸感。 2. 场景（scene） 结合是否前往播放详情分为两个场景