The bigger the data，the better the product！
从事B端产品以来，更习惯通过产品原型、PPT这类可视化的方式表达思路与看法，但是很少认真码字，希望能从这篇大数据产品设计的文章开始，逐步记录下来，文字的部分，也会时刻保持迭代，直到行文足够通常为止。
这篇文章适用于从事B端产品策划，或对平台型产品设计感兴趣的同学。本文以大数据产品设计为例，关注工具型平台建设流程与设计技巧。关于数据可视化、运营数据分析的经验与心得，后续可继续分享。
大数据产品概览
消除认知Gap
提到“数据产品”，大部分同学，可能首先会想到统计分析、报表工具、商业BI这类经常用到的产品形态，这也是产品、运营等岗位跟数据打交道的常见场景。那么，需要先消除一下这里的认知Gap，按照用途定位，可归纳以下两个方向：
一、数据生产：在庞大的“数据冰山”下，还需要依赖一系列的数据接入、存储、处理流程，将已有数据源中的数据进行收集和存储，在这基础上从事分析和应用，形成我们的产品和服务。在这个过程中，继续产生新的数据，从而循环进入整个生态流程中，整个过程，可以是全部智能化、自动化的。
二、数据应用：依赖数据生产的结果，我们可以应用于精准定制、预测方向。“精准定制”可以是一系列个性化的产品，辅助业务进行精准营销，例如效果广告。“预测”则是围绕目标对象，基于过去、未来的相关因素和数据分析，做出预警或实时动态优化，可为用户提供决策与支持，例如商业智能BI产品。“风险预警”，更多用于金融、银行系统中，做风控。
广义来看，数据产品是可以发挥数据价值去辅助用户更优的做决策（甚至行动）的一种产品形式。它在用户的决策和行动过程中，可以充当信息的分析展示者和价值的使能者。从这个角度讲，搜索引擎、个性化推荐引擎显然也是数据产品，由于产品形态已经比较成熟，所以很少被人划分到数据产品的概念里，另外，这类产品往往大都在数据外层做了包装，使非专业的用户并不能直观的感受到数据的存在。
大数据产品全景图
海外有机构，每年都会输出一张“大数据行业产品全景图”，以下是2016年的版本，在每个细分领域下，都已经有了若干家代表企业或产品：
产品经理面临的挑战
图中的这些产品，更多被业内归纳为“工具型平台产品”，对产品经理来说，“就像时刻处于人文与技术的人字路口”，在理解复杂技术、业务场景的同时，不断带来更具人性的产品体验。与此同时，更要面对一系列的挑战：
•竞品信息匮乏，体验成本高；
•项目团队构成复杂，涉及大量跨团队合作，并且项目排期常常很紧凑；
•业务逻辑复杂，技术专业性强，产品经理自身并非受众；
平台型产品设计流程与心得
万事开头难，在规划平台型产品的时候，更需要全局视角去分析业务，根据战略需要，推动流程系统化，释放重复建设资源。同时，通过合理的规划与设计，提升工作效率，实现用户与企业价值双赢。
下图就是一个数据产品从0到1的主要流程与设计原则，接下来会就红字的部分，逐个分享。
一、技术理解力
所谓的技术理解力，是指沟通、需求、及项目推进时，思考方式与技术人员保持基本同步。
1.参加技术人员的概要设计评审：当产品需求提到技术层面时，一般技术人员会对需求进行概要设计、评审、详细设计及评审、开发实施等环节。当然产品经理一般不会在技术层面介入太深，但为了尽量使需求不偏离目标，参加技术层面的概要设计评审，是很好的一个选择，虽然对于多数产品经理而言，不一定能全听懂技术在概要设计层面的讨论。参加概要设计评审可以了解需求在启动技术设计时，涉及到的相关系统、干系人、内外部团队等，大致了解技术实施层面的困难、瓶颈和资源需求。以减少用户类型、路径等环节的偏差。
2.提前向技术同步产品的远期愿景：同步产品愿景和长期版本目标，可以是在需求刚出现时，也可以是在交互设计时，但个人感觉最晚不能晚于技术的概要设计。提前同步产品愿景，可以在技术人员做技术设计时，能确定数据、架构、迭代以及预留字段，更能确定技术实现方式，是按照较大的系统实施，还是按照简单的逻辑实施，因为很多时候，技术的实现方式有多种选择。以免产品的期望是宏伟大厦，因为没有提前同步给技术，导致技术在打地基时，按照普通的平房实施了。
3.了解需求中的关键点：这一点需要在每一次技术沟通中进行确认，但尽量在技术概要设计前了解清楚，这也就是参加技术概要设计评审的重要性所在。了解需求的关键点，了解了相关困难、瓶颈、资源需求等，对于需求实施的排期、时间节点评估则会掌握的比较清晰。
二、业务场景驱动
如果就着需求文档，“用树形导航将需求逐个罗列”，那么，这种形态的输出仅仅能算作“功能平台”，还不能构成产品。“用户视角”是产品设计环节中最必要的部分：
1.找准目标用户：明确用户群体特征，可以通过“用户画像”的方式，描绘这类用户的常规属性、兴趣特征，通过这些属性组合，从而判断出用户行为倾向；如，在大数据产品中，最常见的，就是为数据开发者提供方便的大数据处理工具，无需通过重复的coding，即选即用。
2.发掘场景：每个用户故事，都只在固定的场景下产生，产品经理需要在初期，理清楚场景发生的条件与契机；
3.编写用例：把恰当的“用户”放到恰当的“场景”中，就像电影一样，用分镜的方式将每个功能点逐个模拟、演练，最终用流程图或低保真原型的方式，将用例逐个还原、呈现。这对B端产品设计来说，非常关键，在演练过程中，方便发现遗漏的边界节点，可以随时补充完善。
��三、流程管理-化繁为简
我们设计的不单是页面，而是“流线”，即“功能流程”或“页面访问路径”。
试想一下，泉水在山溪中流动着，穿过岩石、在陡峭出激流勇进，也能在宽阔出从容缓行，最终水到渠成，顺利到达山脚，汇入江河湖川。
•挑战：海量功能、大量模块、错综复杂的交互流程、难以理解的业务技术背景，都对产品构成挑战。
•前提：收集充分的信息，整理任务流，确定重点和逻辑。先构思，后出稿
•使命：用户可以用最短的路径完成任务，减少疑问与歧义。
推荐阅读
《餐巾纸的背面》
《互联网产品设计》
《时空》（KK三部曲）
参考信息：
1.知乎/老读悟 https://www.zhihu.com/question/19679589/answer/90363633
2.http://mattturck.com/2016/02/01/big-data-landscape/
3.简书/赵澈，http://www.jianshu.com/p/f448d0de51bf
