如何建立一套 UI 设计规范？
-
一、确认目标用户在UI设计过程中，需求设计角色会确定软件的目标用户，获取最终用户和直接用户的需求。用户交互要考虑到目标用户的不同引起的交互设计重点的不同。例如：对于科学用户和对于电脑入门用户的设计重点就不同。二、采集目标用户的习惯交互方式不同类型的目标用户有不同的交互习惯。这种习惯的交互方式往往来源于其原有的针对现实的交互流程、已有软件工具的交互流程。当然还要在此基础上通过调研分析找到用户希望达到的交互效果，并且以流程确认下来。三、提示和引导用户软件是用户的工具。因此应该由用户来操作和控制软件。软件响应用户的动作和设定的规则。对于用户交互的结果和反馈，提示用户结果和反馈信息，引导用户进行用户需要的下一步操作。四、一致性原则设计目标一致软件中往往存在多个组成部分（组件、元素）。不同组成部分之间的交互设计目标需要一致。例如：如果以电脑操作初级用户作为目标用户，以简化界面逻辑为设计目标，那么该目标需要贯彻软件（软件包）整体，而不是局部。元素外观一致交互元素的外观往往影响用户的交互效果。同一个（类）软件采用一致风格的外观，对于保持用户焦点，改进交互效果有很大帮助。遗憾的是如何确认元素外观一致没有特别统一的衡量方法。因此需要对目标用户进行调查取得反馈。交互行为一致在交互模型中，不同类型的元素用户触发其对应的行为事件后，其交互行为需要一致。例如：所有需要用户确认操作的对话框都至少包含确认和放弃两个按钮。对于交互行为一致性原则比较极端的理念是相同类型的交互元素所引起的行为事件相同。但是我们可以看到这个理念虽然在大部分情况下正确，但是的确有相反的例子证明不按照这个理念设计，会更加简化用户操作流程。[2]五、可用性原则可理解软件要为用户使用，用户必须可以理解软件各元素对应的功能。如果不能为用户理解，那么需要提供一种非破坏性的途径，使得用户可以通过对该元素的操作，理解其对应的功能。比如：删除操作元素。用户可以点击删除操作按钮，提示用户如何删除操作或者是否确认删除操作，用户可以更加详细的理解该元素对应的功能，同时可以取消该操作。可达到用户是交互的中心，交互元素对应用户需要的功能。因此交互元素必须可以被用户控制。用户可以用诸如键盘、鼠标之类的交互设备通过移动和触发已有的交互元素达到其它在此之前不可见或者不可交互的交互元素。要注意的是交互的次数会影响可达到的效果。当一个功能被深深隐藏（一般来说超过4层）那么用户达到该元素的几率就大大降低了。可达到的效果也同界面设计有关。过于复杂的界面会影响可达到的效果。（参考简单导向原则）可控制软件的交互流程，用户可以控制。功能的执行流程，用户可以控制。如果确实无法提供控制，则用能为目标用户理解的方式提示用户。
-
UI规范，首先有几种不同的作用或者说侧重点。对象不同：面向内部面相第三方开发者树立规范的时机不同：在成熟的设计基础上梳理、总结规范在项目初期开创，制订规范这两处不同，会影响整个“UI设计规范”本身的内容方向属性等等。然后要清楚UI规范的作用。UI规范不只是给设计师看的，而且也是给开发工程师看的，UI规范从某些角度可以成为一个面子工程，但一定不能只是一个用来装X的面皮。UI规范应该对产品交互，视觉设计，开发实现都有一定的指导性和约束性。PS:BBC确实是一个比较好的例子，他们特别喜欢搞规范，事无巨细，从Web端到移动端，都是值得参考的范本。针对上面提到的两种不同，展开说一下：对象不同：面相内部的规范需要将内容梳理清楚，实用性第一，设计文档和标注都配好，设计师或者工程师可以直接参考和使用。废话可以少说，这份规范就是一个工具，干货为主。面相第三方开发者的情况，要更加细致，并且要说明为什么这么去做，开发者遵循这套规范有什么好处。其实这个直接参考Google/iOS的规范就可以。(MD:Introduction)树立规范的时机不同：在成熟的设计基础上梳理、总结规范，是需要考虑到规范的适用期的，对目前的设计未来可能发生的变化也需要考虑在内。总结和梳理容易，保留可扩展性延展性就需要深入思考了。在项目初期开创，制订的规范，往往随着项目的推进会发生很大改变，并且初期的规范一定是面向内部的，所以言简意赅，规范限制的东西都是界面上最基础的元素，给UI设计工作进行定调。这种规范应该尽量避免被颠覆，也就是说小步走，快速迭代可能会更合适。
-
从我自己实践和观察来看，不妨讨论一下UI设计规范的使用对象及场景：产品和设计团队参照共享的设计规范。不管是跟外部的用户体验设计公司合作，还是内部的设计团队执行设计，UI设计规范都是用来体现大家在产品设计沟通后一致确认的方案输出，以及为后续的产品迭代提供参照依据。为项目相关的技术同事（如前端工程师、iOS/Android工程师）实际开发和重构提供保障。技术在实际产品开发的时候，往往喜欢模式化，因为开发的工具语言往往有库、类这样的模块化思维。UI设计规范通过对一系列元素模块的具体规范，既能与产品开发实现完成对接，同时又便于工程师理解。那么何时输出UI设计规范呢？对于BAT等大公司来说，产品线众多，历史包袱沉重，一般无法形成公司层面非常细致的UI规范，一般以项目团队为基准。UI设计规范的输出时机，一般都是产品高保真界面经过产品、设计和技术共同讨论确认后。如果产品的高保真界面OK，同时内部设计资源相对有富余，对应的产品设计师就可以整理一份初版的UI设计规范，然后后面再填充优化。UI设计规范，从目前大家共享出来的方案来看，分为三种类型：平台（系统）性质，主要对于其平台内生态的设计指南，例如GoogleMaterialDesign、AppleWatchHumanInterfaceGuidelines、UbuntuDesign；品牌物料，主要提供给媒体、第三方公司等用于公关报道和设计（PS：貌似国内很少看到有这种整理，导致一些媒体报道的logo图片千奇百怪），例如Dribbble-LogoDownloads
-
UI设计规范，简单、不难。然而意识到规范的必要性，做好一整套行之有效的规范，很可能是设计师自己多年经验的结晶。UI设计规范是随着公司的业务和人员规模扩大，所必然出现的，用于保证设计风格一致，减少设计师彼此沟通成本，减少设计与前端甚至运营沟通成本的，一份文档，可能是PSD，AI，sketch，网页。其形式根据业务和内容的不同，可能划分为如下形式一、UIkit：常用于Web、App设计师之间协作用设计Web和App时，可能由多名设计师一同设计。为了保证最终效果的统一，按钮风格、控件样式、间距、都需要做统一。包含所有控件的一份动态的PSD文件（或.ai/.sketch），可以让不同设计风格的设计师，产出风格近似的产品。优点：快速高效在设计师之间使用要点：UIkit的设计质量，决定了使用这套UIkit的Web或者App的好坏。二、UI设计规范的文档文档与UIkit的不同点在于，更详细和准确，纳入了交互与前端的一些内容。对风格，颜色，文字，控件，交互，图标，动效，甚至配乐都有了明确的标注。往往是历经无数次休整与完善，迭代出的结果，而且是一个持续完善的动态文档。这个的例子其实比较多，拿最近做的一个比较简单的项目以作参考。可能在项目初期，是非常简单直白的。用Sketch生成可供开发查看的Web规范页。可免标注，且便于相关人员查看。优点：将复杂而抽象的设计，表现的更明确深入。与非设计人员沟通更加省力。前端将其转化成web，形成了统一的前端控件使用规范。要点：同样，文档体现的设计质量，决定了使用这套UIkit的Web或者App的好坏。文档定的太死会非常影响设计师的发挥，并且改动起来更折腾。设计规范本身要与时俱进的注意迭代。为了保证产出的质量，有时候会牺牲设计本身的灵活性。利弊自知。
-
规范建立时间，也更需要沉淀，不能一个版本完成就全部推翻重来，这样就失去了规范的意义，一来你的规范刚刚才逐渐完善就要被抛弃；另一方面，用户已经有了固定的认知，推翻则是对用户习惯的挑战。规范的沉淀对已知问题的积累有促进作用，通过一次次的规范迭代，touch到足够多的问题，在设计规范的制定中可以有效规避。同样，对过去的规范进行更为深入的优化，去其糟粕，留其精华，规范也会变得越来越完善和优质。
-
细致的设计规范在不注重设计的互联网公司十分难以推行，一方面是节奏变化非常快，你随时需要应用用户数据做出改变，二来，你的老板们哪天不爽，也可以分分钟推翻你的血汗。规范到底用来做什么？所谓规范，便是对成一定数量的可复用设计或者多设计师协作的设计项目进行量化和约束的东西。如果数量不到一个量级，或者设计师就你一个人，规范的作用力实则非常小，甚至繁琐程度会影响到正常的设计工作，所以分清你的使用场合，什么情况下需要用到规范？规范先行还是设计先行？规范和设计孰先孰后？我所提倡的规范应该在设计中同步进行，没有根据设计实践建立的规范瓶颈过低，经常遭遇各种事先没有考虑进去的问题，同时在设计中要不断完善和修复自己的规范。我们设计一个产品的设计方面的工作流程通常是：探索>脑爆>草稿>讨论>细化>定稿>规范>批量化所以，先小范围的将设计雏形生产，在生产过程中不断的沉淀规范，哪些可以作为规范使用？哪些地方需要灵活处理，这些都需要实践获得，当小范围的设计规范得到验证后，即可进行批量化生产，此时，所有设计师都可介入生产过程，即使的新加入的设计同事也可以通过规范了解设计规则。清晰的表达给所有人规范是面向所有设计师的，你需要让规范被每个人理解。所以规范需要非常细致，按照规范的种类类归，同一种控件按照多种状态、不同场景罗列，让每个设计师都能清晰设计中需要用哪一种
回答请先登录