旅行的计划与记录

今年春节，我去柬埔寨旅行，杭州→暹粒→西哈努克市→金边→杭州，是11天还是13天来着？我已经忘了。

旅行回来，开始动心思设计一款针对“长途旅行”的产品，主题是“旅行的计划与记录”，以APP为主，网站为辅。简单来说，它能帮助我做一份更好的旅行计划，以及在旅途中轻松记录一路见闻。你看，时隔半年，我连去柬埔寨玩了多少天，甚至去过哪些景点都记不清了。可我一辈子或许就去一次柬埔寨，吴哥寺啊。

想记下来一生中所有重要的事情。

最近发现一个9月才上线的新产品，据说是创新工场投资的“途客圈(tukeq.com)”，出发点和我的很接近。兴致勃勃地去体验了一把，又有点失望。产品UI很赞，但易用性差。当然易用性这点不是大问题，交互改进不难，难的是如何处理三个根本问题。

第一，怎么解决UGC产品冷启动的问题？如果是来途客圈查资料，作为最大卖点的景点资料库，浏览体验过于琐碎与清冷（且信息过载），赶不上穷游、蚂蜂窝这些老牌社区生动的内容积累。如果来制定旅行计划呢……我为什么非要来你这里制定并打印计划？仅仅加入地图标记与景点资料，这动力还不够充足。

第二，怎么解决经历分享的问题？在制定计划方面途客圈还算颇有特色，但旅行结束之后，为什么我还要回到网站来，根据旅行计划补充自己的沿途见闻？绝大部分人不写游记仅仅是因为“懒”，而不是不方便什么的。即便有着写游记的热情，往往也希望发表在自己最熟悉的社区。如果缺乏旅行经历的沉淀，产品就极为干瘪而无趣了。

第三，怎么解决旅行记录的问题？上一条提到过很难吸引用户在旅行结束后撰写游记，因此最好的处理方法，就是引导他在旅行的过程中进行记录。这一点并非不可行——但别人凭什么把旅行记录即时发到途客圈呢？他更愿意发去微博或人人这些熟人众多，且响应敏捷的圈子。这个问题在蚂蜂窝即将推出的移动嗡嗡身上同样存在。

以上三点都属于产品的架构瓶颈，具体的产品设计上也还有三项不足。

1、游记在旅行计划的基础上添加内容，这不符合用户写游记的习惯，用起来很别手。更像是交报告，证明鄙人曾到此一游。大大削弱了用户留下游记的意愿与质量。

2、制定计划时不能自定义景点，也不方便挑选景点，非得先收藏数据库里的预设景点，再列入旅行计划，流程很不友好。再说你数据库里没我想去的景点，肿么办？或者我的景点划分方式和你不一样，肿么办？产品使用的弹性不佳。

3、产品减法做得不够，作为一款新产品，人有我有的冗余功能不少，使得重点还不够突出，尤其是产品的核心卖点不带感，不抢眼。把开发杂七杂八功能的精力挪去主线上多好——当然，这得看对“主线”的阶段性定义。

产品设计终归是可以不断改良的，但架构上的短板并不能通过技术来解决。我很欣赏途客圈从“编辑旅行计划”入手，这个突破口与我的设想完全一致，但他们暂时还没拿出一套解决方案来，处理好冷启动、旅行记录与经历分享的问题。

说说我的思路，当然，只是其中可以公开讲的一小部分。

首先，我认为从头做一款旅行产品，最好是工具化的，帮助你制定更好的计划，帮助你更灵活地调整计划，帮助你更轻松愉快地进行旅行记录与分享。必须强调这款产品的工具特长——如同Instagram以高品质滤镜起家。用户是为了方便自己旅行，而不是为了“分享精神”来使用产品，但他在使用过程中会自然而然地产生有价值的信息沉淀。

其次，传统游记过于拉杂，也良莠不齐，撰写成本还很高，用户从中获取实用信息的效率又比较低。因此将结构化的，实时更新的景点数据（以UGC为主），用行程计划的方式串起来，对旅行者的帮助更大。这点上我与途客圈的理念完全一致，不过，设计手法就截然不同。

最后，我更倾向于“旅行实时社区”这个概念。即弱化网页端的社区培育，鼓励在同一个地区旅行的人通过APP进行交流，主要是拼车、拼团、相互咨询等等，将实用性作为贯穿始终的产品气场。有用时拿起，没用就放下。感性的内容分享与互动仍归属于用户常去的其他社区，这是抢不过来的，索性洒脱放手。

这样一款产品，APP与网页的比重大约是2比1。核心价值在于通过UGC的方式，沉淀下来大量结构化的实时旅行资料，为长途旅行者带来帮助。而用户必然是快速流动的，所谓“社区”也是随着旅行热点而动态生成的。至于盈利模式嘛……悲剧，老子对钱一贯的不敏感。但创造不菲用户价值的产品，终归能找到自己的钱景，对不对？

希望我的一整套创新解决方案，能有机会冲开刚才提到的三点瓶颈。这款产品打算自己组队做，后端/视觉/运营都能找到可信赖的同伴，现在还缺一位经验丰富的iOS客户端工程师（全职）。有缘千里来相会。