美文网首页设计之路UI/交互设计规范
工作总结_后台设计(2)_设计规范

工作总结_后台设计(2)_设计规范

作者: Fog_li | 来源:发表于2016-08-21 23:38 被阅读322次

    工作总结_设计语言系统(DLS)

    1.设计规范的意义:

    视觉语言和其他语言一样,都是能传递信息的。如果不能有效的表达意义,那么视觉语言就没有表现该有的意义。

    制定规范首先应该要提高使用效率,其次才是品牌的传播和内容的沉淀,不应该本末倒置。

    2.规范的分类:

    分为系统性和产品性规范

    系统性规范:包括IOS、Android、支付宝&微信的钱包接口之类的规范。系统性大规范需要考虑多方面情况,要从宏观的角度去考虑;而像支付宝一类的设计要遵循系统规范,也是为了最大限度保证与系统体验的一致性

    产品性规范:包括手机淘宝、QQ之类的单一产品。由一个团队来进行设计,自己团队设定品牌规范和视觉语言,体现产品特色。能更好,更合理的匹配产品的业务诉求

    3.规范的使用角色:

    包括设计师、产品经理和开发人员三类人员。

    产品经理:对规范的需求,是帮助不同产品经理之间对于同一模块的理解,了解和说明业务的背景和原理,而并不需要严格意义上的执行。

    技术开发:在确定好一个规范控件以编码以后,直接在库里调用就可以了。在未来不改版的情况下,日常使用下是可以摆脱对规范的需求。

    设计师:大部分情况下,日常工作基本上还是设计师在使用和制定设计规范。

    总之,大而全的设计规范可读性较差,要针对性的让规范可读性和使用性强。

    4.设计规范的理想形态:

    首先,现在的规范多参考系统性规范的思路和模板,以一个个控件为基准。这样导致的后果就是设计师在执行具体业务的时候,还是需要自己思考控件怎么组合。

    然而,理想的规范使用是:在设计师接到业务需求后,能通过规范找到合适根控件kit,然后快速搭建业务界面,再根据具体业务需求单独修改文案、icon、图片等元素,快速输出方案。

    当然,更重要的是,根控件kit是固定的,而业务需求是变化的,设计师会因为不同需求遇到不同的界面反馈,而这些内容决定了设计的结果是动态的。所以,在设计根控件kit的时候,需要多考虑静态内容模块的源文件在真实业务场景里的变化规则。能对已有和未来可能要发生的组件做出预判,这样才能保证整个设计具有良好的扩张性。

    5.设计规范的开发时间节点:

    在开始创做时不要设定规范,会导致设计畏首畏尾

    在1.0版本设计结束时,再制定规范又比较晚了,很多东西开发出来又不行了

    一般在概念稿定版后开始设定规范,在批量生产

    6.产品性规范的思路:

    分为设计准则、素材库、指南三部分。

    a.设计准则:

    产品性规范更贴近产品,能有效执行,可操作性不强;系统性规范相对模糊,只能通过设计语言进行建议。

    1.自然:界面设计都是模拟自然界的真实存在,符合物理规则下的视觉效果。

    2.有序:业务间的样式是保持一致的,使业务之间能有连续性。

    3.无痕:提倡高效的协作。去除无意义的装饰,有效呈现界面的信息,保证代码和设计无缝对接。

    b.素材库:

    主要是指样式,比如信息流分为多图、单图、商品评价、商品详情样式等。

    c.指南:

    主要指使用建议,如色号、字体大小、热区、色彩、透明度、尺寸、间距等使用情况等。

    7.设计规范细致分类:

    a.组件

    含义:

    组件是指符合平台的整体规范,有较高的可复用性,具备完善的使用说明和代码文档的控件。

    组成:

    1.可以是按钮、表单、图片样式等。

    2.可以是基于组件衍生的子组件,某表单生成的子表单样式等。

    构成:

    1.原子组件和分子组件的概念:原子组件+原子组件=分子组件(但这种状态知识相对的,更好的方式是维持动态的生态模式)

    2.页面>组件>元素>图片=文字=icon=弹窗

    使用说明:

    1.说明元素意义(比如功能、对用户的作用、能提供什么信息)

    2.使用规则、限制情况(用的时候要注意什么、有什么限制)

    3.使用场景(在哪用,怎么用)

    4.一致性(新设计的组件,在哪些部分要和原有组件保持一致)

    5.组合性(扩展子组件时,有什么特殊性)

    6.各种状态(不同操作状态下呈现的样貌)

    7.平台差异性(不同平台上,同种组件的差别)

    8.正确&错误示范(标出常见的错误情况,节省来回修改时间)

    载体:

    1.规模不大的产品,以页面为载体展示组件。以页面流程为基础,添加合适的控件。基于场景,能避免脱离场景阅读设计文档的空洞感。

    2.规模较大的产品,需要和开发沟通一遍,需要使用说明做支撑。

    b.字体

    1.字体样式尽量保持在1-2个之间

    2.字体样式不要违背设计氛围,每种字体都有自己内在传递的意义

    3.字体选择的顺序:英>日>中

    4.字体选择也会受到系统和浏览器的影响,对于后台调用的数据,一般不要用特殊字体设计,系统会自动使用默认字体

    5.字体层级一般分为:一级标、二级标、一级正文、二级正文、注释

    对应字体大小,尽量用双数字号【web端:24、20、16、14、12;移动端:32-34、30-32、28-30、26-28、22】

    6.挑选字体时,保证一定的跨度,使界面层级明显

    c.色彩层次

    1.字体色彩,一般分为3层常见色值:333333  666666  999999

    2.分割线色彩,一般分为2层常见色值:一深一浅【编码尽量为AAAAAA  ABABAB】

    3.背景色彩,一般分为3层常见色值:FFFFFF +一深一浅【编码根据具体情况而定】

    d.尺寸

    1.尺寸尽量为偶数

    2.统一尺寸,学会归纳控件类型,把相同类型控件归为一类,做尺寸做归集,分清层次

    3.在前期开发时,对每种小控件,比如选框、按钮、头像、图片、tag等做分类,一般先分为3个层级,再在迭代情况下进行层级扩展

    4.首先在保证界面没美感的情况下,做到同类控件尺寸、宽高比都有一定规律可循

    5.在统一尺寸范围内绘制原始icon,再根据具体需求进行放大缩小,统一线型,倒角、设计区域

    【PC端:16、24、32、48、64、128、256;移动端:16、24、32、48、64、128】

    6.控件尺寸要尽可能被各种数整除,这样能满足同一控件不同状态的尺寸需求。通过观察各种UIkit发现,不同控件最后都能拼成一个方块,这证明各控件尺寸之间是存在一定数值关系的

    5.保证控件的层级和复用性,在满足设计需求的前提下,能少一种控件就不多一种,减少不必要的代码压力,也能保证视觉的统一性

    7.纵向尺寸上可以多看看经典界面如何做的,借鉴尺寸,如导航栏、tab栏等【有规范按规范来,没规范按经典界面来】

    8.控件的圆角、阴影在CSS3之后都可用代码实现,做好规范即可

    e.布局

    1.web端首屏布局尺寸一般控制在1170*620左右,这个尺寸能较好适配不同屏幕。【高620:是去除浏览器导航、系统工具栏之后的净尺寸;宽1170:是市面大多数浏览器的在去除边框等数值后的净尺寸】

    1.只做典型界面的布局设定,只做基础框架,以基础框架为原型,进行扩展,对大框架进行标注

    2.确定各个模块,明确各个模块的设计区域

    3.尽量做到布局上的12分法,有利于开发做响应式布局

    4.同种控件中,各边距保持一致。间距可在屏幕尺寸变化是,灵活调动

    5.清晰的间距能暗喻层次关系,外边距>内边距

    6.间距也按照同种类型进行排布,在一个控件中出现各种各样的间距

    f.状态

    1..反馈状态:按钮类反馈:【nor、hover、active、disable】形式要统一;控件框类反馈:默认、触发、出错状态

    3.常规状态:输入框水印态、页面空状态

    4.触发新增状态:输入框下拉态【待补充】

    g.风格

    1.在对各种空间了解熟悉之后,平时多观察同种控件在设计样式上的不同。比如tabs、面包屑导航等,都有很多种不同样式

    2.色彩能确定产品的调性,几个色彩的搭配能决定产品的风格。色彩一般1+3【即1主色、3辅色:辅色可以是主色的对比色or临近色】,尽量控制在4种以内

    8.注意事项:

    1.规范要让人们愿意使用,一甩几十页的规范,学习成本太高,别人看起来也烦

    2.规范要有参考性,对每个控件必要的使用说明是一定需要的

    3.制作80%的规范,要给设计师发挥的空间

    4.规范不是万能的,不仅用来提升体验和审美,也需要不断迭代和执行,才能达到设计规范的目的

    5.规范是会迭代变化的要根据产品情况进行增减,不要被规范绑架

    6.规范或者设计作品要定期打印出来展示,对作品进行评判,指出优缺点,才能去想解决方案,更加优化设计或规范

    相关文章

      网友评论

        本文标题:工作总结_后台设计(2)_设计规范

        本文链接:https://www.haomeiwen.com/subject/qejesttx.html