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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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