大概率的说，比我们想像的更重要。
一个常见的情况是，很多工具的使用往往提供了一些概念上的扩展点，比如：
- Tmux提供分屏能力时，给出了session/window/pane等操作实体概念；
- odps提供计算能力时，给出了project/table/column等实体概念；
这些多层次的实体概念在权限管理、资源分配等管理操作上提供了很多灵活性。但也带来了一个常见的问题：在文档交代不明确的时候，会让使用者在不明确一个概念的系统定位时，出现误用的现象，导致工具本身使用的过程充满了坎坷和限制，达不到最好的使用效果。如：
- Tmux中，window对应project，pane对应environment，导致session永远没有使用的场景，而大量的window堆积带来了查找上的困难。
- ODPS project对应了现实组织中的“部门”，导致业务混杂在一起，依赖关系不明确，统计分析没有可供划分的维度，权限管理基本失效，所有人可以看到所有业务数据。
这时候比较能体现Best Practise的意义：
- Tmux中，session对应project，window对应environment，pane对应shell，充分利用每一个维度提供的管理能力，管理压力小
- odps中，project对应实际中的业务项目，权限和资源在不同的业务特征下，给不同project分配、调整，同时兼顾了灵活、安全。
这一切的前提是要对工具的使用场景和工具里每一个概念的系统定位、背影，以及作者的设计初衷有比较深刻的了解才行。
没有对设计初衷的准确把握，所有feature之和小于工具本身。
反过来说，在设计一个工具时，自动屏蔽掉所有可能出错的路径，让用户没有犯错的机会，是一个工具开发者能力的体现。
P.S.
《设计心理学》是唐纳德·诺曼关于设计本质的理论著作，里面对设计本质的概括到今天仍然广泛适用：
- 示能：告诉你我的feature， e.g. 耳机音量键的设计
- 约束：根本不给用户犯错的机会，e.g.搜索框的设计
- 映射：产品设计和日常生活有映射关系，e.g.文件系统里的文件夹
- 反馈：即刻的有效反馈会粘住用户，e.g.进度条
