产品经验总结：旅游产品实操流程

　　旅游行业一直是我很看好的行业，现在我以一个旁观者的身份，结合过去几年的旅游产品经历，简单分析一下旅游产品实操的相关流程。

　　

　　旅游：是你去到一个地方以当地人的视角去体验当地人的生活，旅游离不开吃，住，行，购物，玩，安全，天气等。

　　旅游是一个必须要出发的消费过程，其目的地对旅客来说是比较陌生的，那么这就决定了旅游的用户群体：有经济来源，行动方便，有一定社会阅历和应变能力，有空闲时间;按照这个用户画像你大概能定位旅游的用户群体年龄段是：16~70岁之间，那么包括三个年龄阶段，青少年，中年，老年。

　　旅游类APP/网站的目的就是为了解决旅游相关的需求的，因此在做产品前，要考虑清楚产品的要素，目的是为了做到心中有数，知己知彼。

　　

　　在考虑清楚要素后，就是要弄清楚通过哪些业务系统来帮助到消费者，解決旅遊出行需求。

　　

　　业务表现层是罗列了旅游产品线涉及的相关业务(上图概括不是很全面，吃，娱 等没列出)，但是具体开发哪些系统要根据实际情况和公司的战略而定。

　　如：老年用户选择的旅游产品形态是团队游比较多，中青年选择的产品形态是自由行比较多，那么对不同年龄层要提供相应的产品系统; 如果公司只专注周边游，那么交通选择是汽车，+酒店+保险+门票等就可以搭建符合公司的产品框架了。 如果定位的是服务港澳用户，那么交通就只能选择：机票/船票，因为香港和澳门都是岛屿;如公司定位的服务群体是国内，那么签证系统就没必要开发。

　　如果我获取的需求是公司要求开放 机票系统，酒店系统，度假系统，那么下面就以这个三个需求来进行实操说明。

　　一、 产品的流程

　　互联网产品都包含前端和后端，其对应的用户不同，产品流程也不同，可以分为如下三个流程：

　　

　　页面流程：是指APP/H5，Web 网站前端页面走向，页面流程有一个特点就是下一个页面的产生是依赖上一个页面的操作的，有明显的流向性。

　　操作流程： 是后台处理流程，后台操作页面是预置的，功能和模块是固定存在的，后台操作流程受：账户权限和订单状态影响。所以状态其实控制了后台的操作流程顺序。

　　逻辑流程：主要是代码层面上的逻辑，并没有页面可见，页面与页面之间的操作，在后台会做很多接口回调，task ，触发器等处理。

　　二、订单类(电商，旅游)产品流程的特点

　　页面流程：一般包括的主界面有：查询首页，产品列表页，产品详情页，会员登录页，用户资料页，付款页，提交成功页，订单详情页

　　操作流程：后台的流程界面有：基础资料维护，订单查询，订单处理，结算，报表，邮件，权限设置，CRM，Task;其特点是可以增，删，改，查，怎么合理的安排增删改查是操作流程里要考虑的，订单处理的流程是状态的改变(提交待处理，确认供应商，确认资源，出票，确认收款，配送/发货，成交，取消)

　　逻辑流程：在这里讲有点抽象，可以去了解一下资源的融合，还有像付款时的风控体系：调用风控接口，返回风控结果，根据风控结果确定是否hold预授权，task自动扣款，释放预授权诸如这类。

　　三、分析需求

　　我们产品的业务目的就是能帮助用户：买到机票，预订到酒店，预订到度假产品。

　　为了实现业务目的，我们需对机票/酒店/度假系统的基本特性进行提炼。如下图：

　　

　　

　　

　　根据上面信息和已有认知，进行头脑风暴：

　　机票和度假系统都有出发地和目的地，但是酒店产品没有出发地;

　　机票和度假一定有去程出发日期，也可以有返程日期，那么去程资源和回程资源应该是两个单程资源， 一个资源是A~B，另一个是B~A,A 和B 都是对应到的城市。

　　酒店资源有入住日期，并且一定要有退房日期

　　机票和度假产品 精确到的时间是:XX时XX分，因为航班有一个时间点，酒店精确到 X日就ok

　　机票和度假产品有区分成人/儿童，而酒店产品只讲总人数

　　机票会受到机场的限制，度假会受到航线和停落地限制，酒店受限制很少

　　产品都应该有价格，有总价也会有明细

　　旅游是必须出发的消费，那么要知道是谁出发，怎么联系出发者

　　会有一些外部因素导致流程受阻，怎么完成流程(流程的终点有两个，一个是成功，一个是失败)

　　要展示一些信息给用户，用户才能对产品有一个大概的了解。

　　等等

　　第一个页面怎么做? 为什么这么做，依据是什么?

　　机票系统和度假系统本来是有出发地 ，但是出发地也有固定出发地，和非固定出发地之分。如产品早期，受到公司资金，手中资源，业务处理等因素影响，出发地是固定一个城市，则只有目的地是可选择的。

　　产品后期，公司资金充足，业务扩展了，机票系统和度假系统的出发地不再固定为一个城市，系统则要提供出发点选择列表和 目的地选择列表，并且这里的列表数据都要有机场才行，否则会导致列表失效。

　　资源的丰富程度会决定系统实现的模式，如携程的机票，酒店，度假产品，其出发地 和 目的地 的可选列表数据全面，那么决定其使用 查询模式 作为入口才是高效的。 如果像永安旅游度假产品，公司战略决定了出发地是固定香港的，并且其目的地覆盖城市不多，那么采用 目的地分区归类的形式展示比较实用。

　　如下图，资源丰富性和服务广度决定了实现方式的不同：

　　

　　

　　根据系统需要结合实际情况，可以基本确定各系统首页元素(其他没考虑到的地方可以后期优化，布局上要预留优化空间)：

　　机票采用查询首页(出发地，目的地，出发日期(单程/往返去程)，回程日期(往返回程)，舱等，人数(成人/儿童));

　　酒店采用查询首页(入住城市，入住日期，退房日期)

　　度假根据出发地是否固定来设计首页(固定则用目的地分区归类显示;不固定则用查询出发地+目的地分区归类显示)。

　　找到系统的入口后，我们就可以根据前一流程的结果推导出下一流程。

　　查询首页后一般会得到一个数据结果集，这个结果集怎么设计布局要根据你的产品理念来，如酒店，查询后一定得到一个对应城市的酒店列表，酒店与房型是1：X ，你可以在酒店列表页展示出房型数据，也可以新开一个页展示房型。这种细节的考虑是能反应产品经理的产品感。

　　

　　

　　

　　我们规划的这个流程要能把用户想要的功能塞进去，怎么塞?这个就是具体页面功能的展示设计了。你可以在EXCEL里把所有的功能都列出来，然后把草图画出来，最后对功能进行类 Swot的分析。

　　机票/酒店/度假 通过首页查询出来进入资源列表页，资源列表页要展示的资源比较多，则要排序，提供筛选规则;具体到数据的展示项时，酒店要给用户展示(酒店图片，酒店名，星级，位置，价格等)，机票则要展示(出发时间，承运航空，舱等，航站楼，价格)，度假产品则要展示(产品图片，产品名称，产品类型，起价等)

　　资源详情页，可以说是用户真正执行需求的开端点。

　　下面的步骤已经是深入到解决方案设计的层面了。围绕中心是，需要什么功能才能解决用户需求。

　　用户需要订到XX酒店的XX房型，用户需要预订到XX城市到XX城市的机票位置，用户需要预订到X出发日期的XX产品。设想一些用户使用场景，参考一些成熟网站的做法，设计出页面的功能模块。

　　功能模块是躯壳，数据是躯壳的肌肉，数据来源情况，特殊数据的兼容等是产品设计时需要考虑的(根据优先级放在后面的优化项目里处理)。

　　产品经理对行业的业务开展要有一定的体验，至少没吃过猪肉也要见过猪跑。

　　旅客资料页的设计要求有一定的业务常识，酒店你只要输入入住人姓名或者联系人按理都是OK的。那就要为客人减少输入项，只要求必须输入项就OK。 但是机票和度假会涉及到较严格的规则校验，从一个地方到另一个地方是有政策风险的，那么就要证件，姓名，性别等较全面的输入项。

　　支付页，提交成功页，详情页等设计时要考虑客户可能喜欢用上面支付方式，系统是否有必要，有没有安全风险。那些内容是提交页需要展示的，那些可以放到详情里，页面之间的衔接流程怎么样的。

　　完成上面步骤后产品的初始模样已经成型,会产出低保真的交互模型 和 功能说明的需求文档。然后产品还要放到团队里去评审，打磨，不断优化，最终定稿。

　　UI 设计师会根据定稿的低保真原型，调优，画出高保真的原型。 高保真通过审核后就可以交付给开发人员。

　　这里由于篇幅问题只讲了前端的页面流程，后台的操作流程和逻辑流程没讲。其实后台流程的设计决定了前端页面的流程，如机票的资源：设置为往返，那么资源列表页展示的都是往返机票，选择去程就会固定返程。如果设置为单程，那么两个单程就可以组成一个往返程，操作页面就必须先选择去程，再打开另外一个页面展示返程。这些以后有机会再讲。

　　这里写的都是我个人经历后的理解，不免都说错了。张小龙说我说的都是错的，他是谦虚，我是实话实说。

　　其实产品是一直在路上的~~

*请认真填写需求信息，我们会在24小时内与您取得联系。