智慧车行需求设计

1 评论 3878 浏览 28 收藏 14 分钟

出门在外时,自驾游找不到停车位折腾了不少时间,面对这样的游客顾虑,想必大家应该想到了游客的一些需求。作为产品经理,应当如何优化导航APP,让大家更好地出行?本文结合该应用场景,进行产品设计分析,一起来看看吧。

产品设计核心流程:

刚过的新春,宠游客的重庆封闭了道路只为游客有更好的视野,再现了人山人海。那自驾游的大家,在停车的时候,遇到了一些啥情况呢?

一、应用场景

你知道哪里有停车场不?

那个停车场可以停多少车?还有没有车位呢?

1.5元还是2元一个小时?

这是最常见的询问方式了吧?只不过当前,导航系统都可以导航出来,就不再使用询问的方式了。但是,导航搜索出来的停车场依旧没有剩余车位和计价方式。嘿嘿,各位地图导航的产品们,这就是需求哟 [偷笑]

这里司机师傅最关心的就是:哪里有停车场?停车场还有多少车位?停车费怎么计算?

既然都是智慧车行了,这些当然都需要提供。产品设计最核心当然是完善整个业务场景。

生活中一个小的问题,通过互联网的方式来解决,就需要产品经理来转化,将问题和解决方案融合起来。但问题只是整个解决方案的冰山一角,要解决方案能够完整运行,就需要将整个业务的全貌找出来。停车场本身的信息,在这个问题里是没有体现出来的,那么怎么做,才能完整整个业务流程呢?

梳理完整解决方案参与的角色及其所需要的功能(用例图),然后串联着整个业务流程(业务流程图),将相关的所有因素串联完整。

二、用例图

智慧车行用例图

司机知道哪里有停车场,停车费可接受,也能够停进去之后,就会进行停车,然后去处理自己的事项。辅助这个决策,就需要知道 停车场位置、收费标准、是否有停车位。

随着当下车牌识别技术的成熟,很多车库已经无人值守。这就是信息化的便捷、效率。做以上的业务分析,本身在停车开车的场景下是闭环的。但在现实中是不够的,很多停车场是小区的,是园区的,是公司的,那就需要更为完善的支持,提供停车月卡、年卡服务。

另外,若是小区物业的车或公司领导的车,是需要有特殊权限的,需要进行额外管理。

三、业务流程图

智慧车行业务流程图

整个停车场管理业务最小闭环业务流程包含:停车场管理流程、停车流程、开车离开流程。

停车场管理流程主要是维护好停车场基础信息,如位置、停车位数量等;并设置好收费标准,为后续的费用管理奠定基础。

司机开始停车,遇见门卫管理。门卫确认扫描信息,然后开门允许停车。是停车的流程。

司机办完事情,开车离开。在车库门口扫描,系统计费,然后缴费;经门卫确认后开门,开车离开。是开车离开的流程。

在真实的系统设计中,需要完善月卡办理后的流程、以及设置白名单的流程,也就是离开扫描时,需要判断资费类型,然后确定结算的处理方式。系统内部设计会复杂很多,但业务流程实际上就是这样。厘清业务,对于系统设计,至关重要。

四、操作状态图

在停车业务场景中,业务流程相对比较简单,比较清晰,也没有太多状态、操作需要管理。但在扩展的月卡管理上,就有较多的状态操作需要管理。

通俗一些来说,月卡常出现的场景包含:办卡、缴费、欠费、停用;而涉及系统的管理,就需要增删改查等操作。如此,就包含了5个主要操作,也就包含了5个状态。使得整体业务复杂度增加。在不同的月卡状态,可以做哪些操作,就变得比较复杂和不好记忆。在页面交互上,会在不能操作的情况进行对应按钮的置灰或者隐藏,但如何在设计时候更明确的表达并向下宣贯,这个就很重要了。

设计下面的操作状态图,是不是就很明晰了。

月卡操作状态图:

月卡状态在不同的操作下,进行了状态的修改,实现了月卡数据流转的核心流程,实现系统构建的完善。

月卡不同状态有哪些操作:

月卡在不同状态下有哪些操作,一是反向检查流程是否有遗漏,二是明确的告诉下游开发、测试各个状态下有哪些操作。相比于口述或者文档表达,这里清晰明确。

在一开始的设计中,月卡操作状态图中的黄色连线,实际上是遗漏了的。

对应状态可以进行的操作,有个简便的处理方法:将所有的操作都放置到状态下,然后把这个状态下不可执行的操作删除掉,最后统一整理即可。

五、交互设计

信息实体字段梳理

基于整个业务场景的分析,主要实现4个信息实体的管理:停车场管理(含车位管理)、月卡管理、白名单管理、出入记录。其中,停车场管理、月卡管理、白名单管理为管理事项,而出入记录才是使用最频繁的模块。

出入记录

在临停车辆出的时候,需要计算费用。系统可以通过出入记录的费用计算和最终缴费经费作比对,以便对于门卫进行经济方面的核查。

停车场管理

停车场和停车位是绑定的基础信息,一次性维护。一般只会在停车场进行改造或者维修的时候进行调整。

这里实际引出来,车位的状态里面还包含停用的情况,需要继续完善需求。

月卡管理

月卡管理主要明确哪些车辆是通过月卡通过门禁的。这里需要注意是,开门时,若月卡已经欠费需要按照临停规则处理,程序实现时需要做异常流程兼容。

白名单管理

白名单管理主要明确哪些车辆可以特殊权限通过。这里需要对有此权限的人员在业务中加以管理,谨防以权谋私。当然,这些情况都可以通过数据汇总统计的方式来进行监控。由数据来监察业务执行情况。

六、数据追踪

经历以上五个部分的逐步完善,整体需求就很明晰。在本身的设计逻辑上,不会存在巨大的漏洞,并通过整个过程的反复检查,逐渐细致到每一个需求功能点。但,可能还是存在漏的可能!

如,第五步所示,出入记录就缺少“费用”字段,这是在设计之初遗漏掉的,但在详细设计时,发现并得以补充的。也就有了当前这一步,数据追踪。

在系统实现中,所有的字段都是有意义的,需要明确字段在哪些场景会用到,最终在哪些场景消失。选用几个字段,在每个场景中再去检核一次,就会发现最后的遗漏。甚至于能发现业务不合理的地方,从而优化业务。

1,在停车位管理中,增加了“是否私家车位”,当前业务并没有串联该字段,也就是系统还需要继续完善,或者在设计中去掉该字段;

业务中可能存在,私家车位就相当于白名单的情况,那就是创建车位时,选择是 私家车位,就同时创建一条白名单;也有可能,办理月卡就绑定车位,那就是月卡创建时,选择车位就好。这就需要依据业务的具体情况来定。

但,即使因为这个变动要修改,系统变化始终可控的,并不会影响产品主框架。

2,钱是串联整个业务的,那么,就用“费用”这个字段来检核整个流程。

缴费发生在2个场景,一是临停车扫描出停车场的时候(这里检核出入记录少字段的情况),二是月卡缴费的时候。线下业务每月需要做账,那么线上,就可以出具临停车缴费记录、月卡缴费记录,并做相应的统计。可以和线下费用做核对,也可以依据该表单进行后续的数据分析,如:停车位的使用情况、月卡占比,以及同比环比的比较,从而挖掘出来,是否可以扩展一些停车业务。

数据追踪的字段选择,不必要太多个,也不一定非得专门挑选。这里主要是用字段这个角度,再次来检核一遍整体的设计,完成设计本身的自闭环。

智慧车行的整体设计还并没有完成,需要完成PRD文档的撰写,方便信息的传递和存档,用于产品成长的追根溯源。

以上,在产品设计环节,并不一定需要每个环节都按部就班,随着经验的丰富、逻辑能力的完善,产品在接触到这个业务的时候,就已经有了产品的大框架。这也是产品本身的提升和增效。终归来讲,业务流程的梳理,始终是非常必要的。

为何经历产品经理这么严谨的思考,经过开发、测试反复验证,仍有产品在上线后不符合使用者的预期,需要不断的迭代。就是在于业务的分析不彻底,整体的流程未和现实业务相匹配。当然,本身也存在,线下业务因为种种复杂原因,需要进行特殊调控的情况。

保持开放的心态,尽可能的保证产品大框架的稳定性,终归产品会在版本迭代中升华,面世中有那么多优秀产品就是明证。

当然,本期题为“智慧车行”,这里智慧体现远远不够,或许,大家可以加一些柴火,烧的更旺。等你们哟~

本文由 @壹叁零壹 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 还以为是卖车的车行hang。。。。

    来自江苏 回复