Roadmap不在乎用什么工具来描绘，可以用PPT、Xmind等工具，但是它脱离不了以下这些核心的要素，通过这些核心要素按一定逻辑组合起来，呈现出的就是Roadmap的样子。

目标

给你这张蓝图定一个一句话的目标，这句目标能完美的概括出这张蓝图的重点。比如C端O2O产品目标叫“围绕多、快、好、省来打造极致的用户在线交易及服务体验”；再比如B端CRM产品目标叫“建设客户全生命周期移动化、数字化管理平台”。让别人首先看到这句目标，就能快速的了解到这张蓝图的核心宗旨和愿景。

横轴-完整用户体验路径

大多数Roadmap的横轴都是用时间轴来呈现，但是我更偏向于用用户体验路径来当横轴。
两者优劣点如下，大家可根据自己实际情况进行选择。
横轴-时间

• 优点：突出时间维度，能通盘清晰的看出每个时间段该做什么事
• 缺点：没有用户视角，缺乏横向逻辑性，比较难理解

横轴-用户体验路径

• 优点：站在用户视角，有横向逻辑性能串联整张Roadmap
• 缺点：不能通盘看到各个时间段该做什么事

将这款产品以用户体验路径拆解成几个阶段，再基于每个阶段识别出用户的核心动作，这样就形成横轴的用户体验路径。比如打车业务，可以分成上车前、车上、下车后3个阶段，每个阶段动作如下：

• 上车前，提交行程、等待接单、等待司机到达
• 车上，乘车
• 下车后，支付、评价、开票、投诉

将用户体验的关键阶段和动作识别出来，并基于此进行绘制每个阶段和动作场景下的Roadmap，这样就是一幅完美的Roadmap。

纵轴-单个用户场景的蓝图

1、用户行为

用户行为主要是为了细化用户体验的关键阶段和动作。将动作拆解到具体的用户行为上。比如上车前的提交行程是一个动作，具体的用户行为是下载&打开App、注册&登录、填写行程（上车点、终点、用车时间等），然后才是提交行程。将这个动作下的用户行为进行拆解，一方面可以更加清晰的了解完整的用户行为，另一方面Roadmap也能细化到每个用户行为上。

通常可以根据“影响转化率”这个维度来拆解动作下的用户行为，比如影响提交行程的转化率有以下用户行为：

下载&打开滴滴出行App>注册&登录>选择出行服务>输入上车点>输入终点>确认用车时间>选择车型，然后完成订单提交

再将相同节点完成的用户行为进行合并，最终提交行程下的用户行为就是：下载&打开App、注册&登录、填写行程。

2、接触点

接触点主要指用户在上述动作过程中通过什么方式接触到什么样的人。这里的接触点可以分成2类：

• 系统接触点：指用户在上述动作接触到哪些系统的哪些核心功能
• 人员接触点：指用户在上述动作接触到哪些人员

比如等待司机这个动作下，

• 系统接触点：等待司机页（查看司机预计达到时间、车牌号等信息）
• 人员接触点：司机联系我、我联系客服

梳理关键阶段和动作下的接触点，是为了更好的了解到现有的功能支撑度和人员接触点。以系统和人员接触点为基础，构建对应动作下的Roadmap，最终提高该动作下的用户体验和转化率等目标。

3、用户蓝图

用户蓝图这个环节是Roadmap的核心环节，应该要包含以下要素：

• 蓝图内容：

基于该动作下的用户痛点，输出对应的蓝图内容（即产品解决方案），可以是一条也可以是多条。输出的内容要能描述出该动作下“产品成功是长什么样的”。是站在用户视角下，该动作成功的样子。比如提交行程，对于用户来说，成功的样子就是要能快速提交行程，按用户行为可以拆解成3条蓝图内容：a、下载&打开要快；b、注册&登录要快；c、提交行程要快。

• 计划完成时间：

有了每条蓝图内容，就要明确好在什么时间点能够完成上线。因为Roadmap通常是按年输出，所以计划完成时间精确到月份即可。评估计划完成时间，需要考虑到蓝图内容难易程度、实现成本、难易程度、人力成本，以及过程中涉及到的产品调研、输出方案、开发测试等环节总耗时情况，最终输出对应的计划完成时间，而不是拍脑袋写个时间点。

• 重要程度：

将对应的蓝图内容按痛点程度进行拆解，通常越痛的重要程度越高。这就需要提前洞察用户痛点和识别痛点程度，基于此再进行重要程度标注。所以在描绘Roadmap之前，需先完成用户和业务调研，提前洞察用户所有痛点和痛点程度。

4、衡量标准

蓝图内容描绘的是“产品成功是长什么样的”，但是成没成功？成功到什么阶段？这些没法得知，所以需要一把”尺子“来衡量成功的标准。可以从定性和定量的两个维度，结合起来制定这把“尺子”。

• 定性标准：指不能直接量化而需通过其他途径实现量化的评估指标。比如将实现过程进行初步分级。
• 定量标准：可以准确数量定义、精确衡量并能设定绩效目标的考核指标。定量也是针对过程，和定性的区别是要有明确的数值。

比如转化率从10%->30%，10%指现状，30%指成功的标准。所以制定定量标准的时候，需要先计算当前标准，并且基于现状&未来蓝图，预测出成功的标准，这个预测标准要有依据，经得起推敲，而不是拍脑袋定的。

5、业务支撑

要完成蓝图内容，达到成功的样子，除了要有产品解决方案，还需要哪些业务支撑方案。即哪些业务部门需要参与哪些产品解决方案，便于更好的完成蓝图。不管是C端产品还是B端产品，要想实现蓝图内容，过程中都离不开业务部门进行支撑，比如前期一起制定业务规则、中期验收试点，后期上线推广，产品解决方案仅仅是蓝图的样子，如何将蓝图内容落地依赖业务支撑。

6、系统支撑

除了需要业务支撑，还少不了系统支撑。一个完整的C端App离开一套强大的后端系统支撑。B端的系统同样需要相关领域的系统支撑。主要以业务场景相关的领域系统支撑为主，故障监控、数据分析等增值系统支撑为辅。