系列一主要从同一个城市的导航产品的线路规划策略以及呈现方案角度做了分析，并提供了自己一点改进产品的小想法。系列二将从异地，即跨市，跨省远距离的角度分析导航产品路线规划方案及其呈现策略，如果某个模块与系列一内容相差无几则不在此做赘述。
前提
1. 即使是跨市的导航，但由于现在城市的不断发展，某些城市间已经具备城际公交，所以对于这类城市（后续称作近距离城市）的导航方案可能跟同城的较为相近；
2. 除了近距离城市，另一种城市间类型，即城市之间没有公交方案（后续称作远距离城市）的路线规划方案展示策略跟其他的差距较大，故本系列将从这两个类型进行展开讲解。
跨城市路线规划方案
近距离城市路线指：跨市进行导航，但是两个市之间具有城际公交线路或者两个城市相邻，我们在分析中称它为近距离城市。
远距离城市路线指：跨市进行导航，两个市之间没有城际公交线路且不相邻。
使用场景解读
用户在什么场景下会搜索跨市线路的导航？动机是什么？期望得到什么结果？
a. 查询两地之间的距离，耗时；-------模糊地名搜索，给出两地距离，自驾耗时；
b. 自驾游；-------模糊/准确地名搜索，耗时，过路费，距离，拥堵情况，途径城市；
c. 驾车回家；--------准确地名搜索，耗时，过路费，距离，拥堵情况。、
用户在这三个场景下使用远距离的线路导航的频率较高，因此我们将从这几个使用场景出发，去发掘不同场景下，用户期望导航给出的路线方案应该具备哪些信息，目前导航类软件做的如何以及如何超越用户期望做到更好。
搜索
用户在任何场景下要进行路线规划，最先要做的一个动作就是搜索，那么我们允许的用户搜索粒度是什么样的？支持模糊搜索还是精确搜索？不同的搜索方式给出的搜索结果是什么？
用户在进行跨市路线搜索时，存在两种可能；
1. 准确知道起始地点，终点地址信息（此时用户可以进行准确地址输入搜索）；
2. 不知道具体的终点信息，只是想大概估算出行时间（此时用户的输入粒度可能只能到市）；
用户知道准确地址，我们只需要根据用户给出的准确地址为用户规划路线就好了，在用户输入地址的过程中，可以给用户一些可选地址列表，缩短用户的输入时间，实现快速输入；
用户如果不知道准确地址，比如用户想去自驾游，想提前预估路上要花费的时间，但是还没有定好具体要去的地方，这个时候用户输入的地址粒度可能只精确到市、县一类的地址。但是同一个市面积可能很大，例如从最东边到最西边可能也要花费2个小时左右，而且由于没有详细的地址，我们无法为用户规划精确的路线方案。
但是！
我们要知道用户输入粗粒度的地址进行搜索时，用户是在什么场景下进行的，他的动机是什么她想要得到什么结果。
用户输入粗粒度的地址时，大多数的使用动机是想查看两地间的大概距离，耗时等信息，这个时候如果强制用户输入准确地址，否则不能查看路线规划结果会给用户造成极大的困扰，用户可能并不知道为什么这个时候没法进行搜索操作，会给用户带来挫败感和极差的用户体验。更合适的方式是，当用户输入了一个粗粒度的地址时，我们允许用户进行搜索，程序可以在后台自动为用户补齐一个具体的地址信息，然后给出路线规划方案。
叫车模块
百度地图： 即使用户搜索的是跨市路线，也会给出叫车的费用，距离，最近的车离多远和叫车的入口。
高德地图： 会显示不支持跨区域叫车服务。
那么是否允许叫车呢？
这个问题应该从用户具体的搜索路线入手进行考虑。例如用户搜索的起始地和目的地是相邻城市，且这两个相邻城市之间有城际公交线路，例如广州和佛山，西安和咸阳。这种类型的城市，边界比较模糊，用户跨市出行的场景比较频繁，这个时候我们应该提供叫车这一服务，给出用户关于叫车服务的相关信息和叫车入口。但是对于远距离的城市，就算我们提供了叫车的相关信息和叫车入口，用户也几乎无法成功打到车。
因此在叫车模块，如果用户搜索跨市出行路线，如果是临近城市我们应该给用户提供叫车的具体信息和叫车入口；如果是距离较远的城市（不相邻且没有城际公交）我们应该提示用户不支持跨区域叫车功能。
驾车模块（没有太多区别，而且不管从展示的信息还是方案呈现角度都比较合理，因此在这里不做赘述）
展示信息：耗时，里程数，红绿灯数，收费，打车预估费用
公交模块
1. 展示信息
百度地图：（如果有）城际公交方案（耗时，步行距离，总站数，起始点，转程线路）
高铁动车方案（始发地到高铁站路线，高铁路线，终点高铁站到终点）
（耗时，票价，购票入口）
火车方案
飞机方案
出发时间（改变出发方案，给出的火车和高铁动车方案会根据时间改变，公交方案会提 示已停）
高德地图：（如果有）公交方案（耗时，步行距离，票价，转程线路，总站数）
如果用户搜索的路线没有公交方案，则高德地图才会显示火车方案
2. 该怎么样判断当前模块下应该具备的方案？
从上边的展示信息我们可以看出，在这种有城际公交的城市间，用户搜索公交线路的时候，公交的转程方案必然应该呈现，那么高铁，火车等的方案要不要为用户进行展示呢？
回到我们最开始分析的用户使用场景，这种搜索多发生在短途旅行和跨越两个城市回家、上班的情景下，而跨越城市的公交耗时必然较长，现代人越来越没有耐心去等待这么长时间，因此除了公交方案，火车，高铁也应该为用户提供。
百度地图在公交模块下罗列了除了客车方案之外的所有出行方案；
高德地图在公交模块下只罗列了公交方案，在火车模块罗列了火车、高铁方案，并在客车模块罗列了客车方案；
从路线给出的方案来看高德地图给的方案类型更丰富，那么更丰富一定就是更好吗？
相邻市的出行，或者说同一个省的出行，用户选择最多的方式应该就是自驾、客车出行了，首先客车符合到站买票，买了等个十几分钟就可以上车走了，不需要提前买票，提前候车，相比于火车和高铁来说省了很多上车前的准备时间。同时客车可以到的城市或者终点选择更多，而对于一些小站，火车的车次和覆盖范围都远远达不到。
因此在这里，客车方案是非常重要的，但是展示形式上，不建议采用三个模块进行展示。公交，火车，客车列在同一个模块可以方便用户做横向的比较，选择更适合自己的出行方案。
而对于远距离的跨市搜索，高德地图的公交模块和火车模块显示方案、信息都相同，因此从这个角度看，火车模块单独列出来其实是比较多余的，具体的原因和分析在系列一中分析过。
3. 除此之外我要说的
还记得在叫车模块，高德地图对于这种跨市的路线搜索给的显示结果是，不支持扩区域叫车。
但是在公家方案，却在页面底端显示了叫车前往的按钮，点击后会自动跳转到叫车模块，然后叫车模块显示的内容又是不支持扩区域叫车，这里我只想微笑脸。
给用户一个叫车的按钮，那么就应该考虑到，用户点击后他的心里预期是能成功打到车，但是用户点击后，得到的回应和心里预期不一样，这块会让用户感到疑惑，怀疑是不是自己操作失误，可能会导致用户接下来不敢这么随心所欲的使用你的产品了。
让你的每个功能都恰好回应了用户的期望甚至超越了他的期望，给他惊喜而不是惊吓。
步行&骑行模块模块
近距离跨城市：都会给出路线规划，同时提示用户路程较远，不建议采用步行出行的提示，且都有单车入口。
远距离跨城市：不管是步行、骑行都知会显示路程，建议采用其他方式出行。
小结
系列一和系列二从距离上对导航产品做了区分，分别对他们的展示模块和路线规划方案以及显示信息做了分析。
超越期望：可以看出，虽然二者的用户使用场景有部分重叠，但是不同场景下用户所期望得到的回应是有区别的，我们在做产品的每个功能的时候，都应该站在用户当前的使用场景下，去分析用户为什么要这么做，以及用户期望得到的心里预期是什么，我们可不可以比用户想的更多，去超越他的期望。比如用户搜索公交线路，我们除了呈现路线信息外是不是提供个共享单车入口。
做减法：产品到了后期往往会出现功能堆叠的情况，我们不妨试着拿到一个模块，想想一下去掉这个模块，用户的正常使用能不能完成，有没有什么其他的可以替代的方式，去掉后会影响多少用户的使用，甚至可以去做A/B测试进行验证。
到此，导航类产品的分析就全部结束了，如果有任何问题，希望各位不吝赐教。
从生活的每个点滴，从自己觉得不爽的每个时刻，去进一步分析，发掘产品的魅力和缺点，让世界更美好，让产品更懂人心。
