当需要根据后台的内容改造C端前台的时候

一、首先要对生产课程和提供服务的各个系统都要了然于胸，对于后台系统的工作方式也要了然于胸，

    至于是否要将细节了解清楚，根据时间情况来确定

二、当知道了后台系统都能够生产什么东西，以及其细节之后，接下来就可以进入改造阶段了

三、步骤：

      【1】产出信息或功能架构

             原则_1    明确要对什么做划分   

             原则_2   使用业务和学员两把显微镜去看旧有的功能点，不要轻易相信现在的假象     

             原则_3   先认为一切都是能够使用一套规则的，实在不行再退步求分离

             ①   要对什么信息或者功能做架构呢？这个不同的产品一定是不一样的，需要根据自己对产品的理解来想：要对什么做划分？要对什么做分类？知道了哪些结构之后就可以将网站支撑起来了

                   比如：确定了要对【主线课程】与【课程服务】做架构；【主线课程】要描述清楚其层级结构，【课程服务】要描述清楚商品级别的服务和班内服务

             ②   上一步确定了必要的架构之后， 需要知道为了搭建这个架构，都有哪些分散的功能点，所以就去收集功能点，收集功能点的时候一定是会有一些分类，不同类型的商品，来自不同生产

                   平台的商品，具有不同服务类型的商品等等，开始的时候这些分散的功能会有各种相互交叉的分类，但是不要被这些分类给左右，你知道继续列功能点，虽然不被分类左右，但是你必须

                   这些功能点不同维度的分类，不论是记在脑子里还是写下来，因为这会为重新分类提供更多地信息

             ③   功能点列出来之后，还不能进行架构的重新划分，为什么？因为这里还涉及到一个问题：功能点都是旧有平台里的功能点，那么问题来了：这个功能这么设置合理不合理？

                   比如：7E中商品的层级那么多是合理的吗？如果不合理，应该是什么样的？

                            课程生产系统中的讲义那么挂载合理吗？如果不合理，应该是什么样的？

                   你要回答这样的问题看起来简单，因为你可能只是像这样：层级太多，但是不同商品层级有各不一样，我改不了；表面上看挂载在章节内部的讲义和资源是有道理的，道理是：你看有的讲义要针对

                   章吧，有的讲义要针对小节吧，所以这个没办法，就还像原来这样就好了

                   但是这就错了，因为你之所以这么去回答，因为你太表面了，第一个问题的答案你的基础是【我不知道课程的内容，我不知道课程实际是不是应该这样设计，所以我认为那些老师比我内行，

                   他们那么设计是合理的】；第二个问题的答案你的基础也是是【老师内行人，他们能在任意一个级别上挂讲义也是合理的】

 

                   如果你认为【老师是内行，我只要照做】，那么你就永远成不了内行。你的态度应该是【老师他们自己都不知道怎么创建课程，因为如果他们知道，为什么现在网站这么混乱】，你的任务应该是逐

                   一的去打开各种典型的课，打开讲义，看看典型商品的层级结构；你要像一个内行和学员角度去看：”这个商品为什么分这么多层级？这一级是有必要的吗？为什么别的商品都是现有班，再分科目，、

                   这个商品却先分科目在分班“，"奥，讲义里面全原来全是题啊，并不是像原来想的那样讲义都是知识啊！原来讲义是不可能挂载到各个层级的，只需要挂载第一级就好了"

 

                   另外一个问题是：我靠，商品太多了，我不可能把所有的商品都看一遍，可定不能找到一种适用于所有商品的层级结构，所以我想应该设计一个松散的，自由度非常高的设计方案

                   那么恭喜你，你又采坑了：一个产品你的规则越清楚，越简单，约统一，用户的认知感就会越强，如果这里、那里都不一样，就越不好，除非你把这个产品拆成不同的产品

                   基于这个原则，你应该先去找是否能够统一的可能性，这个过程是痛苦的，你要不断的想方案，不断的去问各个老师，如果顺利，你会发现其实真的大家都能够统一起来；那么那个问题怎么办？

                   商品太多，不能全部看完，很简单找出典型的商品，确保你找的这些商品能够代表大部分的商品，这个找项目部要一下，十分简单；好了又解决了

 

                   经过这样拿着显微镜去观察一遍的时候，你要做的就是下一步

 

              ④  将每个功能点的实际内容整理出来观察，得到这个功能点的内容和本质

              ⑤  在检查一遍各个功能点是否枚举清楚，是否枚举完毕 ，然后对各个功能点重新进行拆分与合并

                   原则1  功能点越固定越好，越松散就越差，下面这些都不行

                            这个需要老师自己去定义；这个老师自己随意发；这个这样也行，那样也行，适用的情况越多越好

                            尤其是最后那个：这个既可以挂载资料，也可以挂载讲义，也可以挂载习题，也可以挂载文章，好的，我就设计一个富文本就好

                            这就又采坑了，因为会发现从实际的业务上讲，从实际的内容上讲，根部就不能挂载文章，所以最后结论是：你就直接定义好，只能挂载知识点和习题，没有就不显示，别的不支持

                   原则2  新的功能点或者模块的具体内容和逻辑定义要十分清楚，并且把示例写好，要保证交互知道怎么画，下面这些都不行

                            资料就是富文本就好，信息流里面有课程提醒，有晨间计划，但是晨间计划的具有的时间属性，是否是资料，这些放到这个架构里面是否合适，都要想清楚

 

              ⑥  完成架构的重新设计

                   注意这只是网站主要的功能架构，还有许多的其他新的功能，旧的功能，要不断的想想架构、不同模块之间是如何作用的，如果你是一个纠结于前端页面展示的人，那么告诉你，你起码要想到

                   一种能够说服自己的展示方法，在逻辑上能够讲得通的展现方式，否则你会停滞不前，因为这距离最后还有很远

        【2】 准确清晰的描述每一个功能点

                 因为已经有了上面第⑤点，所以这一步顺理成章

                 原则1  功能点越固定越好，越松散就越差   

                 原则2  新的功能点或者模块的具体内容和逻辑定义要十分清楚，并且把示例写好，标准就是保证交互设计师知道怎么画