前阵子从同事那里得到消息，有需求方想做一个租赁礼服的App，可以进行AR试穿。由于当时能拿到的消息就这么多，本来想去下载几个租赁类App参考一下，可惜乞丐版手机没有空间。正好目前也比较闲，便尝试对整个事情进行分析，看看是否能较为合理的完成这个案例。

需求分析

整体平台搭建

虽然对方初步提出只想要一个租赁类App，但实际分析下来，仅靠一个App是没法支撑起租赁这个行为的。真正的需求是一个前、后台齐全的租赁平台。大致如下：

1. 前台App：主要提供租赁、个人信息管理等功能；（后面再展开讨论）
2. 后台：至少需要有两套管理台（不考虑部署问题，仅从展现端考虑），一个向商户提供商品信息、订单信息相关的管理功能，另外一个是该租赁平台方自身管理个人客户、商户各类信息的功能；
3. 其他比较重要的模块：最容易想到的就是与交易相关的支付功能，既然作为一个平台方来运营，这里最好建设一个较为完整的支付平台来支撑，方便对资金进行管理和调拨。

App功能分析

按照客户要求，App端最重要的功能当然就是“租”了，即通过各种手段让客户来找到合适自己的礼服，比如搜索、推荐、活动等等。除此之外，本App需要用AR作为亮点，所以此功能也需要作为一级入口提供。参考一些购物类、生活类App，拟定前端主要结构如下：

后台管理功能分析

由于需求不是很明确，这里可以分阶段进行分析。

1. 若需求方体量足够大，可以独家开展礼服租赁业务以及相关增值服务，那么只需要建立一个平台侧的管理端，无需考虑商户；
2. 反之，则需要引进商户来扩充平台内容，向客户提供多样化的租赁服务，做法跟X宝、X东类似；

需要支持的常用功能如下：

个人理解平台方和商户侧的功能基本类似，只不过平台方需要对商户、平台进行管理，再加上后续的运营需要，因此会多出相应的功能，即可以把平台方视为一个特殊的商户来对待。另外，相同菜单开放的权限也需要注意；这部分功能可以通过注册成各类平台商家进行参考、完善。

其他模块分析

这个部分主要考虑需要与哪些外部系统有关联。既然是做礼服租赁，不可避免的会涉及到付款、收款等行为。不论是自己单独运营，还是引进商户，常用的做法是作为商户接入各类第三方支付平台，由其进行资金清算。（直接让对方转账这种“暴力”收款不考虑）选择第三方支付平台，主要考虑的基本就是费率以及清算频度。

这里我们搭建的支付模块主要包含功能如下：

简单设计思路

App部分

按照上面的需求分析，App端暂定有5个一级选项卡，大致样式如下：

（1）页卡详细说明

首先是一边分析一边整理在设计过程中可能涉及到的页面和其他元素，做好分类，便于管理和制作交互稿。

接下来整理每个页面的逻辑。

（2）首页

首页界面需要体现出app的主干业务，保证客户能够获取自己想要的、感兴趣的信息。因此，各类活动信息、垂直搜索功能不可或缺。同时为了保证客户拿到可用的信息，定位功能也是必须的。

（3）分类

分类页面提供明细选择，客户大部分的租赁行为都是通过本页面完成，所以如何提供合适的分类，需要仔细斟酌，再参考运营一段时间后的各类数据来进行调整，不断完善。

（4）AR

作为 App 的特色功能，设置为一级选项卡是为了保证用户随时都能点开使用，提升用户活跃度。此外，本页面不应设置太多的门槛，比如不要求客户登录、参数不宜太多。

（5）圈子

提供场所让用户与用户、用户与商户互动，类似贴吧、论坛的地方，因此需要加强管理。又因为移动设备屏幕有限，所以功能不宜太复杂。

（6）我的

涉及未登录和已登录两个页面，如下：

（7）部分页面示例

搜索类：

商品、注册页：

最后，不可避免的需要根据客户方、开发人员多次沟通，调整界面功能，完成最终的设计稿。在确定主体需求的时候，前后台已经可以同步开发了。

后台管理部分

管理台部分按照最初的分析，主要提供如下功能：

1. 业务信息类：管理商品、个人、订单、活动等信息；
2. 报表类：提供流水、简单分析、统计类报表；
3. 平台类：平台自身参数配置，用户管理；
4. 自定义类：个性化首页配置；

一般来说，后台管理端对应的用户量并不大，系统也不需要支持很高的并发。在设计的时候，可以不用考虑很多性能方面的问题，而且很多前后端框架本身的性能也不差，我们优先把关注点放在功能的实现上。每个功能点大致都需要围绕输入/输出界面、操作流程、异常处理这三点来完善

其他部分

对于支付模块的设计，仅就完成功能而言，主要包括：

1. 账户体系：需要建立一套虚拟的账户体系，包括与银行卡账户相对应的子账户、红包账户、临时账户（比如活动账户），以及每个账户的扣帐原则、分录；这部分需要跟客户信息进行挂钩，用于评定客户等级、赠送积分等等。
2. 支付邮路：灵活的邮路切换原则，找到成本和效率的平衡点；
3. 流水：支付流水的查询以及差错处理，设计时需要考虑到客户的感受，毕竟支付出了问题体验已经不好了，如果不能及时定位以及处理差错，那么失去客户也是分分钟的事情；
4. 报表：这块主要是为了进行运营分析，所以维度要尽量多一些，每一种表样在设计的时候需要多斟酌一下，不要产生模棱两可的含义；

余下的事情

1. 数据库的设计、开发框架的选择就丢给资深程序猿大神们了。当然，产品狗适当的参与、了解也是必要的，便于后期开展工作；
2. 账户体系、支付模块的设计应该可以通过网上找到成熟文档，设计时可以多参考一下；

总结

第一次尝试做app端简单的交互设计（姑且这么叫吧），很多地方可能也不够完善和美观，希望能在以后多看到相关资料来提升，也希望在这里找到各类产品牛人带我飞。

对拓展功能的思考：

• 当客户在看中某产品时，并不仅仅只有租赁可选，还能直接买下。如果这样，商品页面、购物车、付款页面等都需要做相应的调整。
• 根据运营方式（会员、押金）来给客户提供更多的附加功能，例如目前比较火的开锁共享单车，当然这些需要通过数据来验证效果。

本文由 @盗不留蘅 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pixabay，基于 CC0 协议