工作经验｜ B 端产品组件设计细节及经验分享（五）
本文源于读者和粉丝的相关提问，以及我前段时间在做 Ant Design 设计与运营工作中的经验沉淀和总结，希望对你有帮助 。
01 如何判断组件的美观性？
经常有同学问我：什么样的组件才是美的组件？或者怎样定义做出来的组件是美的？
其实“美”这个概念因人而异，很难被绝对化的定义。我总结出了四条设计规则，帮助大家作出判断。
1. 契合功能
“形式追随功能” 是包豪斯很早期的产品设计理念，同样也适用于交互设计。对于“美”的评判，需要特定环境和内容的加持。再好看的视觉表现，没有传达出确定的语言或呼应相关的功能，偏离了实际用途，都不能被称作“美”。
2. 自然舒适
人类是大自然的产物。面对大自然，大多数人都会感到愉悦和放松。Ant Design 也在其设计价值观中指出，“美” 的交互，会从两个方面体现自然：
- 感知自然：界面设计中的布局、色彩、插画、图标等要素，应充分汲取自然界规律，从而降低用户认知成本，带来真实流畅的感受。
- 行为自然：在与系统的互动中，设计师应充分理解用户、系统角色、任务目标间的关系，场景化组织系统功能和服务。帮助用户顺畅决策、减少操作阻碍，节约用户脑力和体力，让人机交互行为更自然。
3. 积极正向
“美”是具体事物包含的正向价值，应该使用正向的设计方法传播正向的能量和思想认知。危险的、具备侵略性的、不健康的设计表达都不能称之为美。
4. 与时俱进
“美”是社会意识形态在视觉层面的体现，是跟随着人类历史与文化发展而发生不断变化的。因此，是否符合当下流行趋势也可以构成一个对“美”的评判标准。
另外，我认为这四个判断标准的关系是层层递进的。最基础的美，就是“契合功能”，在与功能完美匹配后，便可以追求 “自然舒适”，然后再去“积极正向” 的感染他人，最后是“与时俱进” 紧随时代大潮流和趋势不断的自我革新。这也是一个螺旋上升的设计发展过程。
02 组件状态、尺寸是不是越全越好？
在做组件库时，你可能也会纠结这样的问题：一个组件要不要提供多个大小呢？如何判断一个组件是否需要做多种尺寸呢？组件库是不是越全越好呢？
1. 以「业务」为出发点
对于以上问题，一个很重要的判断标准就是业务或产品是否需要。对于大多数产品设计团队，在组件库搭建的初期，一定是以业务为主的，组件的设计应当是“从业务中来，到业务中去”。
当你的业务中对于一个组件有大、中、小尺寸的需求时，你再根据应用的场景做出组件并制定出相应的使用规则，也为时不晚。这样做的好处有以下几点：
- 做好的尺寸规定直接运用到业务中，有现成的验证场景
- 节省时间，避免先做了一大堆的尺寸分类和说明，但却无处应用
- 在设计师查找和使用组件的过程中，尽可能减少干扰。避免选项太多干扰使用
另外要注意，如果做了多种尺寸，你需要详细的规范每一种尺寸的使用场景，避免在实际设计和开发过程中的误用或混用。一句话，对于组件来说，并不是内容越全越好。“全”不等于“好用”，而且也会带来更多新问题。
2. 以「提效」为目的
对于业务级的组件设计系统，“大而全”不一定是好事，“专而精”有时会更高效。毕竟设计系统的根本目的就是降本提效，而非设计师们的炫耀设计价值的工具。
另外，“专而精” 也是另一个维度的 “全”。当我们通过对业务需求和属性的深入研究，将业务组件做的足够专业，也会从另一个维度对业务进行补充和赋能，从设计侧推动业务进行体验优化，促进产品质量的提升。
既然一切都以提效为目的，那什么样的内容可以被做成组件、要做出几种状态或尺寸、组件的使用规范要写到什么颗粒度，这些就都可以由业务设计师根据业务需求，自行制定标准了。
3. 以「能力输出」为重点
对于业务组件设计系统，组件库并不是核心，而是更强调通过一系列的机制，训练和培养业务设计师们进行统一的能力输出，包括组件设计和应用能力、协调和沟通能力、组件库检测和管理能力等等。
业务可能会千变万化，但只要团队整体的设计能力具备统一水准，工作流程规范，就能够用最短的时间，保证最基础的设计质量，还可以不断推陈出新，为业务注入更多设计价值。
本文作者@ 元尧 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
