1、产品类型
一直从事面向c端大众消费群体的产品设计与研究，c端产品更加倾向于用户体验和商业运营，产品逻辑未占据主导地位，体现的不是不明显。换句话讲，产品业务逻辑相对比较简单，比较容易理解和解决。
2、工作内容
核心工作集中在需求管理、产品设计、产品文档、技术追踪、测试上线等产品前端工作，未能设计到产品后台业务的科学规划设计。当然，这个要感谢之前精诚合作的技术团队的同事，你们才是“最可爱的人”。
这几年的产品工作，经历的很多，还是那句老话：非常感谢遇到的人和经历的事情！我觉得自己非常幸运，甚至说老天对我真的是疼爱有加。工作年限屈指可数，而主导/参与的产品还是蛮令人满意的。（有点小小的骄傲！）以产品形态为维度，大概包括：app（工具型、内容型）、web（应用型、内容型[财经社区]）、h5（应用、活动、微信）、cms（产品内容运营）。cms（内容管理系统）是心中的痛，苦于之前公司的产品策略倾向于前台产品，核心的技术资源和资金投入也自然向面向c端产品线倾斜。当然，产品处于初期成长阶段必然决定了重视用户体验、以用户为中心的产品策略；其实还有一个更加重要的因素——业务形态，后台业务需求集中在产品内容运营。
还记得，我之前写的《从一个项目实践说起，产品设计流程是什么样的》详细介绍了互联网产品设计流程，这套流程是普适的，可以应用到不同产品形态上。那么下面我就尝试着将这套流程应用到cms（内容管理系统）的产品设计上面：
note：内容管理系统的产品设计思路仅限于产品阶段的思维构思过程，不涉及跨部门的交互内容。
内容管理系统（cms）的产品构思流程
一个完整的内容管理系统（cms）的产品构思流程，大致可以概括为以下四个过程：需求管控、梳理流程、产品框架、迭代规划。
1、需求管控
理解需求是产品设计的第一步，如果说都没明白需求是什么，那么产品将只能摸着石头过河！不是危言耸听，而是切身体会。需求管理阶段，务必需要弄明白一下几个问题：
提出需求的背景是什么？需求解决了用户的什么问题？是不是用户真正想要的？解决该需求有什么直接/间接商业价值？需求背后的商业模式和运营方式？
搞清楚了这个几个问题，在随后的产品设计中才不会一味摸瞎前进，那种感觉很艰难、痛苦，甚至会给你带来莫大的麻烦——你所做的不是需求方想要的。我能想象，此刻有一种“想死的冲动”！需求管控是产品过程的核心环节，无论哪种产品类型都很关键、都需要付出更多感情和精力。更何况是“业务逻辑”主导的cms（内容管理系统）呢？
2、梳理流程
内容管理系统（cms）管理的是内容，而内容来源于哪里呢？用户生产内容和运营支持内容，如何理解呢？
c端注册用户，在网站上生产内容。业务性的产品核心就是实现业务流的运转，上下游实现资源的有效传递，最大化压缩成本，实现利益最大化。因此，ugc为cms内容管理的核心内容来源，也是业务驱动的产品的价值增长点。运营类型的内容网站，除了用户与后台的内容交互之外；产品本身也提供了必要的运营内容，这部分的资源也需要借助cms（内容管理系统）实现高效配置。业务交互性内容是产品前后台最主要的数据流，还有一部分自然数据，而这部分数据恰恰又是之后数据分析、经营性分析的基础。重视自然数据的长尾价值，积累用户行为数据，挖掘用户价值。
从形式上讲，产品越流程的梳理通常借助流程图可视化，流程图又包括：状态图、业务流程图、泳道图等具体的样式。业务流程能清晰地解构出，前后台的数据之间的交互。重点关注核心业务流程，梳理次要业务流程，分清主次，抓住主要矛盾。
流程图[状态图]：
3、框架设计
前面两个步骤基本解决了“做什么”的问题，接下来就是“怎么做“的问题。理解用户用户所需，明确产品业务的核心流程，接下来就是将需求和想法进一步的可视化，而这个环节将借助：功能导图、产品原型。更高维度的信息加工，将原本复杂的产品需求进一步精化为更为立体的功能结构框架，使其更具可行性和落地性。
功能导图：理解需求的基础上，抽象需求为立体的功能。需求分类、功能结构重组，搭建良好的产品信息架构（ia），行业性质浓厚的产品需要专业人员的介入，增加产品信息架构的专业度和行业边界。一眼看尽产品的宏观功能框架，对产品的每一次延展都了然于胸。产品原型：很多人都喜欢这一产品产物，甚至说很多人一上来就开始画原型，我觉得很糟糕、毫无意义。产品原型是对已经拥有明确思路和需求范围的产品构想的重现过程，是一个快速重现和迭代的过程，而不是思维的依赖。正如我之前说的，产品经理最重要的特质就是——思考。
产品框架示例：
4、迭代规划
产品框架设计本着从愿景的角度出发，确保产品本身的可扩展性、可性行的，方便产品的客气敏捷迭代。分期迭代或源于实际情况，亦或产品策略性调整，而问题的关键在于分期迭代的动机和目的。产品分期迭代升级的因素有很多，大致包括以下几个情况：
客观情况：技术资源紧缺、资金投入定量，必定在客观情况上限制了周期内的产品规模和体量。我想表达的并不是“没资源就不做了！”而是最大化资源利用率，推进产品创造可能。产品规划：产品发展角度来说，周期性的迭代升级有利于产品的良性进化循环。产品需求量大迫使产品不得不依据需求的紧迫程度规定优先级，在可落地上多做尝试、多做努力。
[产品版本规划]：
行文小结
这一瞬间，我似乎透彻地明白一个道理：学无止境！以怎样的方式才能洞悉世间万物呢？想必穷尽我一生的所愿都不可能实现呢… 可我还是心有不甘，尝试将自己所经历的每一个产品过程抽象为一个个具体的思维构思过程，从而让自己的身后的很多事情有一个可参考的依据和背书。以上就是我个人尝试搭建的cms（内容管理系统）的产品构思的思考过程，业务驱动的内容管理系统（cms）更加侧重业务流的处理，业务流程的产品逻辑重要性更加突出。
尝试着以一种科学的思维模式去构建一款cms（内容管理系统），需求管控、梳理流程、产品框架、迭代规划，每一步都值得付出更多努力和感情！与之前写的《从一个项目实践说起，产品设计流程是什么样的》相比较，内容管理系统（cms）的思维过程只是原有产品框架基础上的再改造，产品重心的适当调整，产品策略的场景性变化。
这也印证了一句话：每一次的努力，收获的却是全世界！
1.页面动态配置的前生今世
页面动态配置是cms系统（内容管理系统）的一部分，在电商行业，cms系统有时会局限用作页面动态配置的功能。有时也叫作“装修”，店铺装修、页面装修、自定义新页面。平台见到的首页管理和新建活动页面都属于此类范畴。
在pc电商时代，页面的自定义比作盖楼，添加一个楼层，每层可以自定义内容，譬如商品、优惠券、商品排名等。“淘宝旺铺“就是店铺装修发展出来的一门生意，淘宝店家可以选择基础模块的内容，编辑首页或新建页面，动态配置页面。
淘宝的店铺pc端自定义设置
在移动互联网时代，页面动态配置功能升级，可以自定义的要素越来越多，在页面布局上也更为灵活。可以选择添加icon、banner、商品等模块。
京东的手机装修页面
2.配置的产品逻辑
可以把页面的动态配置比作乐高玩具，每一个组件就像乐高积木，可以用它搭建不同的乐高玩具，就类似组装成不同的动态页面。我将页面的动态配置分为3步：组件→ 位置+内容 → 动态页面，如下图。
页面动态配置
2.1 基础组件
组件是动态页面的基础，提供给用户编辑具体展示的信息。有许多类型的组件：图片轮播、icon、优惠券等，每种组件都可以有多个不同的样式，选择内部展示的内容或者自定义。用的最常见的就是链接，组件显示样式虽然多样，但是点击之后通往的页面选择库却是共通的。例如：新的活动页面、商品详情页、商品聚合页、购物车、客服等等。
基础组件的定义和解析是自定义页面的核心，不同的组件有不同的功能，表示不同类型的内容。每个组件都需要单独设计，定义其规则和样式。 例如icon、图片轮播就是简单的图片展示，商品排名对应的算法较为复杂，需要实时去取动态排名。
2.2 位置+内容
有了组件之后，用户在设置或者系统在解析的时候，首先要确定组件在自定义页面中的位置。位置可以称为“楼层”，每个页面的各楼层可以定义名称、设置背景、配置内容，目前最主流的交互是拖动组件到相应的位置，设置内容之后实时预览，自定义页面动态可视化。
2.3 动态页面
对于整个动态页面，需要定义生效时间、结束时间、活动页面名称等基础信息。设置之后可生成相应的链接进行预览。
动态页面是由不同的组件内容构成，首先按照各组件位置去解析，然后再去解析组件的内容（样式、图片/商品、背景、链接等）。按照上图的反向流程走，就能解析出对应的自定义页面内容。
首页设置也是相同，类似自定义页面，可动态设置首页内容，动态添加自定义组件。目前绝大部分电商首页都是动态配置，有着丰富的自定义内容。
3.常用的配置组件
配置组件有许多种，常见的图片轮播、 商品推荐、商品分类、 宝贝排行、图标（icon）这几种形式，其实是富文本、 客服、优惠券、满减活动、满赠活动、自定义区域、商品搜索、文字、公告、倒计时、tab组件（顶部、底部）。
丰富的自定义组件可以实现各式各样的活动页面，前面举例的京东、淘宝活动页都是通过cms配置实现。
至于不同的组件设计和功能，下篇再详细讲解。
4.可自定义的一些要素
组件之间有些通用的自定义要素:
背景颜色/图片;组件之间的空隙;对应链接。点击组件对应的跳转页面，这些都是通用的：其他活动页、商品详情、商品聚合页、店铺主页、购物车、在线客服、积分商城、购物券、外链等等。
页面动态配置的整体产品逻辑基本已经介绍完毕，可以了解到，页面动态配置看似复杂，理顺之后发现其实就分为三个步骤，绝大部分的复杂度增加只是基础配置组件的丰富。
虽然cms系统产品逻辑简单，但是页面要做到较高的自定义配置程度，需要技术框架的高效率和较强的可扩展性。在浏览一个自定义页面时，系统要逐步去解析该页面下的自定义组件内容和要素，运算量很大。
目前绝大部门电商公司的自定义页面仅仅停留在一个初级阶段，限于首页和少数特殊页面的自定义配置，而且自定义程度较低。本文提供了cms系统的产品设计思路，落到实际项目中，还需要权衡实际需求和自定义配置程度之间的关系。
如果想了解详细描述各组件的功能，一直到组装之后的解析，可关注我，下篇将重点讲解。
来源：pm28