在复杂中后台设计中，为解决配置变更影响多场景问题，提出结合正向和逆向信息架构，采用原子化任务，动态组合任务，降低用户和开发成本，优化体验并改变已有的产品迭代和人机交互模式。未来可能发展为AI自动根据业务规则和用户行为生成最佳方案。
一、背景
事情的起因是这样的：有一天技术同学找到我解决一个问题，有个【A】场景用户在做配置变更的时候会影响【B】和【C】场景，希望设计师能做个弹窗提示引导用户在保存之后去【B】和【C】场景做相应的配置变更。这是一个典型的关联场景任务的设计问题。
业务举例：产品商业化配置中，当用户修改【定价对象】时，需要同步去完成【计费规则】变更，否则将出账失败；
工作场景举例：当你的【会议室】发生了变更时（抢到了一个新会议室），需要同步去【会议日程】完成会议地点变更。
在阿里云复杂的中后台业务中，这种关联逻辑数不胜数。甚至两个中后台产品之间都会存在非常多的关联（BOSS和CRM，CRM和GTS等），我在想为什么大家都会不由自主的想通过【提示引导】的方式让用户去完成关联的闭环任务呢？
二、传统叙事逻辑带来的问题
在构建一个任务流程或者是一个中后台产品时，我们往往采用的思维框架就是【正向的信息架构模式】，建立严谨的功能分类标准和线性流程逻辑。
在很复杂的中后台场景下，这种叙事方式将每个最小的任务事件以架构的方式天然被组合或被隔离，当两个事情在某个场景，或者规则发生变化而需要建立联系时，两个事件需要变成一个闭环事件时，但是又被架构隔离。造成了用户的行为也是被架构所约束，就会遭遇上述的问题。
而解决这样的问题，我们一般的做法有两种：
1.搭桥梁—做个提示指引
2.做整合—建立新的信息架构
以上两种方式或 用户成本很高 或 开发成本很高，都不是终极的好选择。
三、构建原子化任务，动态组合成新的临时任务
要怎么解决呢？在复杂的中后台产品设计中，我们需要将【正向的信息架构模式】和【逆向的信息架构模式】相结合，解决复杂的任务场景和动态的业务规则下的体验问题：
正向的信息架构模式：建构稳定的产品认知（产品是干嘛的，找什么东西去哪里找）；
逆向的信息架构模式：动态的，基于具体场景自动生成的（把两个/多个被架构隔离的任务，组合生成一个新任务）；
回到刚开始的问题，更好的解决方案应该是：
它是一种新的模式，最小的原子任务当需要调用组合的时候，它不受架构的约束，当用户需要的时候它能自由组合成各种临时的新的任务场景，将带来极大效率的提升 ：
用户提效，就地问题就地解决；
开发提效，组合模式没有定制化；
未来可拓展，AI驱动的基础物料；
四、原子化会成为未来AI驱动产品迭代和人机交互的基础
4.1 原子化+AI 或许改变产品迭代流程
原子化任务事件未来它还会成为在中后台场景下AI的基础，基于AI算法它就能生成无数种组合，在用户需要的情况下推送给他，同时也可能改变传统开发设计流程 ：
传统开发设计流程：业务规则 —> PD&设计师处理 —> 设计架构和路径 —> 开发实现 —> 用户使用 —> 反馈迭代 。不断的循环来提升用户的效率和适应规则的变更，但其中充斥着人处理、人设计、人反馈 等人工处理信息的过程 。
未来在任务原子化和AI的基础上，可能演化为：业务规则&用户行为 —> AI —> 动态架构和路径（原子任务组合）—> 用户使用
4.2 原子化+AI 或许改变人机交互模式
根据业务规则和用户实际行为，AI 计算基于原子任务形成动态组合，并交付最优的方案给用户，改变传统的交互模式：
传统交互模式：设计一个固定的信息架构和路径， 用户在一个既定的逻辑上和界面进行交互；
新的交互模式：动态的，线性的，不在是一个既定的架构和路径；
未来AI可能是PD&设计&前端的集合体，而设计师要做的可能是底层的原子物料 （AI组件库） 以及用户场景的设计：
传统的组件库：主要做样式和功能，需要设计师学习理解一个业务上下文后挑选一个合适的组件放进页面；
AI组件库：每个原子组件背后都会有上下文的联系，AI模型读取业务规则&用户行为，动态调用语意匹配的组件组合成任务事件；
作者:一默
