从信息架构谈起—更好地理解产品策划

精华速读：

随着互联网的来袭，策划者们总是在绞尽脑汁得做着各种优质的产品。然而总是避免不各种问题，本期主要谈谈一个一个互联网产品涉及的几大层面：

一、信息架构：从需求方入手，抓住核心主干，满足需求方的目的；

二、产品结构：从产品元素、数据类型、表结构清晰定义产品整体逻辑；

三、布局规划：从整体角度进行模块划分，始终考虑产品扩展性；

四、视觉分析：第一印象，符合大众化的感官，做出合理的设计风格。

让我们一起探索产品策划的本质，解决实际的问题！

长文：

互联网浪潮已有20余年，人们已经过渡了web、app、硬件层面，未来的形态可能会越来越多。抛开应用形态来讲，所有的产品本质上都一样：如何更好得服务大众化。就像人们所看到的那样，在现实与网络世界的结合中，人们总是在尝试接受新的事物，探索新的刺激，从某种意义上讲，这些事物会具体到某件产品上面，无论它是否可触摸的，所带来的服务已经记录在大众的思考中。

一件衣服，一支笔，一款应用，一台硬件设备等等都会被称为产品。事实已经证明夸大的说法与吸引大众化的言辞并非能真正让用户喜欢它，这只是短时间的，产品的好坏会决定大众对它的持久耐性。本章只想从互联网角度谈谈产品的诞生，传统行业也会有借鉴的地方。

一个好的idea，一个好的执行力，似乎已经是互联网产品最初的雏形。然而，随着产品的快速发展，必然会走向规范的流程，也许这会局限某些思维，事实上，也的确存在这种情况。但不可否认的是，业务规范性至少不会出现大层次的错误。做为产品人，也许写写文档，画画原型，做好协调就能完成产品的正常部署节奏，这始终是理想阶段的层面，在实际的业务流程中，总会遇到各种各样的问题。从产品设计的角度，该用怎样的思维方式与表现更好达到产品规范呢？还是从四个维度谈起：信息架构、产品结构、布局规划、视觉分析。

信息架构篇：说起信息架构，似乎更偏向于工程层面上。实际上，对于一款产品而言，信息架构是综合各种因素考虑的结果，并非一个简单的idea就可形成。对应实际的场景便是需求方、实现程度、后期扩展等层面。经常会遇到棘手的问题，可能在某次评审会上，可能在策划中，被各种业务逻辑搞得繁杂，这样从信息架构就可很好得梳理思路与后续发展。

对于产品策划人士而言，落到实地的更多其实是需求，这也是产品的根基，怎么解决，如何解决，存在的问题等一系列的因素。首先得明确一点，产品一定是有需求方的，无论在大小公司还是自己单干，你的需求方就是产品要解决的问题。需求方总是来自于很多方面，比如运营人员、商务人员、boss、资本方、用户等等，当然，也可能来自于产品策划者本身。

面对如此复杂的需求方，的确会有写混乱。遇到这种问题，有个好的处理方式，即列出所有需求的根源，需求方要达到的目的，实现的效果等。但主线却是唯一的，即产品策划负责本身，最终的产品形态只会体现出各个需求方的元素，但很大程度上，他们未必是一级需求。主线不能乱，特别是在复合型的环境下，如果没有主题枝干，那么会因为需求方的各种压力而使得产品拥挤。比如运营要加活动入口，商务要加广告入口，技术构建框架等，那么在产品形态中用一些元素体现出来即可，如焦点图，web扩展等，随着需求的不一致，表现的形式也是多样化，总之始终有策略性的方式来解决，但表现方式从主观上不会影响主线，即给用户带来的服务。很多时候策划者会一直遇到取舍问题，一般来讲，每一次迭代与扩展突出的重点会很精益，只需要理出主干，同时在表现形式上满足于需求方的目的即可。实际过程中，需求方提的需求很多，把确定做的需求列出来，再进行策略上的改变，这也是从信息架构考虑的目的。

总之，信息架构的出发点是抓住主干，同时考虑好需求方的实现形态，无论产品经过怎样的扩展，都能很好的解决，本策略一定是在需求明确的情况下。

产品架构篇：与信息架构不同，产品结构是非常实际的东西，具体到产品的整体形态，无论是研发还是设计都能实际运用的东西。在搭建结构的过程中，实际上将每个需求体现的要素都具体化。好比一颗大树一样，枝干、叶子、树干等，每个模块都将元素具体化。从根本上来将，常常所说的需求侧露等问题往往由于细节性的元素没有很好的连贯性。

对于策划者而言，每个产品的模块划分、具体页面体现的元素都是产品架构最根本的问题。将产品架构放在布局之前也是有原因的，首先需要梳理好各个元素直接的关系，才能进行整体的布局。无论是web还是app，每个页面体现的元素将取决于整体的结构划分。如果一上来就做整体性的工作，比如直接做原型，出策划方案，很出现很多问题，因为总有考虑不周全的地方。拿社交类的产品举例，用户昵称、性别、头像、签名等都是产品结构的元素，正是由于这些细小的元素，才最终为整体体系搭建好基本工作。初期这项工作可能会很繁琐，

但其作用是很明显的，最透彻的问题在于考虑不周全，遇到实际的开发流程，则出现需求遗漏，策划者本身就要对细节性的东西负责，一开始花时间做结构是有必要的。无论输出的结果面向谁，至少不会存在元素混乱等现象。对于研发人员来讲，知道每个模块的元素，能够更好的建表，知道各个业务的元素关系，则更好的整合数据库，包括对字段等细节的处理；

对于设计人员来讲，模块的元素的量化将影响整体的设计思路，在后期的协调当中，设计与技术的对接对于需求更容易明确，无论是切图还是数据类型的展现，都是关键点。

总之，产品结构更多体现在产品的元素整合上，每个页面，每个模块体现哪些数据类型，哪些用户要素，都能很好得处理。从整体开发而言，业务流程的负责人会对本身的需求体现更容易理解，这始终是件有益的事。

布局规划篇：当产品的要素形成具体量化后，则需要从整体角度考虑产品布局。本流程会对具体的产品形态进行定义。按理来讲布局将划分到产品结构上，之所以单独拿出来，是为了理顺业务逻辑，方便后期更好得扩展产品。举个例子，在前期策划，如果仅考虑功能实现，也许该周期能够很好得完成，但不会利于产品扩展，一旦设计模块布局页面等的改动，可能就牵扯逻辑，从研发角度看，这可能是非常影响进度的事情。

建议从一开始布局就合理化，不仅适用于目前的需求展现，也适应于后期的扩展。一旦遇到需求增加等问题，总能很好的解决。近两年，无论是web还是app开发，都出现一种较为规范的形式，就是在前期就将布局搭建的很合理，后期的扩展增加模块只会增添新的功能与子模块，不会对整体样式进行大的调整。当然也存在问题，就是前期的版本从模块划分看来，显示得很空，但由于快读迭代以及敏捷开发模式的出现，使得产品形态越来越完善。

从整个产品生命周期看来，布局的条理化也是大大提高了进程。从这时起，布局与操作流程就已经相互融合，毕竟所有的操作流程都是通过布局体现。

布局规划主要从扩展性以及合理化去考虑，也是产品具体的形态。基本上从本阶段开始，研发与设计人员已经处于交集中，保证整体的协调性。

视觉分析篇：从产品使用者角度看，视觉其实感官，印象层面的东西。也常常将“第一印象”作为产品的优良。大多数的使用者是没有耐心的，他们本身也看不到产品背后复杂的逻辑，当然，也无需看到。产品所有需求体系在视觉上都会形成相应的区域，对于使用者本身而已，只需要通过视觉层面快速理解产品的本质。

从最初的三维化，到扁平化，以及极简主义的视觉趋势，已经看到产品的使用者对产品的态度。在信息复杂化的今天，如果通过简单的设计来体现复杂的流程，更加艰难与重要，也是应了那句话：越简单的东西越复杂。基本上，产品的视觉层面由产品的基因基本决定，无论是色彩搭配还是元素设计体现，都会收到产品基因的影响，当然，这其实也符合规范的。对于设计人员而讲，风格往往是最难定义的，往往会看到做某个模块会大花大量时间，整个产品的视觉层面也较混乱，往往是因为最初的风格没有搭建好。简单来讲，产品的风格定格会极大减少设计层面的问题，风格便是整体的设计理念以及突出点。无论做怎样复杂的模块，可完全按照风格来走，无论是app还是web，产品在页面上也会保持统一性。该阶段主要由策划者与设计师共同参与完成。

总结

作为一名产品策划者，有必要从整体的角度去看产品的具体流程。理想化的策划方式在实际中总会遇到很多问题。面对技术、设计、领导层等各方持有问题，如果没有完整的产品思维，那么很难协调好对应的流程化问题。当然，没有最合理的方式，只有适合业务流程的方式，好的东西只能去借鉴，但具体怎么做需要看实际情况，总之探索与策略的实施是必要的。

By 张晓辉