四、解决方案
在经历了一大波实际环境尝试之后，得出了一些目前比较适用的方案。首先明确不存在一张解决所有问题的图表达方式，这也是为了在可读性和完整性中寻求平衡。
1、业务用例图
首先在业务概念阶段，需要一种能表示系统内全部流程的图，并能展示角色的差别，方便跨部门沟通。重点在于简单快速易理解，在开始设计前敲定所有业务影响的范围。
所以选用普通流程图易理解的表达方式，直接引入角色的概念，若图表过于复杂则从颗粒度着手，再引入「包」和「领域」切分的概念就很完美了。
一整张图的形式
可调颗粒度行为并引入角色概念，真是和概念思维较弱的同学沟通的利器，也方便进行整个系统架构的思考，因为合理切分/加大颗粒度后，对大信息量的支持很友好。
例图前半部分被我截掉了，实际是一整张业务流程图，表达了全部主要的业务流程。图中也可以用一些小标签的方式表达一些额外概念。例如我图例紫色的小图标表示该操作允许业务员协助客户完成。
切分引入集合的形式
由于系统大小限制，此处可能需要细分任务颗粒度，酌情增加细分阶段。尝试利用类似DDD领域切分的思路分割复杂系统为独立系统，概念或流程打包独立封装，来简化自上而下设计时信息量过大的问题。
将「用户首次进入」流程封装，在其他流程中直接引用，方便进行整体管理。
能把流程简化到什么程度呢？见下图
太轻松有没有？
2、数据状态图
其次我们需要在完善功能概念阶段，需要一些能更好的表达抽象对象的图，来作为产品设计的工具，补充思考边界问题并尽量穷尽所有可能性，避免出现设计BUG。还有梳理状态和数据的关键变化。
行为数据图
数据如何产生？由某种行为，引起某处的变化，产生数据。所以图中要表示「地点」（页面），「行为」（操作），「数据项」（输入输出）。
由于怕干扰开发同学数据库设计和选择数据存储方案的思路，就采用了一个「数据存储/记录」的概念集合来表示采集的数据集合。需要表示数据项额外限制的，可以在数据项后加括号，例如：版本1-1（最大字符数25，disable状态）。
表层交互即用户能感受到的交互，底层交互则为用户感受不到的系统内部交互，分开主要因为有些时候底层交互触发的节点与表层交互触发节点不一致（系统总是会在背后默默地多做一些事情）。
状态图
同理状态也是由行为产生变化，所以每步状态变化必然带着一个前置动作。
括号「（-）」内的状态表示前台展示的状态对应的状态，「 [ – ] 」处内容为注释。
3、交互原型图
最后在交互原型阶段，需要一种表示界面元素的图来展示功能，并引入交互表达，这个都很熟悉，不多说了。
五、后记
当设计过于复杂的系统时，采用自顶向下的设计方式更容易搭建合理的体系。而稳步推进项目的好方法就是细分任务阶段，阶段性确认与阶段性设计（有点类似CI/CD的概念？）。
多层确认与详细的沟通一定不会带来坏处，让伙伴们明白「业务先行」与「集体参与」，会使设计方案更稳定且耐受考验。
内容均来源于个人思考，或有偏颇，或有不足，期待你的交流，这会让我们一起进步。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
