ui界面设计规范，最新ui设计规范( 三 ) _互联网

设计师和工程师拥有最高优先权。
那么，工程师和设计师哪个更重要呢？我最近参与的所有设计系统项目都需要为这两者服务，为设计和代码做规范指南。我也在一些企业的文件中看到过太多对某一方的偏见，或者有完全割裂目标的倾向(后面我会解释) 。有许多方面需要考虑:设计系统的目标、他们的使用频率、内容深度、质量、生产成本以及与他们日常工作的相关性。
设计师vs工程师
外卖:读者的优先级是由很多因素决定的。期望:工程师和设计师的需求会有冲突，尽可能优化和处理这些冲突。如果实在不行，就要偏向最接近最终产品的一方，通常是工程师。这意味着工程师第一，设计师第二。
文档内容
规范是连接读者和内容的媒介。内容会有不同的格式或者模块，所以成本也会不一样，你需要最终把它们编织在一起。
内容模块:简介和案例文档内容模块:设计参考和代码参考。
摘要，规范文档的内容通常包含以下四个模块:
简介:组件的名称和简介。 (必要的)
案例:对于这个组件的各种形态、状态、维度等元素，最好直接用代码展示，而不是不能交互的静态图片。 (必要的)
设计:例如，我应该什么时候使用这个组件，允许的做法和不允许的做法，以及关于视觉，交互和文案的指南。 (推荐)
代码:包含api和其他实现和部署指南。 (必要的)
不同的模块会有不同的生产成本。
“引言”当然很短，写起来很快。一个优秀的“案例”也是值得花费的，写起来会越来越轻松。工程师也需要一个合理清晰的“代码参考” 。然而，真正有效的“设计参考”可能非常昂贵。
横轴:细节的丰富程度由浅入深。纵轴:制造成本从低到高。
请点击进入图片说明。
要点:一个规范文档可以包含许多内容模块。所以团队需要在前期进行充分的讨论，对每个内容模块做出符合自己团队和产品价值的判断，然后投入成本去做。
文献的信息结构
与设计代码:分离还是合并？
在实践中，设计师经常发布或更新自己的内容，工程师也是如此。这样的惯性行为会无意中加大设计和工程之间的距离。所以大家需要在前期对文档的信息结构达成共识。
谷歌的素材文档生态就是这种距离感的代表。 Material的设计基础以设计实践为主，而material design lite、polymer project、android developer's、material ui(为react而建)都是服务于代码的，与设计规范绑定不紧密。
请点击进入图片说明。
这种分离状态其实是有意义的，也是正当的。因为material是一个操作系统的底层系统，它跨越了很多框架、团队和平台。从某种意义上说，它的复杂程度超过了目前世界上所有的设计系统。但是你要知道，大部分设计系统都不是为一个操作系统服务的，所以不会发展成这么复杂的形态。
对于我们这样的产品团队来说，设计和代码要分开是符合共识的。这种方法可以设计出满足两种角色需求的体验。
组件设计规范和api及代码规范分别放在两个网站上。出发地:亚特兰大
请点击进入图片说明。
这种方法存在风险。随着时间的推移，这两个网站可能会不同步:

特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。