需求本身也是一种界面

最近，我参与了一项法规变更分析。客户给出的材料有四十多条需求，它们不是四十件可以单独处理的小事，而是在共同描述一套必须整体成立的规则。

真正让我觉得累的，不只是法规本身复杂，而是材料的表达方式让理解变得更困难。

读到后面时，我需要不停往回翻，把前面的条件和后面的例外重新接起来。到了第十条，能不能看懂下一句，已经取决于我还记不记得前九条之间的关系。 逻辑是连贯的，但材料没有把这种连贯直接呈现出来。

业务规则很少以天然易懂的形式出现。团队通过文档、会议、表格和图来接触它，而这些表达方式会在开发开始之前，就影响每个人对系统的理解。

长列表适合彼此独立的事项，但不适合表达依赖、优先级、条件和例外。如果这些关系都藏在文字里，阅读就会变成记忆测试，而不是推理。 材料可以包含所有必要信息，却依然让人难以看见整体结构。

这和界面设计很像。好的界面不是删掉功能，而是减少理解功能时不必要的负担。需求也应该被这样设计。

有时需要用决策表替代长列表，有时应该把相关规则重新分组，有时则要直接画出依赖关系，而不是让读者自己在脑中拼。

目标不是把业务说得简单，而是让复杂性以更容易理解的方式出现。

在最终用户接触产品之前，分析师、开发和测试已经先接触了它的需求。那段理解过程，同样属于设计的一部分。