以最近在做的项目为例总结B端产品设计

前面在谈“二清”的文章中提到我最近在做一个养老院管理的项目,这是我第二个B端项目。这篇文章是对养老院这个项目的复盘总结。

一、产品背景调研

1.了解客户诉求,与客户沟通产品期望

和C端产品一样,在接手B端项目时,第一步都是对产品的背景调研。不同的是,B端的项目第一个要接触的是客户。

首先我们需要了解客户的诉求,他是基于什么样的想法需要做一个产品,他想要为谁而做等等。其次我们需要引导客户让他描述出对产品的期望,在这里注意不能直接问客户“你想要一个什么样的产品”。因为这样做,我们往往不会得到一个全面的答案。

在这个阶段,我们访谈的客户一般都不会是业务需求方而是高层,所以我们不需要得到太细的业务需求。

必须要明确问题有:

      • 目标用户 这个产品为谁而做?
      • 出发点 客户为什么需要做这样的产品?
      • 核心价值 竞品为何不可以?
      • 需求 产品能够解决什么样的需求?
      • 目的 希望产品能够达到什么样的效果?

养老院的这个项目,通过访谈客户公司的最高领导人了解到,该公司是一个养老领域集团化管控的公司,下属有7家养老院。客户表示因为现在集团旗下养老院都是用传统的纸质办公,数据也都是由员工进行上报,对于集团化的监管都不标准并且不规范。所以希望通过数字化平台解决信息互通、管理规范、数据透明的问题,为养老院提升服务质量、业务效率从而为集团带来更大的收益。

用上面5个问题进行整理则是:

目标用户:这个产品为老人家属、养老院院内医护人员、养老院管理人员、集团管理人员

出发点:目前的方式对于集团化的监管都不标准并且不规范

核心价值:竞品不够美观、在费用计算上不能完全贴合集团的标准化业务

需求:希望通过数字化平台解决信息互通、管理规范、数据透明的问题

目的:为养老院提升服务质量、业务效率从而为集团带来更大的收益

2.行业背景、竞品调研

在了解的客户的诉求后,我们就需要尽快了解对方的行业背景,调研当前市面上的解决方案。

在养老行业,我国推行的养老模式主要为“9073”模式,即90%的老年人由家庭自我照顾,7%享受社区居家养老服务,3%享受机构养老服务。前瞻认为,我国机构养老、社区养老、养老护理用品前景均较大。
养老院服务的对象主要以重度失能老人和孤寡老人为主,其中46%是重度失能老人。
截至 2019年6月底,中国共有各类养老机构2.99 万个,社区老服务机构和设施14.34 万个,养老服务床位合计 735.3万张,养老院实际床位空置率达到48%左右。养老机构发展滞后,存在着服务能力不足、专业护理人员缺乏、难于可持续发展等一系列问题。

对于养老院使用的数字化管理系统,目前业内较为知名且成熟的养老管理平台是:三开、跃达。

对于B端的竞品调研的目的主要是让我们能够在短时间内迅速掌握竞品对于产品的理解、行业内主要的业务模块有哪些。

3.利益者相关地图

在做了行业背景及竞品的调研后,下一步是要着手准备客户公司各岗位的访谈,来了解其职责和业务。

在此之前,我们首先需要对客户组织架构管理关系做以了解,以便于站在宏观角度理解业务,并且能够为之后排优先级时作为依据。

养老项目的利益者相关地图如下:

4.向部门负责人调研业务期望

梳理完成客户的组织架构及管理层级关系后,接下来需要对应去找部门负责人进行访谈,在这一阶段去了解其部门是负责哪些业务,业务之间存在哪些关系。部门负责人对于产品的愿景如何,他们期望解决自己部门什么样的问题。

在我访谈了院长、财务、护理部主任、行政后,获得的信息分别是:

    • 院长:可以通过产品了解院内状况,如财务收支、老人在院数量、床位使用率等。
    • 财务:产品可以解决老人每月、出院的费用结算,从而免去人工计算。
    • 护理部主任:产品能够管理下属员工,查看老人全面的情况,上传下达,实现办公自动化。
    • 行政:能够对院内员工进行管理
    • 后勤部主任:进销存情况、与财务之间的往来可以在产品中看到
    • 集团行政:能够看到下属养老机构的数据,可以查到院内任何信息

 

二、业务流程调研

1.岗位角色用户画像

了解完项目背景之后,这一阶段就需要我们去做业务分析。去和客户的公司各岗位角色进行访谈,了解对方的岗位职责,越详细越好。为接下来我们梳理主要业务流程做支撑。

与C端不同,在做B端的用户画像时,更偏重该岗位职责。每个访谈时间长度控制在30-50分钟。

以下是我在养老院项目做的用户画像:

2.主要流程分析(跨职责流程图)

做完用户画像后,我们基本能够明白客户公司的主要业务是什么,存在哪些重要的流程,在我们做系统设计的时候不能出错。当我们画出流程图后,再去和业务方确认,是否如此,有无需要修改的地方,最终定稿。

养老项目的核心流程则是老人入院的流程。

三、产品结构设计

1.与客户沟通需求清单并确定优先级

通过各岗位访谈,了解了角色在什么场景有哪些职责,我们已经能够列出了一个业务需求清单。再加上之前从竞品调研中得到的启示、我们模拟用户在某几个场景中的旅程得到的体验性需求最终建立我们的需求清单。

再把需求清单中的需求与客户一起逐一对照 KANO 模型进行分级,那么「基本需求」则是我们在MVP中要做的。

 

在这一步,对于养老院这个项目,我列了其中一些需求作为案例展示:

 

在对需求进行简单的分级之后,我们将「基本需求」、「期望需求」拿给开发,让他们估一个技术实现成本的点,再呈现给客户,看他们是否需要修改优先级。

2.产品结构及业务设计

在客户确定完MVP的需求清单后,我们就可以针对这些需求开始梳理产品功能架构,以及业务逻辑的设计。这两项工作是在同期进行的,原因是在考虑某需求时,它需要哪些模块支撑,这些模块的关系是什么。

比如在做护士交接班需求时,要思考护士交接班给谁交接,是交接给院内任何一个护士吗?不是的,交接班一定是排好的班次,班次内进行交接班,比如上早班的护士交接给上午班的护士。那么这里首先需要一个护士排班管理的模块。

其次我们再去考虑当护士站排班之后,护士只能看到自己哪天上什么班。如果院内只有3位护士,护士就很清楚下一个班交接给谁(我在做需求调研的养老院确实是这样)。

但如果养老院规模较大,院内排班一个班有多个护士呢,这样的话,护士就不知道该把班交接给下一个班次的哪一位护士。这里就需要引入”护士组“的概念,我们规定,护士交接班时,交接给自己组内的下一位护士。

同时,这里还出现了这样的问题:如果存在交接班,那么护士与老人就不是和护理员一样的1对1的绑定关系,而是有可能多位老人对应某个班次的护士。引申出的需求是:当护士交接班后,该老人的任务则会转移到下一班次的护士任务池中。那么是不是把老人也进行编组,这样就可以和护士组对应起来?我们试想,如果一位老人在某天办理了床位升级计划,由5楼住到了1楼,5楼老人组所负责的护士仍需要跑到1楼去执行该老人的任务。所以考虑到护士业务场景,通常一个护士站对应的是某几个楼层,一个护士也对应的是某几个房间,我们需要将房间与护士组关联起来,即护士只对住该房间的老人服务。因此,我们机构后台还需要一个「房间组管理」的模块。

业务规则设计如下:

 

功能模块清单这里以机构后台部分功能作为示例。

 

 

3.书写用户故事

《用户故事与敏捷方法》对于”用户故事“的定义如下:

用户故事描述了对用户、系统或购买者有价值的功能。用户故事由以下组成。

    • 一份书面的故事描述,用作计划和作为提示。
    • 有关故事的对话,用于具体化故事细节。
    • 测试,用于表达和编档故事细节且可用于确定故事何时完成。

用户故事的描述信息以传统的手写方式写在纸质卡片上,所以Ron Jeffries(2001)对这三个方面称为3C:卡片(Card)、对话(Conversation)和确认(Confirmation)。

卡片可能是用户故事最明显的表现,但它并不是最重要的。Rachel Davies(2001)说过”卡片代表客户需求而不是记录需求“。这是对用户故事的最佳诠释:卡片包含故事的文字描述,然而需求细节要在”对话“中获得,并且在”确认“部分得以记录。

而一般的,我们把用户故事的正面格式定为:

作为…通过…的操作,以便于达到…的目的

卡片背面则书写验收标准(Acceptance Criteria)。

 

《用户故事与敏捷方法》还对于合格故事的定义为:

好的用户故事除了格式规范,要素完整外,还应该遵循INVEST原则:Idependent(独立的);Negotiable(可协商的);Valuable(有价值的);Estimatable(可评估);Small(小的);Testable(可测试的)。

在这里我举两个我们在编写用户故事的例子:

TS-001:

作为评估员,通过审核老人申请入住信息,以便于达到评估该老人是否可进行下一步入院的目的

AC:

1.审核通过,该老人信息状态变更为待评估员评估

2.审核不通过,需操作人填写不通过原因,提交后该老人信息状态变更为审核不通过

TS-002:

作为家属,通过输入手机号及验证码登录,以便于达到用户能够使用登录后的的服务目的

AC:

1.验证码正确,登陆成功,进入首页

2.验证码错误,登录失败,toast提示验证码错误

3.验证码获取超时,登录失败,toast提示验证码超时

4.重复获取验证码,验证码不可在1分钟内获取1次以上

 

四、前后台交互设计并书写交互说明

在编写完用户故事后,就可以进行交互原型的设计了。我的个人习惯是画完一个模块的原型图后再进行交互说明的书写。

示例:

 

 

五、对开发进行需求讲解,测试验收

到了这个阶段,实际上产品设计的工作已经完成了。接下来就是向开发讲需求,开发进行开发的工作,直至这张卡完成,他们会找我们来show case,之后我们再拿到这张卡进行测试验收。

测试这里要具体看团队的设置,如果团队中没有测试,那么测试的工作依然由我们产品部门来做。

一般的,我们会进行3轮左右的测试,第一轮测试后会产生很多的问题,提给开发后他们改一轮。第二次是我们回验一轮,他们再进行修改。第三轮就是到后面所有的卡已经完成,我们在测试环境及线上环境都跑一遍,如果还有问题,开发再进行集中修复。

 

 

本文是我在做的这个B端项目进行的思路总结,希望能够给大家带来一些帮助,可能会有些不准确的地方,欢迎交流。

 

 

最近也重新把公众号同步了,欢迎关注:

 

babykoala与产品设计(id:babykoala_fun)

2条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注