点击『小生知道』关注我
我会分享一些我的产品、设计、开发经验给你
这一节核心是如何画原型，当然，工具怎么用我就不说了，这个得写个老长的教程，而且每个人用的工具不一样。
工具方面：后台我一般用Axure、前端用Sketch。
画原型，其实分两步：
第一步：功能划分 ，一个业务到底要几个分几个模块，每个模块承载什么功能。
第二部：画图，划分好模块之后，用图形把功能、页面表现出来。
而标题的『降低耦合性』、『组件化』 正好对应上面两步。
降低耦合性 - 功能划分
后台产品之间的功能，经常会出现，A业务操作了，B的数据也发生变化的情况。这种情况无法完全避免，但是一定要做干扰最小，至少你要能感知到这个数据的变化。
举个例子：学校的课表安排，一次性安排一整个学期的课表，得到课表安排结果 A 。正常流程应该是：安排好之后，学校就根据课表上课即可。
但是，节假日课程调整、老师调休假、校园活动等等情况的存在，导致很多课在学期进行中，势必会造成课程的调整。
所有老师的课程安排都继承于课表 A ，如果这个时候要加课表调整功能，最普通的做法就是做一个功能，可以调整课表 A。
再但是，我个人并不推荐这么做，因为这么调整直接破坏了原始数据。虽然看起来没太大影响，但是功能是辅助完成业务场景下的任务的。
回头我要查初始数据怎么办?
PS：不涉及业务处理，是特定场景下的需要
所以，在课表 A 生成后，所有老师通过课表 A 复制一份数据形成『教师-课表B1』、『教师-课表B2』·····数据独立是一部分，然后就是功能独立。
『单个老师的课表调整』这个功能应该和『课表安排』这个功能分开，放在另外一个『页面』下面去。我个人做产品的有一个原则『一个场景下尽量只解决一个类型的问题。』（功能单一原则）
有的时候，耦合性还出现另一个场景，通过 业务 X 操作的数据和业务 Y 操作的数据重叠了，然后系统也不知道该优先处理哪一个，或者说，X 业务处理完之后，Y的数据已经不是原来的那个了。
比如：学校有一间『多媒体教室A-01』，张老师『星期一1-2节』有课在『A-01教室』上，但是由于当天有事，就想申请调整到『星期二3-4节』上。然后李老师因为班级活动『星期二3-4节』要申请多媒体教室，就申请了『A-01教室』。
由于张老师的课还没审核通过，所以数据没有变更，然后李老师也可以申请。等到张老师通过了之后，李老师也通过了，系统就对『A-01教室』星期二上午3-4课做了两次数据处理，结果就是，最后李老师的课安排上了，张老师的课，没了。
具体怎么处理我就不说了，大家根据这个思路去思考即可。
组件化 - 画图
我自己喜欢设计，日常有事没事还喜欢自己画点UI，所以也了解了一些『原子设计』、『组件化设计』的内容，因为我做的是 ToB 产品，不怎么用到 UI设计师，所以经常设计稿就是我的原型。慢慢的重复的内容越来越多，我就开始研究什么叫『组件化设计』。
组件化设计简单的意思就是：把相同的模块抽象出来，放在一个画板中，当你在画原型时，用到这样的模块时，直接复制去用即可。
例如：按钮，你不可能一个页面一种按钮风格吧，所以就可以把按钮按类型、场景画几个模板出来。其他场景再用的时候，先看看组件库里有没有，有就直接复制来用即可，没有的话，就把这个类型补充上，方便下次使用。
组件化不仅是设计的理念，也是开发的理念，思路和设计差不多，把相同的部分抽象出来，用的时候去索引即可。
组件化的话，是一门很长的学问，我懂的不是很多，所以推荐大家去看一些文章：
Ant Design: https://ant.design/index-cn
Element UI: http://element.eleme.io/#/zh-CN
以上是国内比较优秀的两个后台组件库（我也就用过这两个而已，bootstrap以前用过，但是过气了），还有一些如 iview、MuseUI等，自己有兴趣看看即可。
另外，强烈推荐大家好好看看 Ant Design 的设计语言部分，很有指导意义。
总结
虽然场景是老生常谈的话题，但是做产品不了解业务、场景，真的容易在设计的时候丢三落四。
同时，画原型时，也不要太过遵守规范、套路，『创新』是需要时刻放在脑海中的理念，因为『创新』可能是你做的产品的竞争力所在。
