精华内容
下载资源
问答
  • 产品经理——产品原型设计规范

    万次阅读 多人点赞 2018-08-29 14:35:42
    相似而不同的内容分成几个区域,各区域相关内容相互聚拢。 3.对比原则 加大不同元素或者板块的对比和视觉差异。 4.一致原则 不同页面相同内容,设计上的必须保证一致性和连贯性;不同页面相同元件和交互事件...

    1 术语与解释

    表 1 1术语表
    这里写图片描述
    这里写图片描述

    2 概述

    2.1 前言

    由于多种因素,在需求分析阶段得到完全、一致、准确、合理的需求说明存在困难。在获得一组原始需求后,如何快速地使其“实现”,通过原型反馈,加深对系统的理解?如何满足用户基本要求,使用户在试用过程中受到启发,对需求说明进行补充和精确化,消除不协调的系统需求,逐步确定各种需求?如何获得合理、协调一致、无歧义的、完整的、可行的需求说明?

    这里写图片描述
    图 2 1不同角色认为的需求

    随着计算机辅助设计的应用,产品设计和生产能力得到极大提高,然而在产品设计、研发和生产前,快速获取产品设计的反馈信息,如何对产品用户价值、可行性、可用性和交互体验等快速地做出评估、论证和改进,这是软、硬件产品生产的痛点。
    快速原型技术的出现,为这一问题的解决提供了有效途径,不仅解决了需求阶段的一致性问题,还能很好地将这种一致性的传递到产品研发过程中的系统设计阶段、视觉设计阶段、编码和测试阶段等过程。快速原型是非常有效的需求可视化呈现、传递和解释手段。

    2.2 定义
    快速原型(特指IT领域,下同)常被称为线框图、mockuo、demo,是对产品可视化的呈现,主要表达一个产品的信息架构、页面布局、内容、功能和交互方式,可以真实的模拟产品最终的视觉效果、交互效果和用户体验感受。快速原型,按照仿真效果划分为:低保证原型和高保真原型;按照业务流程划分为:水平原型和垂直原型。
    目前,主流的产品原型设计软件/工具有:
    POP(Prototyping on Paper)是由来自台湾的Woomoo公司推出的一款界面原型设计工具,适用于iOS和Android平台。
    摩客(Mockplus)是一款简洁、快速、免费的原型图工具,适合软件团队、个人在软件开发的设计阶段使用。该工具具有低保真、无需学习、快速上手等功能特点,可以帮助用户轻松的做出专业化的原型设计。
    Briefs是Mac最新上架的专业App设计工具,提供了成熟的交互设计功能,堪称移动App上的“Axure RP”,设计师可以利用Briefs设计完整的iPhone、iPad应用交互模型,并利用模拟器即时体验设计的成果,或者利用BriefsLive,将 作品同步到装有Briefscase的iOS 6设备上。
    Wireframe是一款具有“点击-拖-放”界面且超简单的线框图创作工具。双击实现编辑功能,有限的界面意味着你会把精力集中于你的想法上。还给每个线框图分配了特有的URL,便于标记和分享。

    我们为什么选择Axure?
    Axure RP,地球上的PM应该都知道它,虽然它不是最完美,但是具有以下优势:
    1. Axure可以进行更加高效的动态设计;
    2. Axure可以让你体验动态真实原型;
    3. Axure可以更加清晰的交流想法;
    4. Axure可以更便捷的被分享;
    5. Axure是使用最广泛的原型设计工具。

    这里写图片描述
    图 2 2Axure_7.0主界面

    2.3 目的
    产品原型设计规范(下称“本规范”)指导产品经理、交互设计师或产品原型设计工作者,在产品原型设计活动中理解、遵循和掌握各节点的任务、边界、规范等相关内容;提高产品原型设计工作者的专业水平和产品原型设计的质量,达到产品原型设计活动的专业性、规范性和系统性等目的。

    2.4 范围
    本规范由产品经理团队负责制定并授权更改,产品原型设计活动遵循此过程。本规范影响范围包括项目组所以人员。

    2.5 流程
    产品原型设计活动主要工作是设计和评审,参考《产品经理工作规范快速指南》,从产品经理工作规范和流程角度出发,产品原型设计活动分为3个阶段:需求阶段、产品原型设计与评审阶段和交付与维护阶段。
    需求阶段,主要工作是需求调研和业务流程梳理,并输出需求文档。需求阶段可根据需要输出低保证产品原型展示给需求方,产品和需求方双方进行需求一致性前期确认;
    产品原型设计与评审阶段,产品经理一般组织完成需求文档编制和评审工作,接着输出高保真产品原型,建议邀请用户、产品伙伴、测试组同事参与产品原型体验,提前发现产品原型中的需求缺陷、交互缺陷和用例缺陷等问题,完成缺陷修复后,产品经理应该邀请需求方、项目组、部门主管、公司领导(按需)组成评审小组,参与产品原型评审活动;
    交付与维护阶段,产品原型评审通过后,产品原型交付给项目组(纳入项目组SVN),后期研发过程中,如果出现需求变更或发现产品原型设计缺陷等问题,应当及时进行维护,产品原型必须做好修订记录,并通知项目组等相关方。产品研发后期或完成后,产品原型源文件应归档至产品组SVN。

    这里写图片描述
    图 2 3产品原型设计与评审流程

    2.6 原则
    1.对齐原则
    相关元件和内容按照层次必须对齐。
    2.亲密原则
    相似而不同的内容分成几个区域,各区域相关内容相互聚拢。
    3.对比原则
    加大不同元素或者板块的对比和视觉差异。
    4.一致原则
    不同页面相同内容,设计上的必须保证一致性和连贯性;不同页面相同元件和交互事件必须保证一致性。
    5.留白原则
    注意页面元素的密度,保持必要的空白。
    6.降噪原则
    颜色过多、字数过多、图形过繁,都是分散注意力的”噪音”,注意页面整体视觉效果,整体色调必须以灰色系为主,点缀色为辅。
    7.节省原则
    元件使用尽量节省,可以一个面板处理不要使用两个,可以一个事件处理,不要多个。
    8.MECE原则
    交互/用例设计满足相互独立完全穷尽原则(MECE原则),避免遗漏和交叉。

    2.7 元件

    这里写图片描述
    图 2 4Axure默认元件概览图

    Axure自带丰富的元件库,默认元件库包括:通用型元件、排列型元件和菜单型元件3种,还自带一个默认流程图元件库;Axure支持设计、导入和导出自定义元件库(文件格式:“*.rplib”),满足产品原型设计工作者个性化使用。Axure默认元件库介绍如下:

    表 2Axure默认元件列表
    这里写图片描述

    3 输入

    一般需求阶段已完成或者处于后期文档编制和评审阶段,开始产品原型设计工作。产品原型设计前置条件:必须完成产品定义和版本规划,确定产品形态和界面尺寸,输出产品功能结构图、业务流程图、用例图等必要的需求文档。

    4 设计规范

    设计规范详细阐述本规范的维度、要求和示例等内容,产品原型设计工作者应共同努力使用规范、维护规范和更新规范。设计规范更新是一个不断调整和丰富的动态过程,通过持续更新以符合公司产品原型设计的实际情况,保证专业性、规范性与实用性的统一。
    设计规范在操作过程中,从强制性角度划分有4个级别:必须、推荐、一般和禁止。下文均有明确提示,如未明确提示的,则表示为“一般”。
    本规范包括3个配套附件:
    1. 产品原型设计模板-WEB.rp
    2. 产品原型设计模板-Software.rp
    3. 产品原型设计模板-APP.rp
    温馨提示:产品原型设计模板见产品组SVN:…SVN\Productfile\工作规范\文档模板\产品原型

    4.1 页面结构
    4.1.1 描述
    页面结构指产品原型设计工作界面的目标产品的页面结构,页面结构由原型说明和产品原型2部分组成,各部分使用文件夹分隔(如果产品包含多个子系统,则需要创建多个文件夹分隔)。
    原型说明是辅助说明内容,方便体验者快速了解产品的全貌,原型说明包括:修订记录、版本规划、业务流程、功能模块、交互说明和参考尺寸等页面;
    产品原型是页面设计的主体部分,各页面严格按照功能结构拓扑或者任务关系拓扑,且命名必须使用“编号+名称”的形式,如:A-1-1-新闻列表,其中,A表示页面或任务编号,1-1表示层级,各部分使用“-”连接。

    4.1.2 示例

    这里写图片描述
    图 4 1产品页面/任务结构

    4.2 修订记录
    4.2.1 描述
    产品原型通过评审,交付项目组后,如果进行后期维护,必须打上修订记录。每次产品原型修订,详细描述修订记录,修订类型:创建、新增、修改、删除。修订记录需要说明页面层级或编号以明确路径。

    4.2.2 示例
    这里写图片描述
    图 4 2产品原型修订记录

    4.3 版本计划
    4.3.1 描述
    版本计划,需要简述软件简介,描述软件名称、定位、目标用户、子系统职责等基本信息。版本计划应该基于目标产品和产品目标输出,在产品原型中重点描述规划的版本号(如2.5.0)、特性和优先级等。

    4.3.2 示例
    这里写图片描述
    图 4 3软件简介和版本计划

    4.4 业务流程
    4.4.1 描述
    业务流程是指产品的整体/全局业务流程,用于描述产品的业务场景。流程图要求:包含流程名称、角色/职责/系统名称、起始状态等;建议使用Visio/Axuer等软件绘制流程图;其中,子流程建议在中转页面中绘制。

    4.4.2 示例
    这里写图片描述
    图 4 4整体业务流程示意图

    4.5 功能模块
    4.5.1 描述
    功能结构图即软件的功能拓扑图,是一种快速直观地展示软件功能的图示,建议使用MindManager、Xmind、Axure等软件绘制思维导图,以功能层级或业务流程为基准进行拓扑设计,或者使用Microsoft Office软件绘制也可。推荐思维导图工具:Xmind_7.5。

    4.5.2 示例
    这里写图片描述
    图 4 5软件功能结构图

    4.6 交互说明
    4.6.1 描述
    全局性交互说明,如:弹窗、数据加载、暂无数据、404等;交互说明包括:事件名称、触发条件、适用范围和交互流程等,且辅助示例展示。

    4.6.2 示例

    这里写图片描述
    图 4 6全局性交互设计列表

    这里写图片描述
    图 4 7全局性交互设计示例

    4.7 参考尺寸
    4.7.1 描述
    参考尺寸是辅助产品原型设计的说明内容,不作为产品视觉设计依据。根据产品形态不同,产品原型设计参考尺寸如下:

    1.WEB:
    页面尺寸:推荐1600*900(min)px
    版心尺寸:推荐1000*600(min)px

    2.Software:
    NO.1-推荐尺寸:1366*768PX(16:9)
    NO.2-推荐尺寸:1024*768PX(4:3)

    3.APP:
    Phone:
    NO.1-最小尺寸:320*570PX;
    NO.2-推荐尺寸:393*700PX;
    NO.3-最大尺寸:456*821X;
    Pad:
    NO.1-推荐尺寸:553*738PX(738*553PX);
    NO.2-最大尺寸:768*1024PX(1024*768PX)

    4.7.2 示例
    这里写图片描述
    图 4 8产品原型-WEB-参考尺寸

    这里写图片描述
    图 4 9产品原型-Software-参考尺寸(16:9)

    这里写图片描述
    图 4 10产品原型-Software-参考尺寸(4:3)

    这里写图片描述
    图 4 11产品原型-APP-参考尺寸(Phone)

    这里写图片描述
    图 4 12产品原型-APP-参考尺寸(PAD)

    4.8 版权信息
    4.8.1 描述
    版权信息指产品原型的版权信息,即可凸显公司产品实力,又可防止产品原型被盗用。版权信息包括产品名称、版本号、产品经理和版权申明等内容。针对不同的使用场景,提供2种版权信息示例。

    4.8.2 示例

    这里写图片描述
    图 4 13版权信息(1)
    图 4 14版权信息(2)

    4.9 页面设计
    4.9.1 描述
    页面设计是产品原型设计的主体工作,一般依据需求文档进行页面规划和版面设计,不仅需要实现页面布局和内容展示,还需要实现页面的交互设计和需求标注等。
    页面设计严格按照功能结构拓扑或者任务关系拓扑,且命名必须使用“编号+名称”的形式,如:A-1-1-新闻列表,其中,A表示页面或任务编号,1-1表示层级,各部分使用“-”连接。
    页面设计要求菜单层级的链接和业务流程的层级跳转是有效的,保证主要页面之间交互的连续性,便于体验者浏览产品原型HTML;页面设计需严格遵循本规范定义的设计原则,以保证原型设计质量;产品原型设计应该在注重实用性的同时,考虑创新性。

    4.9.2 示例
    这里写图片描述
    图 4 15产品原型页面设计示例图

    4.10 用例描述
    4.10.1 描述
    高保真产品原型设计重点在于交互设计,对象的交互用例设计必须遵循相互独立完全穷尽原则(MECE原则)。同一个对象用例超过2个时,必须对用例进行命名,建议保留用例编号,如:用例3;

    4.10.2 示例
    这里写图片描述
    图 4 16用例设计示意图

    4.11 需求说明
    4.11.1 描述
    为了保证需求传递的一致性,页面的关键元件、用例、表单、按钮等按需标注需求说明。需求、用例、备注、提示等需求说明,推荐使用规范格式设计,如:1A,其中,1表示编号,A表示流程顺序;需求说明也可使用快捷方式如:TIPS:密码错误时,在密码输入框下方提示“密码错误”。需求描述的放置位置应当保持页面的美观。

    4.11.2 示例
    这里写图片描述
    图 4 17需求描述说明

    4.12 中转页面
    4.12.1 描述
    中转页面一般是在产品原型设计过程中产生的,如:一级菜单=产品发布,二级子菜单1=产品列表,二级子菜单2=产品修改,由于产品发布页面并没有内容,所以产品发布页面就是中转页面。中转页面必须放置页面跳转的按钮,方便浏览。
    中转页面大有可为,推荐在中转页面绘制子业务流程图、页面流程图(APP必须)、用例图、数据流图等需求类图示,加强产品原型的解释能力。

    4.12.2 示例
    这里写图片描述
    图 4 18子业务流程图

    这里写图片描述
    图 4 19用例图

    这里写图片描述
    图 4 20页面流程图


    4.13 弹窗/浮窗
    4.13.1 描述
    页面交互如果涉及弹窗/浮窗提示的,必须设计弹窗/浮窗,且保证事件执行有效性和完备性,禁止出现弹窗点击没有反应的情况。弹窗设计禁止出现超过3层弹窗的情况!
    弹窗设计主流的3种方式:弹窗没有背景效果;弹窗附带页面背景遮罩效果;弹窗附带阴影效果。
    浮窗设计一般是显示后自动隐藏,少数隐藏后还执行事件。

    4.13.2 示例
    这里写图片描述
    图 4 21弹窗示意图
    这里写图片描述
    图 4 22浮窗示意图

    4.14 菜单设计
    4.14.1 描述
    Axure自带元件库提供了树形菜单、横向菜单和纵向菜单3种菜单设计方案,能够满足多数使用场景。如果产品需要,建议自定义创新菜单设计。
    菜单设计,必须实现悬浮、点选、选中等交互效果,推荐与母版嵌套使用,方便后期维护,禁止出现多个页面菜单一致的情况下,不使用母版。

    4.14.2 示例

    这里写图片描述
    图 4 23Axure自动的3种菜单

    这里写图片描述
    图 4 24自定义菜单设计(1)

    这里写图片描述
    图 4 25自定义菜单设计(2)

    4.15 表单设计
    4.15.1 描述
    表单设计应用于多项数据排版和展示的场景,如:机构用户注册、标识符申请、产品发布等。推荐使用表格进行设计表单设计,包括:查询表单、数据填写表单、查看详情表单等。

    4.15.2 示例

    这里写图片描述
    图 4 26查看详情表单设计示例

    这里写图片描述
    图 4 27修改信息表单设计示例

    这里写图片描述
    图 4 28查询列表表单设计示例

    4.16 提示设计
    4.16.1 描述
    产品原型的精细程度,除了合理的页面布局和完备的交互外,很大一部分是交互提示和交互提示的系统化整理。避免,遇到一个默认提示或者报错,临时定义。时间长了,数量多了,没有办法跟踪和管理。一方面,产品原型中穷尽用例和提示语,另一方,推荐使用Excel文档形式进行跟踪。

    4.16.2 示例

    这里写图片描述
    图 4 29表单提示语规范参考图

    这里写图片描述
    图 4 30交互提示语规范参考图

    这里写图片描述
    图 4 31错误提示产品原型示例

    4.17 动态面板
    4.17.1 描述
    动态面板是产品原型设计中,非常重要和常用的元件。动态面板必须命名,推荐使用英文名称或拼音;状态数量超过2个时,必须对状态进行命名;同一个页面动态面板数量推荐控制在3个以内;同一个动态面板,状态层级数量推荐控制在3层以内。

    4.17.2 示例
    这里写图片描述
    图 4 32动态面板示例

    4.18 母版设计
    4.18.1 描述
    页面通用模块/组件,建议使用母版制作。包括但不限于:页面头部和底部、功能菜单、属性面板等版式固定的区域。
    温馨提示:各种元件包括动态面板支持与母版嵌套使用。

    4.18.2 示例
    这里写图片描述
    图 4 33母版示例

    5 输出

    产品原型设计活动中,产品经理负责输出高保真原型,必要时还需输出低保真原型。高保真产品原型设计流程和规范应遵循本规范。

    6 质量与评价

    对产品原型设计活动进行测量,并将测量结果用于确定软件研发活动的状态和产品经理考核。产品原型测量依据:
    1.需求符合度:评判产品原型表达的需求和功能与需求文档定义一致性或符合程度;
    2.产品原型设计质量:参照本规范和产品原型设计模板对比产品经理输出的产品原型源文件,评判其规范符合度以及设计质量;
    3.产品原型设计效率:综合考虑产品原型的页面数量、控件数量、交互复杂度等,对比产品原型设计的时长进行考量;
    4.产品原型体验满意度:体验产品原型输出的HTML页面,评价用户满意度。

    展开全文
  • UI设计中关于设计规范、切图和尺寸的点疑问?

    从事软件开发和设计工作的大家肯定或多或少对设计规范和切图以及尺寸有一些疑问,但是这些方面也是我们工作中必不可少要接触的内容,所以大家都知道并了解我们从事这个行业,尺寸规范以及切图的重要性,首先,我们先来聊聊设计规范,工作中我们往往需要提出一个完整的一次性解决方案。但有时我们是受到时间的限制,或者我们只是还没有确定一个清晰的发展方向。一次性的解决方案并不是说它不好,但是如果它不是建立在一个坚实的基础之上,最终我们会发现自己还是不得不回过头来偿还技术积累和设计这笔债。

     

    n 为什么需要设计规范

    1、缺少限制

    相比于其他设计领域,软件设计几乎没有物理限制。这就意味着任何一个问题都可能有多种解决方案,但这恰恰可能造成用户体验的不一致。因此作为产品所有者或设计师,我们必须创建并遵循自己的设计规范。

     

    2、多人协作

    软件通常是由一个团队设计出来的,有时甚至可能是很大的团队。这就意味着,创造一个连贯一致的用户体验的难度会随着团队成员的人数增加而呈指数增长。另外,无论团队协作多么一致或团队多小,不同的人总会有不同的解决方案或设计风格,很容易导致体验割裂。

     

    3、多个平台

    我们需要让产品应用于多种不同的平台和设备。为保证产品在多平台间的同步及体验的一致性,通常需要在不同平台上去做很多重复性的工作。

     

    4、软件是连贯的

    软件的另一个不同之处在于,虽然它可以被认为是一个产品,但他不会像传统的消费品那样真的磨损或被更换。即使公司和其产品本身发生了大的变化,多年前的代码和设计仍然会存在于产品的许多地方。这就要求不断的维护和升级。

     

    随着现在手机行业的兴起,手机的尺寸越来越多,相信刚入门的设计师都会被手机尺寸、分辨率、适配等等的给弄昏头脑,下面帮助UI新手小伙伴们,快速了解一些设计规范。

     

    主流Android手机的分辨率和尺寸


    移动UI设计切图是UI设计师最重要的设计输出物,切图资源输出是否规范直接影响到工程师对设计效果的还原度。设计师的切图输出物是是体现一个设计师专业水准的重要标准,同时也是设计师表达自己对设计态度的最有力的语言。合适、精准的切图可以最大限度的还原设计图,起到事半功倍的效果。如何输出具有全局把控和细节专注的高段位切图,应该是所有设计师一直需要追求的能力。

    设计切图的原则

    设计切图输出的目的是跟下游的工程师团队协同工作,那么在团队协作过程中首先应该保证切图输出能够满足工程师设计效果图的高保真还原的需求。其次切图输出应该尽可能的降低工程师的开发工作量,避免因切图输出而导致的不必要的工作量。最后输出的切图应当尽可能的压缩大小,以降低APP的总大小,提升用户使用时的加载速度。所以切图输出应当做到切图精准、便与协同和压缩大小。


    l 切图资源尺寸必须为双数

    图标切图输出应根据标准尺寸输出并且考虑到手机适配(主要是iPhone 6plus的适配) 

    为了提升APP使用速度,尽量降低图片文件大小

    可点击部件应当注意其点击区域不小于88px

    l 可点击部件要把相关状态都切图输出,比如正常状态、点击状态。

    切图神器Cutterman介绍

     

    Cutterman是现在最主流的设计师切图利器,能够自动将你需要的切图进行输出。极大的减轻了设计师的工作量,提升了切图效率。它支持各种图片格式,尺寸,形态输出,  兼容安卓,iOS,WEB各种系统的一键输出。以下是Cutterman的使用方法简介。

     

    l 一键切图,真正解放双手

    Cutterman能够让你只需要点击一个按钮,就自动输出你需要的各种各样的图片,快到没有朋友!

    支持IOS平台

    输出支持IOS平台的单倍图、双倍图,支持IPHONE6/6P尺寸比例。

    支持Android平台

    输出支持Android平台的各种分辨率大小图片,什么XXHPDI,XHDPI,HDPI啊之类的,通通自动化输出,为你节省出更多的时间陪小伙伴好好玩耍。

    l 支持各种图片格式输出

    什么png、jpg、gif通通不在话下,还可以自己缩放、压缩大小呢。从此,就告别那个所谓的“存储为web所用格式”的功能啦~~

    l 多个图层合并、单独输出

    图层太多?木关系!可以多选嘛!支持选中多个图层合并输出,也可以逐一输出的哦,简直方便到爆!

     

    l 固定尺寸输出


    想要输出固定尺寸的ICON,多种姿势让你选择,秒秒钟的事情~~

     

    展开全文
  • 流程质量+测试质量 开发与测试的流程要严格遵守 测试的质量说的 是测试案例的质量,测试人员的工作效率,需求覆盖度,缺陷密度...3,测试技术的高度,如测试计划的合理性,用例设计的全面性、粒度、效率,以及测
    流程质量+测试质量
    

    开发与测试的流程要严格遵守

    测试的质量说的 是测试案例的质量,测试人员的工作效率,需求覆盖度,缺陷密度等等  综合分析给出测试质量。

    考虑从以下方面提升软件质量:
    1,项目流程的规范程度,包括需求管理、开发流程、测试流程
    2,测试资源的充分程度,包括人(质与量)、时间、环境、工具等
    3,测试技术的高度,如测试计划的合理性,用例设计的全面性、粒度、效率,以及测试执行的充分性


    不谈理论,只谈实践的话。如要保证好测试的质量(或是说成得到客户较高的认知度)。至少要考虑以下几个方面。
    1,让用户承认你的测试对象分析结果(需求分析转化为测试需求分析的过程要得到客户的认可)
    2,用例设计过程,不但要能设计出高效的用例,而且要能说明是如何的高效,要得到客户的认可。
    3,如何证明,你的测试过程是高精度,高效率的,你的团队是敬业的,并有在实施的过程中能不断的发现问题,克服/解决问题。
    4,你的结果报告中的内容,是否能准确反映软件的质量状况,并且,有客户想看到的内容。

    从另外角度来说,要想得到好的评价,不但要有好的用例设计技术,和很强的总结,报告能力,与客户的沟通,与开发的协调,以及对组员的管理,都是非常重要的。哪个环节出现问题,都会波及其他方面。所以,才说做好测试真的不容易,因为他不但对技术有要求,对人的本身,也有很高的要求。


    展开全文
  • UI设计规范-全文篇

    千次阅读 2019-05-24 15:48:04
    UI设计规范 1 1. 界面规范 1 1.1. 总体原则 1 1.2. 原则详述 2 1.2.1. 用户控制 2 1.2.2. 清楚一致的设计 2 1.3. 细节约定 3 1.3.1. 界面风格 3 1.3.2. 统一术语 14 关于UI规范的点意见 15 深圳UI...

    目录

    UI设计规范 1

    1. 界面规范 1

    1.1. 总体原则 1

    1.2. 原则详述 2

    1.2.1. 用户控制 2

    1.2.2. 清楚一致的设计 2

    1.3. 细节约定 3

    1.3.1. 界面风格 3

    1.3.2. 统一术语 14

    关于UI规范的几点意见 15

    深圳UI设计交流QQ群:611531774 

    UI设计规范

    1. 界面规范

    1.1. 总体原则

    l 以用户为中心。设计由用户控制的界面,而不是界面控制用户。

    l 清楚一致的设计。所有界面的风格保持一致,所有具有相同含义的术语保持一致,且易于理解

    l 拥有良好的直觉特征。以用户所熟悉的现实世界事务的抽象来给用户暗示和隐喻,来帮助用户能迅速学会软件的使用。

     

    l 较快的响应速度。

    l 简单且美观。

    1.2. 原则详述

    1.2.1. 用户控制

    用户界面设计的一个重要原则是用户应该总是感觉在控制软件而不是感觉被软件所控制。

    l 操作上假设是用户-而不是计算机或软件-开始动作。用户扮演主动角色,而不是扮演被动角色。在需要自动执行任务时,要以允许用户进行选择或控制它的方式来实现该自动任务。

    l 提供用户自定义设置。因为用户的技能和喜好各不相同,因此他们必须能够个性化界面的某些方面。Windows为用户提供了对许多这方面的访问。您的软件应该反应不同的系统属性-例如颜色、字体或其他选项的用户设置。

    l 采取交互式和易于感应的窗口,尽量避免使用模态对话框,而使用"非模式"辅助窗口。 "模式"是一种状态,它排除一般的交互,或者限制用户只能进行特定的交互。当最好使用一个模式或该模式只是可替换的设计时-例如,用于在一个绘图程序中选定一个特定感觉-请确保该模式是显然的、可见的,是一个明确的用户选定的结果,并且容易取消。

    l 在后台运行长进程时,保持前台式交互。例如,当正在打印一个文档,即使该文档不能被改变,用户也应该可以最小化该窗口。

    l 谅解。用户喜欢探索一个界面,并经常从尝试和错误中学习。一个有效的界面允许交互式的发现,它只提供一组合适的选择,并在用户可能破坏系统或数据的情况时发出警告。如果可行,还应提供可逆转或可还原的操作。即使在设计得很好得界面中,用户也可能犯错误。这些错误既可以是物理上得(偶然地指向了错误的命令或数据),也可以是逻辑上的(对选定哪一个命令或哪些数据做出了错误的决定)。有效的设计避免很可能导致错误的情况。它还包容潜在的用户错误,并且使用户易于还原。

    1.2.2. 清楚一致的设计

    一致允许用户将已有的知识传递到新的任务中,更快地学习新事物,并将更多的注意力集中在任务上。这是因为他们不必花时间来尝试记住交互中的不同。通过提供一种稳定的感觉,一致使得界面熟悉而又可预测。一致在界面的所有方面都是很重要的,包括命令的名称、信息的可视表示,操作行为,以及元素在屏幕和窗口内部的放置。

    l 相同含义的词使用统一的术语。比如对于仓库中存放的物料,不可同时又称为物品、货物、备品、产品和材料等等,而统一约定一个称谓,且此称谓是用户熟悉的和易于理解的。

    l 使用一组一致的命令和界面来展示常见功能。例如,避免一个"复制"命令在一种情况下立刻执行一个操作,但在另一种情况显示一个对话框要求用户键入目标然后才执行。应该使用同样的命令来执行对用户来说相似的功能。

    l 操作环境内的一致。保持Windows提供的交互操作和界面约定之间的高度一致,用户将能很快熟悉软件的使用。

    l 使用隐喻的一致性。如果一个特定的行为更多的是一个不同的事物的特征,而不是它的隐喻的含义,那么用户可能在学习将行为和该事物相关联时遇到困难。例如,对于放在回收站中的对象而言,焚烧炉和废纸箩代表不同的模型。

    l 建立项目保留字。通过建立保留字来明确和统一术语和操作命令。

    l 提供可视反馈。在后台运行长进程时(时间超过1~10秒,视具体情况而定),必须提供进度条等信息指示。

    l 除非特别必要时,不要提供声音反馈。在有严重的问题发生时,可以使用声音来提示用户,但是通常应该允许用户取消声音。

    l 保持文字内容清楚。信息的表达要言简意赅,易于理解而又不罗嗦;避免使用冗长的文字给用户反馈。

    1.2.3. 有良好的直觉特征

    l 用熟悉的隐喻为用户的任务提供直接而直观的界面。通过允许用户利用他们的知识和经验,隐喻使得预测和学习基于软件的表示的行为更加容易。

    l 在使用隐喻时,不需要将基于计算机的实现局限在真实世界的对应物上范围之内。例如,与其基于纸张的对应物不同,Windows桌面上的文件夹可以被用来组织各种对象,例如打印机、计算器、以及其他文件夹。同样,Windows文件夹可以其真实世界对应物不可能的方式被排序。在界面中使用隐喻的目的是提供一个认知的桥梁;隐喻并不以其自身为最终目的。

    l 隐喻支持用户认知而不是记忆。用户记起与一个熟悉的事物相关联的意义要比他们记起一个特定命令的名称要容易得多。

    l 同常见软件保持一致性。出色的用户界面在程序中将实现同用户以前用过的其它成功软件一致的动作。

    1.2.4. 较快的响应速度

    l 保持界面能很快对用户操作作出反应。

    l 提供快捷键。特别对于有大量录入项的界面,能让用户不使用鼠标即可完成快速数据录入。在用户界面中加入一些功能,这些功能可以让熟练用户在不同的区域快速的输入数据。这些功能包括重复功能、快捷键、带有有意义的图标的按钮等等,所有这些可以使速度快的用户可以控制界面并加快数据的输入。

    l 除非必要,不要重绘屏幕。

    1.2.5. 简单且美观

    l 简单。界面应该很简单(不是过分单纯化)、易于学习、并且易于使用。它还必须提供对应用程序的所有功能的访问。在界面中,扩大功能和保持简单是相互矛盾的。一个有效的设计应该平衡这些目标。支持简单性的一种方法是将信息的表示减少到进行充分交流所需的最少信息。例如,避免命令名和消息的文字描述。不相关或冗长的句子扰乱了您的设计,使得用户难以很容易地提取重要信息。另一个设计简单而有用的界面的方法是使用自然的映射和语意。界面元素的排列和表示影响它们的意义和关联。简单还与熟悉相互关联。熟悉的事物通常似乎更简单。尽可能尝试建立利用用户已有的知识和经历的联系。您可以使用渐进揭示来帮助用户管理复杂的事物。"渐进揭示"涉及到仔细的信息组织,以便只在恰当的时候才显示信息。通过隐藏向用户表达的信息,您减少了用户必须处理的信息数量。例如,您可以使用菜单来显示操作或选择的列表,还可以使用对话框来显示一组选项。渐进揭示并不意味着对显示信息使用非传统的技术,例如需要一个修饰键作为访问基本功能的唯一方法,或者强迫用户通过一个更长的分级交互序列。这会使用户界面更加复杂和麻烦。

    l 美观。可视设计是应用程序界面的重要部分。可视属性提供了非常好的印象,并传达特定对象的交互行为的重要线索。同时,出现在屏幕上的每一个可视元素也是很重要的,它们可能竞争用户的注意。提供清楚地促进用户对表达的信息的理解的连贯环境。图形或可视设计器的技巧对于这一方面是无价的。

    1.3. 细节约定

    1.3.1. 界面风格

    1.3.1.1. 普通外观

    l 使用一致性一致的外观将使用户界面更易于理解和使用。用户界面控件看起来应该是一致的。

    l 使用安排和流程在西方文化中(包括中国),人们习惯于从左到右,从上到下进行阅读,因此,应该将重要信息放在上面和左边。左上角最容易吸引起人们的注意力。

    l 使用对齐通常,使用左对齐来使用户界面控件更易于浏览。对于数值文本,应该使用小数点对齐或右对齐。对于非数值文本,应该避免使用右对齐或居中对齐。不必对什么都使用中间对齐,或者使它们保持对称形式。在右边或底部保留空白区域更适合习惯。

    l 使用分组将相关的用户界面控件分成组,以体现它们之间的关系。同时,还要显示相关信息。将控件放在它所作用的对象旁。使用空格、分组框、线条和标签,或者其它分隔符对用户界面控件进行分组。

    l 使用强调使用焦点、位置、分组、层次、启用/禁用、大小、颜色或者字体等,来将注意力集中在需要首先看到的用户界面控件上。尽量以可视的方式指明用户接下来应该进行的操作。

    l 使用可视的提示尽量使用近似的大小和间距来指出用户界面控件是相似的,而使用不同的大小和间距来指出用户界面控件视是不同的。

    l 使用空格使用空格来创建一个"透气室",以使窗口布局更易于理解,并且查看起来更舒服。空格的多少要适当,不要显得太分散。但是,要避免过多地使用空格。如果可能,尽量使窗口小一些。

    l 警惕空洞不要到处粘贴公司或产品的名称及徽标。虽然在启动屏或"关于"框中出现公司或产品名称及徽标是完全可以接受的,但其他窗口中的可用空间应该出现其他内容。如果没有其他内容,那么应尽量使窗口小一些。

    l 注意大小使用用户界面控件的分辨率具有独立性。使用系统规格(使用GetGystemMetrics API 函数)或文本规格(使用GetTextMetrics或GetTextExtentPoint32 API 函数)来确定用户界面控件的大小。任何显示文本的对象(如对话框或定义的文本文档)都应该使用文本规格。

    l 考虑使用资源或预定义的布局网格资源模板或预定义的布局网格有助于您在不同的窗口之间实现一致性。

    注意,下页所示图的第二个对话框,与第一个不同,它有一个紧凑、从左到右、从上到下的流程,并且,左对齐的标签很便于浏览;通过对齐编辑框并调整其大小,使它显得更有组织,更加平衡。

    不合理的

    平衡的对话框

    1.3.1.2. Windows的可视提示

    暗示与用户只需通过查看可视提示来确定对象的使用方式的能力有关。在Windows中,请保持使用下面的可视提示:

    l 可以单击凸起的项目。

    l 可以单击当鼠标从其上移过时突出显示的项目。

    l 不能单击下凹的项目。

    l 可以编辑具有白色背景和闪烁垂直条(光标)的项目。

    l 不能编辑具有灰色背景的项目。

    l 灰色项目是被禁用的。

    l 可以拖动凸起的项目。

    1.3.1.3. 交互

    l 尽量提供对所有功能的键盘访问理想情况下,除了绘图这样的图形功能,其他所有的功能都应该只能通过键盘来访问。

    l 尽量提供对所有功能的鼠标访问理想情况下,除了文本输入外,其他所有功能都应该只能通过鼠标来访问。

    l 确保具有明显后果的操作要求用户进行明确的选择*用户需要完全明确他将要进行危险性操作或破坏性操作。

    l 对于使有耗时的操作都给出反馈*在进行长时间的操作时,要确保有等待光标、进度表或其他的可视反馈。用户应该能够取消长时间的操作。如果可以取消未完成的操作,那么将按钮标记为"取消",否则将按钮标记为"停止"。

    l 可视的指示模式*向用户提供一种可视的反馈,以指出用户进入一种模式,通常可以通过更改光标或标题栏文本来做到这一点。

    l 确保单击和双击的一致性*单击用于非按钮选定,而双击用于选定并执行默认操作。换句话说,双击(在列表框、组合框,或其他接受双击的控件中)的效果应该与选定控件中的一个项目,然后按下Enter键的效果一样。

    l 鼠标右键仅用于快捷菜单*确保鼠标右键仅用于快捷菜单,而不要用于其他用途。

    l 不要使用鼠标中键*如果用户的鼠标有中键,那么让用户使用"控制面板"中的"鼠标"实用程序自己分配中键的行为。

    l 保持分配的快捷键的一致性组合功能键和Ctrl键用于快捷键。习惯上不将Alt键用于组合键,业务Alt键常常被用于访问键。尽量避免使用Alt键和Ctrl键,因为这种组合会使快捷键非常麻烦,而且也很不方便。

    l 将快捷键作为补充方式*千万不要将快捷键作为访问命令的唯一方法。应该让用户有更多的明显选择。

    l 避免水平滚动条与垂直滚动条不同,水平滚动条并不受欢迎,因为它会使项目阅读起来比较困难。解决的办法有:尽量使用垂直滚动条、加宽窗口、减小文本的宽度,或者使文本自动换行等。当然,如果确实需要,还可以使用水平滚动条。

    1.3.1.4. 程序

    l 只有主程序窗口才有标题栏图标、菜单栏、工具栏和状态栏*因为单击主窗口的任务栏按钮也会激活二级窗口,所以二级窗口绝对不要显示在任务栏中。二级窗口不要因为使用菜单栏、工具栏或状态栏而使其变得复杂。可以使用标题栏图Subtopic

      Subtopic

    标来明显区分主窗口和二级窗口。另外,绝对不要使用默认的Windows图标(飘动的窗口图标)作为窗口图标。

    l 简化默认配置让用户按自己的速度来学习和使用程序。

    l 应用程序应该使用多文档界面(MDI)或单文档(SDI)这些程序界面应该与应用程序的使用模式匹配。

    l 默认情况下,应用程序应该保持为最大化当应用程序占用整个屏幕时,常常能够提高用户的工作效率。

    l 实用程序应该使用SDI或对话框界面这些程序界面应该与实用程序的使用模式匹配。对于实用程序,建议不要使用MDI界面,因为管理这些窗口需要付出很多努力。

    l 实用程序应该在小屏幕范围内运行实用程序常常与其他程序一起运行,因此它们需要在小屏幕范围内运行。实用程序应该有灵活的窗口布局,以适应多种不同的大小。实用程序很少以最大化的形式运行。

    l 使用实际文档的SDI程序必须支持运行多个实例*运行多个实例使用户能够同时操作多个文档。

    l 使用"退出"命令终止程序使用"退出"终止程序;使用"关闭"移走主窗口和非模式对话框;使用"取消"移走模式对话框。当关闭主窗口并不表示终止进程时,对于主窗口使用"关闭"来代替使用"退出"。例如:关闭打印机状态窗口不会取消打印任务。

    1.3.1.5. 默认

    l 保存和恢复用户选择程序应该能够恢复到其最后退出的状态。MDI程序应该能够恢复文档窗口的大小和位置。对话框通常应该使用最后输入的值作为默认值。

    l 提供适当的默认值提供提供适当的默认值来减少用户不必要的操作,从而帮助用户完成工作。提供最可能使用并给出设置实际使用方式的默认值。通常,最好的默认值是用户最后输入的值。

    l 考虑选择默认值时的安全性* 不应该将不可恢复或破坏性的操作设置为默认值。不要使用令用户感到莫名其妙的默认值。

    1.3.1.6. 窗体

    对话框窗体大小尽量不要超过640*460,留20给任务栏。并且高和宽(或W宽和高)的比应该大致保持为3:4(或4:3)。一般应该将窗体的"Position"属性定义为 "poDesktopCenter","WindowState"属性为"wsNormal",某些主界面设置为"wsMaximized"。"ShowHint"属性设为"True"。如果是模式对话框,则将"BorderStyle"属性设置为"bsDialog"。

    窗体文件(*.dfm)保存为文本格式,以便在VSS中比较不同版本之间的差别。如果窗体大小超过屏幕大小,则在Delphi开发环境中打开时,大小会有改变,并且影响到运行时刻效果。由于每个人的屏幕大小设置不一样,有些是1024*768,有些是800*600,因此在设计期间请注意窗体大小,尽量不要超过800*600,以免出现上述问题。

    

    1.3.1.7. 布局和间距

    窗体控件布局和间距尽量保持与Windows标准一致。控件与窗体的上、下、左、右边距为7象素。右下角主命令按钮之间的间距为6象素,如果主命令按钮在右上角,之间的间距则为4象素。主命令按钮一般情况为75×21象素,如果按钮的文本很长,应该适当加宽按钮的宽度。如下图。其它详细资料请完全参照错误!书签自引用无效。和命令按钮。

    控件的"TabOrder"属性值应该与控件排列顺序一致,即遵循从上到下、从左到右这样一个流程。如果在PageControl的多个页面中存在类似的控件,应该尽量使得它们在各个页面中出现的位置/大小比较一致,以免在页面间切换时产生闪烁感。

    1.3.1.8. 图标、图片

    不同界面中的同一功能应该使用同样的图标和图片。图标、图片的色调、风格尽量保持一致。图标、图片的隐喻应能确切表示功能的含义,如果不能,就直接使用文本,以免混淆用户。如果功能是一个动作时,可能比较难找到确切表示该功能的图标,这时应该尽量采用此动作相关的名词做图标。例如Windows中的"剪切"功能就是用一把剪刀来表示的。

    1.3.1.9. 提示信息(Hint)

    工具栏按钮应该设置工具提示 "Hint" 属性。Hint能帮助用户更方便地理解和使用。详细资料可以参照工具栏、工具提示。

    如果使用了"TSpeedButton"控件,并且只有图标,同样应对它设置"Hint"属性。如果不是特殊情况,应尽量避免使用"TSpeedButton"控件,而使用"TButton"控件代替。

    1.3.1.10. 标点符号

    在标识控件用途的标签文本(Label)和提示信息(Hint)中,应使用半角符号。如果是指导性标签文本(如解释按钮功能的句子),则使用全角符号,并且句子应遵循中文标点符号标准。如下图Microsoft标准对话框例子。其他详细资料可参照静态文本。

    1.3.1.11. 对话框

    l 对话框应该在所有视频模式下都能够正确显示当在VGA模式(640×480)下显示时,对话框应该不超过640×460(留20像素给任务栏)。这将确保对话框能够显示在所有的视频模式下。

    l 确保模式对话框的模式*确保使用具有父窗口的模式对话框都提供正确的父窗口句柄,而不时提供NULL句柄。如果没有提供父窗口句柄,那么父窗口仍处于活动状态,因此该对话框实际上并不是模式对话框。

    l 不要使用可滚动的对话框*也就是说,不要使用需要滚动条来进行完全查看的对话框。这种对话框使用起来非常不方便,并且也时完全不必要的。应该重新设计这种对话框。

    l 不要在作为二级窗口的对话框中使用菜单栏*使用这种对话框需要付出很多努力。注意,在用作主窗口的对话框(如"查找"实用工具)中,菜单栏时可以接受的。还要注意的是,在所有对话框中,快捷菜单和菜单按钮都是可以接受的。

    二级对话框不要使用菜单栏,但可以使用菜单按钮。

    l 不要在作为二级窗口的对话框中使用标题栏图标*标题栏图标用于区别主窗口和二级窗口。

    l 不要在任务栏上显示作为二级窗口的对话框*注意,单击主窗口的的任务栏图标也将激活二级窗口。

    l 对话框中使用下页图所示的页面布局和间距。

    l 对于相似的对话框,使用控件位置来强调其相似性。如果意义相同的同一控件出现在一些相似的对话框中,那么它应该显示在相同的位置。另一方面,应避免将可能会产生混淆的不同控件放在同一位置。

    l 对非模式对话框最好使用可停放的对话框可停放对话框在功能上与非模式对话框是等效的,但其位置设置更为灵活。

    l 策略地设置输入焦点将最初的输入焦点设置在最可能首先使用的控件上。

    l 在对话框标题文本中不要出现省略号例如,作为选择"打印选项…"命令结果而显示地对话框的标题应该为"对于选项"。但是,表示命令正在执行过程中菜单对话框(如"连接到Internet…"对话框)是一种例外情况。

    l 为所有可处理访问键的控件分配访问键*访问键可以使用户的手保持在键盘上,从而使访问程序更加方便。您可以直接在其标题中为诸如命令按钮、单选按钮、复选框等控件分配访问键。通过提供静态文本标签或带有访问键、在Tab顺序上先于控件的组框,您可以为诸如编辑框、列表框、组合框等控件分配访问键。在其他情况下不要为组框分配访问键-这会使人产生混淆。"确定"按钮没有访问键,因为在作为默认按钮时,它通过提Enter键来选定的。"取消"按钮也没有访问键,因为Esc键预览清除模式对话框。如果可能,避免使用小写的g、j、p、q或y作访问键,也避免使用这些字母前后的字母作为访问键。下划线不能与这些字母的下行字母分开。当然,访问键必须是唯一的。

    l 避免使用粗体文本尽量少使用粗体文本。在Windows 3.1 的对话框中,粗体文本用于在旧式的视频硬件上绘制被禁用的文本(即抖动的灰色文本)。因为现在的视频硬件可以绘制没有抖动的灰色文本,所以Windows 为了使外观更加清洁,现在Windows 在对话框中使用正常文本。粗体文本仅用于强调。对于大多数对话框不要粗体文本。

    l 提供环境敏感的帮助对于复杂的对话框,应该为整个对话框提供环境敏感的帮助(通过帮助按钮或F1键访问),或者为个别控件提供控件特定的帮助(通过"这是什么?"按钮或Shift+F1 键来访问),或者同时提供这两种帮助。

    1.3.1.12. 对话框的主要命令按钮

    l 将主命令按钮与对话框主体分开*主命令按钮包括像"确定"、"取消"、"关闭"、"帮助"、"停止"、"隐藏",以及其他相关按钮的等命令按钮。这种分开使主命令按钮更易于查找和识别。

    l 认真选择对话框的方向在西方文化中,人们习惯于从左到右、从上到下进行阅读,因此,将主命令按钮靠底部或右边放置更容易被发现。您应该选择对话框的外观比例与屏幕的外观比例(通常高与宽的比例为3:4)相似的方向。这将使对话框的外观看起来更加舒服,并且更易于在屏幕上进行定位。如果按钮具有不同的大小,那么可以将它们放在对话框菜单底部。当不能确定时,也可以将按钮放在底部,因为这种定位方式最为常见,也更易于阅读。

    l 将排列在底部的主命令按钮右对齐右对齐主命令按钮适合从左到右的阅读习惯。当只有一个主命令按钮时,您或许希望例外地将其居中放置。

    右对齐主命令按钮

    l 避免使用多行或多列的主命令按钮多行或多列的主命令按钮对用户是一个打击。如果有许多主命令按钮,那么注意,通常在右边排成一列与在底部排成一行相比可以放置更多的按钮。另外,您可以考虑使用命令菜单。如果必须使用很多按钮,那么注意使用多行别使用多列的效果好。

    l 对模式对话框,通常提供"确定"和"取消"按钮*要使用对话框,用户需要能够方便地识别前进(使用"确定"按钮)和后退(使用"取消"按钮)的方式。您可以使用更明确的按钮代替"确定"按钮,但绝对不要在模式对话框中替换"取消"按钮,除非用"停止"来表明正在进行的操作无法取消。

    l 对于非模式对话框或或作为主窗口的对话框,提供"关闭"按钮而不提供"确定"和"取消"按钮*将"确定"和"取消"按钮用于非模式对话框或作为主窗口的对话框可以使对话框看起来像是模式对话框。而且,当用于非模式环境中时,"确定"和"取消"时没有什么意义的。使用"关闭"按钮可以消除这种混淆。

    l 通常将"确定"按钮排第一,"取消"其次,"帮助"最后*"确定"或其等价按钮通常作为第一个主命令按钮。"取消"按钮应该位于"确定"的右边或下面。将"确定"和"取消"按钮放在一起。"帮助"按钮应该时最后一个按钮。如果没有"确定"按钮,那么应该将"取消"按钮放在"帮助"按钮的前面。这可以使主命令按钮更易于查找和识别。

    l 确保"取消"按钮真正用于取消操作*当取消时,程序的状态栏应该与之前显示的模式对话框完全相同。如果不是这样,那么应该用"停止"按钮来代替"取消"按钮。模式对话框中的"取消"按钮应该与标题栏中的"关闭"按钮效果相同。而属性表是个例外,因为"取消"按钮不会取消已经应用的更改。

    1.3.1.13. 属性表和属性页

    l 让属性页独立工作避免使一个属性页的行为或操作受其他属性页的限止。用户不可能发现属性页之间的这种独立关系。在属性页的使用顺序方面应该没有限止。用户应该能够随时查看任意的属性页。

    l 属性页的布局相互独立一些属性页通常不会占用同样大小的空间。占用空间较小的属性页应该与最大的属性页的布局的格式方式不同,因为将会产生额外的空间(见下图)。

    属性页的布局保持独立,避免居中。

    l 用属性表代替使用带选项卡的对话框使用属性表而不使用带选项卡的对话框除了具有一致性之外,没有什么明显的实用性优势。另外,对于实际显示对象属性的对话框使用属性表,而对于其他用途,所有带选项卡的对话框。

    l 对属性显示总采用属性表,即使仅有一个页*采用属性表能够明确告诉用户查看的使属性而不是一般的对话框。属性表有一个"应用"按钮来帮助用户测试设置。

    l 绝对不要使用两行以上的标签*最好使用一行标签,但两行也是可接受的,两行以上就太多了,可用级连属性设置或多个对话框代替。

    l 总为属性提供"应用"按钮再说一次,提供"应用"按钮帮助用户对设置进行测试。

    l 对显示属性的属性表总是在其标题中写上"属性"一词和对象的名称*请注意,不是所有的属性表都是用来显示属性的。

    l 总将命令按钮放在右边*适用于所有页的命令按钮必须置于标签页区域的外面,而仅适用于单个页的命令按钮必须置于该标签页的里面。

    1.3.1.14. 向导

    l 对高级的、复杂的或不常用的任务使用向导向导对非常高级或复杂的任务十分有用,省去了用户许多麻烦的操作。当向导用于不常用的任务时,其效果最好。对常用任务使用向导则显得大而不当。

    1.3.1.15. 控件

    l 尽量采用标准控件尽可能采用标准控件(6个最早的控件和新的Win32常用控件)。采用非标准控件的程序与绝大多数Windows程序看起来不一致。只用完全合理时才使用自定义控件。

    l 定制标准控件时要小心改变标准控件的标准外观或行为时一定要小心,这是个常常出错的地方。

    l 将无效控件置为不可用*将不适用于当前程序状态的控件置为不可用。

    l 取消不必要滚动条尽量使控件的尺寸足够大,避免使用滚动条。

    1.3.1.16. 命令按钮

    l 采用最小的宽度和标准的高度带文字的命令按钮应该采用50个对话单位(75个像素点)的最小宽度、14个对话单位(21个像素点)的标准高度。尽量将不同大小的带文字命令按钮的个数控制在两个以内。对父窗口拖动(owner-draw)按钮或无文字的按钮(如"…"),其大小可以任意设置,原则是使命令按钮外观简朴一致。高度大于14个对话单位(21个像素点)的按钮看起来不够专业。尽管不限制命令按钮的最大宽度,但宽度超过200个对话单位的按钮使不妥当的。请参阅下图所示关于命令按钮的实例。

    命令按钮大小示例

    l 针对国际化适当加宽按钮尽管50个对话单位(75个像素点)的宽度是适合英语文字的最小宽度,但对需要针对其他语言进行本地化的程序来说,可能就太小了。对于需要翻译为其他语言的程序,将命令按钮的最小宽度定为60个对话单位可能更适合。

    l 将无效按钮置为不可用,以取消报错*绝对不要使可用的按钮仅产生一条出错信息。

    l 总采用省略号来表示需要更多信息*命令中的省略号表示执行命令时需要更多信息,而不是简单的确认。省略号并不表示一定会出现对话框。

    l 绝对不要指定双击行为*用户意料不到命令按钮会响应双击,因此不可能发现这样的行为。

    命令按钮大小使用Window标准75×21象素。一般情况下,"确定"和"取消"按钮的属性设置如下:

    btnOk: TButton

    Caption = '确定'

    Default = True

    ModalResult = mrOk

    end

    object btnCancel: TButton

    Cancel = True

    Caption = '取消'

    ModalResult = mrCancel

    End

    "确定"和"取消"按钮一般被映射为Enter键和Esc键,因此不应该对它们指定访问键,除此以外的命令按钮都应该指定一个访问键。如下图:

    主命令按钮在下

    如果主命令按钮在右上角,应该布置为这样。

    主命令按钮在上

    如有其他不明,请参照命令按钮。

    如果设计期间未指定"ModalResult",注意一定要在按钮的"OnClick" 事件代码中为"ModalResult"赋值。

    1.3.1.17. 复选框

    l 用复选框开关选项,用单选按钮改变模式*用复选框进行选项的开关操作是很有效的,但如果用来将模式改变为另外一种状态就难免让人迷惑了。例如,可用一个复选框来表示是否显示工具栏,但若用复选框来切换打印机的横向模式和纵向模式就会使人糊涂,对横向和纵向模式应该用一组单选按钮代替。

    l 避免一组复选框中选项个数超过8个应该考虑用复选框列表代替,它占用的空间更少,但复选框列表需要滚动时使用就稍稍麻烦了。尽管控件足够或保持与同一窗口中其他复选框一致时,采用复选框时可取的,但大于8个左右的复选框就未免太多了。

    l 考虑将修改组的复选框置于应该分组框中这样的分组使得复选框之间的关系更为明显。

    l 宁可竖向对齐虽然更合适的情况下采用横向对齐或直角对齐也是可以接受的,但竖向对齐的一组复选框更易于浏览。

    1.3.1.18. 单选按钮

    l 避免一组单选按钮中的选项个数超过8个考虑用列表或组合框代替,它们占用的空间更少,但要记住控件使用更麻烦些。尽管控件足够或保持与同一窗口中其他单选按钮一致时,采用单选按钮是可取的,但多于8个的单选按钮未免太多了。

    l 避免使用单选按钮进行开 / 关或是 / 否选择用复选框代替。

    l 总将单选按钮置于一个分组框中*由于单选按钮是一组相互排斥的选项,所以分组框使选择更为明确。

    l 宁可竖向对齐虽然更合适的情况下采用横向对齐或直角对齐也是可以接受的,但竖向对齐的一组单选按钮更易于浏览。

    1.3.1.19. 组合框

    l 总给组合框提供一个标签*必须用标签来表明组合框的用途。

    l 使组合框的下拉列表最少有5行长少于5行的列表就没有可用的滑块,不易于滚动。请注意,如果组合框没有足够的列项来填满列表,那么将自动缩短列表的长度。

    l 避免组合框的列项少于4考虑用单选按钮代替,它们虽然多占空间,但更易于操作。如果空间更为重要或为了保持与同一窗口中的其它组合框一致时,采用组合框则更为可取。

    1.3.1.20. 编辑框

    l 总给编辑框提供一个标签*必须用标签来标明编辑框的用途。如果标签在左边,将标签文字与编辑框文本垂直对齐。

    l 避免有输入限制的编辑框将编辑框用于用户对任何文本的输入或数字编辑框用于数字的编辑。对于输入受限的情况,使用其他的控件,如组合框、列表、滑块和微调框。对于日期和时间,使用日期和时间拾取控件。

    l 用微调框和浏览按钮使编辑框可视微调框和浏览按钮是简单的可视机制,它们帮助用户在编辑框中进行有效的输入。避免让用户必须输入。仅对数字编采用带微调框的编辑框,对于文本,使用组合框代替。

    l 按期望输入来设置编辑框的宽度编辑框的宽度是对期望输入的可视提示。例如,如果用户是输入地址,两个字符宽的State字段明显暗示用户输入两个字符的州名缩写。如果期望的输入没有特别的大小,就选择与其他编辑框或控件一致的宽度。

    l 总采用数字编辑框用于数字输入*当用户在数字字段中输入非数字文本时,不应该有任何出错消息。

    1.3.1.21. 滑块

    l 总给滑块提供一个标签* 必须用标签来标明滑块的用途。而且,滑块还应该有标明高、低值意义和当前选择的标签-当然都不带冒号。

    1.3.1.22. 静态文本

    l 左对齐静态文本标签左对齐使得标签外观更有条理,且易于浏览。

    l 宁可将静态文本标签置于相关控件的左边,而不是上面这样对齐使标签更易于被发现,且方便了标签和控件的浏览。很明显,长控件是例外情况,如列表视图、树形视图(Tree)和多行编辑框。

    l 总在用于标识控件的静态文本标签后带上冒号*使用冒号明显表示为控件标签的文本。为控件提供附加信息的标签不应该有冒号,如用来解释滑块控件的标签。标签也可作为屏幕读出器的输入信息。

    l 对非标签文本总用只读编辑框*  只读编辑框允许用户将文本复制到剪贴板上,并在文本比控件长时可进行滚动。

    l 不要把静态文本置于凸起的边界上*在凸起边界上的静态文看起来像按钮,因而用户会试图单击它。

    1.3.1.23. 列表框

    l 总给列表框提供一个标签*必须用标签来标明列表框的用途。

    l 使列表框至少5行长少于5行的列表没有滑块,不便于滚动。如果列表框没有滚动条,那么使用一个更短的列表框也是可以接受的。

    l 对多个选择考虑采用复选框复选框列表可以突出其多个选择的能力。如果不能接受复选框列表,那么可以采用多选列表,并用静态文本表示选项个数,清楚指明可进行多项选择。

    l 对多选列表考虑提供"全部选中"和"全部取消选中"命令由于希望全部选中或全部取消使常见的事情,所以这两个命令方便了用户进行多项选择。

    1.3.1.24. 列表视图

    l 总给列表视图提供一个标签*必须用标签来标明列表视图的用途。

    l 使列表视图至少5行长少于5行的列表视图没有滑块,不便于滚动。如果列表视图没有滚动条,那么使用一个更短的列表视图也是可以接受的。

    l 仅在列表可排序时采用可单击的表头*可单击的表头只应用于排序。首次单击时应按正序对列表进行排序,而第二次单击时按反序进行排列。

    l 对列项大约超过30的列表视图总使其可进行排序*用户能够对列表进行排序方便了对信息的查找。

    1.3.1.25. 滚动条

    l 滚动条仅用于滚动*使用滑块或微调框来设置数值。

    l 使滚动条足够长,保证有可用的滑块。没有滑块的滚动条不便于使用。

    1.3.1.26. 分组框

    l 利用分组框分组相关控件尽管分组框通常是用于单选按钮的分组,但也可用于任何控件的分组。避免使用只有一个控件的分组框,除非是为了保持与同一对话框中其他分组框一致。

    l 考虑采用静态线或文本标签来代替分组框分组框多时要占去许多空间。如果空间紧张的话,一个替代分组控件的好办法是同时采用静态文本标签和静态线。

    考虑采用静态文本标签和静态线代替分组框

    l 不要在分组框标签的后面使用冒号*分组框标签的意思明白,使用冒号完全没有必要且让人糊涂。

    1.3.1.27. 菜单

    l 总用单个单词作为菜单标题*菜单栏上多个单词的菜单标题看起来像多个菜单标题。

    l 不要在菜单栏的文本间留有空隙*不一至的菜单栏文本既无用,又难看。

    l 避免占多行的菜单栏*尽管将父窗口缩小到足够窄时,任何菜单栏都要占用几行,当要避免正常使用时因菜单项都而占用几行的菜单栏。

    l 保持菜单稳定*将无效菜单置为不可用,而不要删除它们。但是,对整个程序实例都无效的菜单,就应该删除。

    l 合理安排菜单项的顺序将相关菜单项组合在一起。重要的命令应该位于菜单的顶部,而不重要的菜单则位于菜单的底部。

    l 将无效菜单置为不可用来代替报错*菜单绝不应该有仅产生出错消息的可用命令。

    l 分配访问键*访问键使用户可以手不离开键盘进行操作,并提供程序的可访问性。尽可能避免用小写字母g、j、p、q、y或单词中与它们靠近的字母来分配访问键,因为下划线与下一行的字母不好区分。当然,一个菜单中的访问键应该是唯一的。

    l 总采用省略号来表示需要更多信息*命令中的省略号表示执行时需要更多的信息,而不是简单确认。省略号不表示一定有对话框出现。

    l 使用标准菜单避免不提供"文件"、"编辑"和"帮助"菜单。由于这些是标准菜单,所以用户会期望它们出现。例如,期望在"文件"菜单中发现像"打印"和"退出"这样的命令,虽然这些命令可能与"文件"无关。同样,用户期望在"编辑"菜单中发现"剪切"、"复制"和"粘贴"命令,至少要在"帮助"菜单中发现"关于"命令。

    l 统一放置"查找"和"选项"命令总将"查找"命令放在"编辑"菜单中,而有"工具"菜单时,总将"选项"置于其中,否则置于"查看"菜单中。

    l 用复选标记来开关选项,用单选组来改变模式*用复选标记进行选项的开关操作是有效的,但如果用来将模式改变为另外一种状态就难免让人迷惑了。例如,可用一个复选标记来表示是否显示工具栏,但若用复选框来切换打印机的横向模式和纵向模式就会使人糊涂,对横向和纵向模式应该用一个单选组来代替。

    l 不要使用多列的下拉菜单*多列增加了菜单不必要的复杂性。

    l 不要使用"Bang"(爆炸的声音)菜单*Bang菜单是菜单栏上那些看起来像下拉菜单,但实际是选择后立即执行的命令,如"退出"!显然,用户希望菜单标题就只是菜单,而不是命令。

    l 不要右对齐菜单标题*这样的菜单风格陈旧且不易于使用。

    1.3.1.28. 上下文菜单

    l 考虑将上下文菜单作为冗余使用上下文才菜单不应该是访问命令的唯一方式。通常上下文菜单中的命令应该在菜单栏中也提供,使用上下文菜单是为了提高访问效率。

    l 避免在上下文菜单中包含快捷键应该将快捷键分配在菜单栏中,上下文菜单的快速访问是通过鼠标进行,而不是通过键盘。

    1.3.1.29. 工具栏

    l 保持工具栏稳定*将无效的工具栏按钮置为不可用,而不是将它删除。但是,应该考虑删除用户进入一种模式用不到的整个工具栏。

    l 将无效命令置为不可用,而不是报错*工具栏绝不应该包含只出现错误消息的命令。

    l 对实用程序采用大工具栏按钮好的使用程序工具栏常常与应用程序的按钮不同,其按钮更简朴,更大。实用程序工具栏应该只包含几个带有描述性文字和图形的显眼命令。

    l 对应用程序采用可移动的、可定制的工具栏,而对实用程序采用固定的工具栏应用程序需要灵活的工具栏来支持其典型的使用方式。用户使用实用程序的时间一般不长,因而不需要定制工具栏。

    l 提供显示或隐藏工具栏选项如果有多个工具栏,分别为它们提供显示或隐藏的选项。

    l 总使用工具提示*工具提示帮助用户了解工具栏按钮的作用。

    1.3.1.30. 工具提示

    l 用工具栏的工具提示来提供信息,但要简短避免提示很明显的事情。考虑采用省略号来表示执行命令时需要更多信息。如果该命令已分配有快捷键,则显示该快捷键。

    l 使工具提示文本成为高级用户的媒介工具提示用于简短的识别和提醒,而不是用来教学。

    l 用工具提示显示有用信息不仅仅可在工具栏上使用工具提示,它的使用简单,能够向用户提供有用信息。但不可滥用-工具提示太多也就失去了其价值。不要对命令按钮会静态文本这样的控件使用工具提示。

    l 不要自动消去包含许多文字的工具栏提示默认时,10秒种后工具提示将自动消去。如果工具提示的文字很多,10秒钟对用户来说就看不完了。

    1.3.1.31. 文本

    l 避免不必要的缩写词要么给文本更多的空间,要么改写文本使其占用更少的空间,缩写词使文本不易理解。

    l 避免不必要的大写字母文本除非只去首字母构成的缩写词,否则不要用字母全为大写的单词,这样的单词看起来像在冲用户大喊大叫一样

    l 避免复杂的标号尽量采用简单的标点,如句号、逗号、问号,以及破折号。避免使用分号、感叹号、圆括号、括号,等等。

    l 采用一致的大小写规则*对窗口标题、菜单、命令按钮、列标题属性页选项卡以及工具栏提示文字采用与书题一样的大小写规则,而对于标题、单选按钮、复选框、分组框和菜单项帮助中的文本采用与句子一致的大小写规则。(对于标题,除了不是标题开头和结尾的冠词和介词外,每个单词的第一个字母大小。对于句子,每个句子的第一个单词以及通常大写的单词-如专有名词的首字母大写。)

    l 避免不好的背景将文本放在实地、颜色适中的背景上,确保在文本和背景之间存在良好的对比。

    l 避免冒犯性语言避免激烈的词语,如fatal(致命的)、execute(执行)、kill(杀死、毁掉)、terminate(终止)、和abort(中止)。

    1.3.1.32. 消息框

    l 仔细选择消息框的类型采用带"确定"按钮的信息消息框向用户提供有关命令结果的信息。采用带"是"、"否",以及可能"取消"按钮的警告消息框在继续进行前需要用户输入的情形下告诫用户。采用危急消息框通知用户进行工作前需要修改一个错误。

    l 不要使用疑问消息框类型*不再推荐对消息框使用疑问标记符(MB_ICONQUESTION),因为它在Windows98后一致用来表示上下文修改帮助。

    l 避免不必要的消息框不要用出错消息来报告正常行为,而应该用来报告不正常或不期望的结果。不要对很容易恢复的操作进行确认。

    l 问用是/否回答的问题问用户问题时,采用"是"和"否"按钮代替"确定"和"取消"按钮,这样使问题易于理解。与对话框中不一样,"确定"和"取消"按钮很少同时用在消息框中。

    l 确保消息框选项按钮与文本一致例如绝不要用"是"和"否"来作为非提问消息的响应。同样,不要使用多个效果相同的选项按钮。例如,除非有不同的操作结果,否则不要同时提供"否"和"取消"按钮。"否"按钮应该执行操作,而"取消"应该取消操作。

    l 仔细选择默认按钮将最安全的或最常用的选项作为默认按钮。

    l 避免无用的帮助除非提供真正有用的附加信息,否则不要提供"帮助"按钮。不要附加带无用帮助信息的没意义的消息框。

    l 对危急错误考虑采用系统模式消息框采用系统模式消息框向用户提示严重的、可能造成破坏性的、急需注意的错误。系统消息框除了有WS_EX_TOPMOST样式外,与应用程序模式对话框完全一样。与在16位Windows中不一样的是,系统模式不影响用户与其他程序的交互。

    1.3.1.33. 错误消息

    l 避免错误号除非这个错误号对用户真正有用,否则不要给出错误号。

    l 避免责怪用户避免在出错消息文字中出现单词you(你)或your(你的)。如果需要,当指用户操作时使用被动语气。采用与"错误发生了"等价的表达,比采用与"你捅漏子了"等价的表达要好得多。

    l 避免敌对性语言避免在错误消息文字中使用词语bad(糟糕的、坏的)、caution(小心)、error(错误)、fatal(致命的)、illegal(非法)、invalid(无效)和warning(警告),而应该使用更具体的描述性词语。并且应该尽量解释到底是什么出了错。

    l 在出错消息文字中使用平实的语句表达要简短、清楚、协调、具体。除非缩写词,否则不要使用全部大写的单词,那样的单词看起来像在冲用户大喊大叫一样。使用完整的句子和一般的现在或过去时态。避免缩写词

    l 避免在用户错误消息文字中装做有趣或高人一等用户并不觉得错误消息有趣,故装幽默并不能被广泛接受。

    l 允许用户压制非危急的错误消息对经常出现的非危急错误,向用户提供一个压制该错误消息的选项。

    1.3.1.34. 字体

    字体统一使用以下设置:

    Charset = GB2312_CHARSET

    Name = '宋体'

    Size = 9

    Color = clWindowText

    Style = []

    字符集不要使用 ANSI_CHARSET 或 DEFAULT_CHARSET,否则可能导致不同的操作系统下字符集不一致。

    l 尊重用户的字体选择*Windows允许用户为标题栏、菜单、消息框和工具提示选择字体。及时处理WM_SETTINGCHANGE消息以根据设置迅速而安全地改变字体。

    l 避免让人分心地字体一般说来,应避免使用Arial、Tahoma和MS Sans Serif之外的字体。Verdana、TrebuchetMS和Century Gothic也适合于轻微差别的外观。即使文档中的截线字体很不错,但界面中的任何截线字体都被认为是让人分心的。除了提示用户输入或模拟打字机外,不要采用等宽字体。

    l 避免使用粗体和斜体用粗体来吸引人的注意,用斜体表示着重,但要还少使用。

    l 避免混合字体任何不包含文档的窗口最多包含两种不同的字体。

    1.3.1.35. 颜色

    l 使用系统颜色*尊重用户的颜色选择,避免使用固定颜色。不要强迫用户使用您选择的颜色。避免让人分心的文本颜色,通常是黑色之外任何颜色,对文本使用系统颜色COLOR_BTNTEXT或COLOR_WINDOWTEXT。在白色(COLOR_WINDOW)背景上使用黑色(COLOR_WINDOWTEXT)文字是完全正确的。及时处理WM_SYSCOLORCHANGE消息以根据设置迅速而完全地改变颜色。

    l 根据内容而不是外观来选择系统颜色*不要将作为一个集合中的几种系统颜色混合匹配在一起。例如,不要将COLOR_BTNTEXT和COLOR_WINDOW混合在一起。

    l 考虑对图形使用中间调色板在256色模式下使用中间色调色板避免了调色板的闪烁。

    l 不要用颜色作为传递消息的唯一方式*不依赖于对颜色的区分可以增强程序对色盲用户的可访问性,并且使程序可运行在单色显示器上。

    1.3.1.36. 三维效果

    l 避免不必要的三维效果除非对控件分组,否则避免三维静态线和矩形框。宁可采用空白来分开组件,绝不在三维矩形框周围套其他的三维矩形框。避免使用三维文本。

    三维效果过多

    在界面中采用太多的三维效果是程序员常范的错误。毕竟,如果有些三维效果很酷,对吧?不完全如此。请看下面的对话框。一点也不酷。一旦三维控件流行起来,就好像能使用三维的都采用三维,而不管看起来是好是坏。即使采用三维边框,其目的也是为了让人理解。采用许多三维静态框架控件通常是个坏征兆,现代的趋时是倾向于更为简单的风格。

    l 使用柔和的三维效果请注意Window98中更为细致的三维效果是如何比Window 3.1中的三维效果更有效更悦目的。尽管绝大多数现时世界的物体有加亮区,但很少有黑色实边框的。Windows98仅是通过在突起物体的右边和底部加上黑色边框以及在凹陷物体的上部和左边加黑色边框来达到三维效果。

    去除多余的三维效果

    最少三维效果

    l 使用一致的三维效果*确保三维效果的光源位于屏幕的左上角。

    1.3.1.37. 各种细节

    l 不要发音和闪动没什么比发音和闪动的程序更烦人的了。但闪烁程序的任务栏窗口按钮通知用户未决消息例外。

    l 避免不必要的视频效果至少一个使其为可选择的。理想情形是,默认时关闭这样的效果,用户有明确要求时才打开。

    l 用缩放功能提高文档可访问性提供提供文档缩放功能,可提高显示文档的程序的可访问性和整体性能。

    l 处理WM_DISPLAYCHANGE消息*改变显示分辨率后,程序应该能够正确显示和运行。

    l 基于光盘的程序的应该支持自动播放当光盘插入驱动器后,"自动播放"应该显示一列选项,包括安装。程序安装以后,不应该运行"自动播放"。

    l 支持用户采用日期和时间拾取控件进行日期输入,GetDateFormat和GetTimeFormat函数用于设置货币和数字的格式,LCMapString API用于排序。考虑采用RichEdit控件用于文本输入和输出。最后,利用WM_INPUTLANGCHANGE消息来处理输入语言的改变。

    1.3.2. 统一术语

    1.3.2.1. 术语的重要性

    我们用名称来区别、描述和查找事物,使用名称来分解并理解不熟悉的事物。采用统一的术语有助于我们更好地理解和进行交流-简化并统一用户界面术语有助于用户理解和充分应用我们设计的界面。

    使用不同的术语描述相同的事物是最让人迷惑的,而改变人人都已经熟悉的术语也是有害的。这两种情况都使得程序难以讨论、描述,以及归档。甚至使它难以编程。

    1.3.2.2. 命名

    下面是一些需要命名的、与界面有关的典型对象:

    ● 程序本身;

    ● 程序使用的文档类型;

    ● 用户利用程序执行的主要操作;

    ● 所有的窗口、对话框和属性表;

    ● 主程序窗口中的使用区域;

    ● 认为非标准的屏幕对象、命令、属性、交互、或者技术。

    简而言之,用户可以看到或需要与其进行交互的、显示在菜单、工具栏、窗口、对话框、状态栏、联机帮助或文档中的任何内容都需要有一个名称。当然,您将会使用已存在的标准屏幕对象的名称。例如,您不需要命名常用的对话框,因为它们已经拥有名称。

    1.3.2.3. 用用户的语言说话

    使用软件面向的用户所熟悉的词语,除非您的软件是为了程序员设计的,否则应该避免使用计算机行话,而应用常用的单词代替。例如,对绝大多数用户来说,常用单词"separator"(分隔符)就比技术术语"delimiter"(定界符)要好得多。如果必须使用技术词汇,那么应采用那些用户可能知道的术语。

    1.3.2.4. 要避免的术语

    也有些术语是千万不要用在您的用户界面中的。尽管"execute"执行、"kill"(杀死)、"terminate"(结束)、"fatal"(致命的)和"abort"(中止)这样的术语在程序员文献中是完全可接受的,但完全应该避免出现在其他的文字中。

     

    关于UI规范的几点意见

    2007-04-30 10:07

    今早看了白鸦的一篇博文"什么时候开始整理界面规范"讲的主要是图形界面方面的内容,我也写了几点意见

    1、UI规范分为两个方面:

    a、GUI规范,指导产品GUI设计和GUI编码。

    b、交互设计规范,指导产品设计,着重统一团队意识,作为设计产品交互行为的最高标准。

    这里大家讲的主要是GUI 规范。

    2、GUI规范的制定时间可前可后,但是有两个关键点:

    a、必须在编码之前完成,否则就成花架子了。

    b、GUI规范不是一蹴而就,它和设计相互迭代,彼此补充,相互完善。

    3、GUI规范的内容70%是通用原则,涉及产品图形控件的基本属性和构建的基本参数和原则,30%是与项目或产品特点相适应的内容。这部分内容就是在设计过程中迭代产生。

    4、规范制定不是问题,最大的问题在于执行。必须打破现有的开发流程和组织架构,有专人负责界面编码和界面测试,才能保证规范能贯彻下来。让做逻辑和函数的编码工程师来执行,完全不可控,走样是自然的,因为他不懂,也不在乎,而且他有理由逃避责任。

    5、规范不能直接拿出来执行,篇幅太多,操作有难度。所以必须要让规范落地。也就是说,要有具体的设计文档作为执行的依据。设计文档按照产品设计思路分片分线组织,所有设计文档结合起来就是整合的产品原型。

    所以说,GUI设计、交互设计、设计、规范、原型,执行是一个完整的互动的概念,牵一发而动全身。

    展开全文
  • 三天研读《中兴电路设计规范》精华总结

    万次阅读 多人点赞 2020-05-16 18:25:52
    本博客将简述中兴通讯股份有限公司在原理图设计中需要注意的一些事项,其中包含了中兴设计开发部积累的大量硬件开发知识和经验,可以作为学习使用。硬件工程师可以学习并掌握检查条目的内容以及对条目的详细说明,...
  • APP设计规范

    千次阅读 2019-04-30 13:43:00
    APP设计规范 设计师DPI指南 本指南旨在为初级到中级设计人员提供“入门”或介绍性阅读,他们希望从一开始就学习或获得有关跨DPI和跨平台设计的更多知识。尽可能少的数学和没有不可解析...
  • APP设计:(一)app界面常用设计规范

    万次阅读 多人点赞 2019-07-10 15:55:27
    app设计是一看似简单...经过年的发展逐渐成熟,也逐渐形成一些普适的设计规范,包括布局、各部件尺寸、字体运用等等。虽然说设计要创新,不能一成不变,但考虑到用户的使用习惯,提高用户体验感,在一些趋于统...
  • Android设计规范

    千次阅读 2016-09-08 15:14:43
    准备了半月,思考产品设计、交互设计,见证了公司的产品、UE和开发的撕逼,将自己的思考、感悟,整理成下文,谨代表广大程序猿,向设计狮、产品X开战。希望广大程序猿能够坚持贯彻Google的Material Design,切实...
  • 弹出框设计规范

    千次阅读 2016-06-30 16:21:24
    程序方面 几个容易被忽视的弹框细节 1.背景锁定与滚动条引起的抖动问题 浏览网页时经常会发现弹框出现后,滚动鼠标时,蒙版下面的页面还是可以滚动的,其实这些滚动都是没必要的,因为弹框的原意就是要聚焦用户...
  • MySQL命名、设计及使用规范

    万次阅读 2018-04-03 08:14:46
    sim:模拟环境,开发可读写,发起上线请求时,会先在这环境上进行预执行,这环境也可供部署上线演练或压力测试使用。real:生产数据库从库(准实时同步),只读环境,不允许修改数据,不允许修改表结构,供线上...
  • 过程质量保证PQA的几个关键方面

    千次阅读 2015-01-11 16:12:33
    现在最新的CMMI将其对应的过程域称为产品和过程质量保证,缩写是PPQA,这里面的一P产品包括了最终产物,但其焦点是中间工作产物,所以这P放在这里反而是带来一些混淆,与测试存在一些重叠。所以过程质量保证...
  • 网络基础10 Restful API设计规范

    万次阅读 2017-11-03 19:58:30
    Restful API设计规范总结
  • 软件开发设计规范书的撰写

    千次阅读 2008-08-05 16:30:00
    整个软件开发过程是一个相当复杂的流程,并不是简单的靠几个设计工程师自己在那边写软件就完,而是要从头到尾,包括很多人,不同专家,不同的专业,不同的知识放在一起,最后才造成一个完善的软件产品。...
  • 产品设计

    千次阅读 2014-11-04 13:57:20
    产品设计是一由抽象的概念到具体形象化的处理过程,通过文字或图像等方式将我们规划的产品需求展现出来。它将产品的某种目的或需求转换为一具体的物理或工具的过程,把一种计划、规划设想、问题解决的方法,通过...
  • 现在最新的CMMI将其对应的过程域称为产品和过程质量保证,缩写是PPQA,这里面的一P产品包括了最终产物,但其焦点是中间工作产物,所以这P放在这里反而是带来一些混淆,与测试存在一些重叠。所以过程质量保证...
  • 一些界面设计规范

    万次阅读 2010-03-29 10:16:00
    这样得到的好处:1:使用户使用起来能够建立起精确的心里模型,使用熟练了一界面后,切换到另外一界面能够很轻松的推测出各种功能,语句理解也不需要费神理解 2:降低培训、支持成本,支持人员不会行费力逐个...
  • 华为C语言编程规范(精华总结)

    万次阅读 多人点赞 2020-03-24 09:48:55
    代码的有效组织包括:逻辑层组织和物理层组织两个方面。逻辑层,主要是把不同功能的函数通过某种联系组织起来,主要关注模块间的接口,也就是模块的架构。物理层,无论使用什么样的目录或者名字空间等,需要把函数...
  • 从微信WeUI设计规范 解读移动界面设计 字数1842 阅读11593 评论16 喜欢102 写在开头,以表明动机、甩掉一切可能需要承担的责任。 目的:看到传播很热的微信WeUI,应该说是一种比较简单暴力的表现...
  • 自初春之际着手翻译《iOS11界面交互设计规范》(英文记《iOS Human Interface Guidelines》),迄今已近半载。断断续续,林林总总;终归曙光初现,也算圆满。更幸梳理归整,章节目录也算清晰,得以纵览全文。奈...
  • 技术人员的全面介入,可以简单的看作以“需求分析初稿完成”为界,需求完成以后,派生出几个设计:交互设计、编码设计、数据库设计、测试设计,各自设计完成并执行以后,再部署发布。 具体的说一下,交互设计这块,...
  • 硬件原理图设计规范——基本原则

    千次阅读 2017-12-22 08:37:00
     原理图设计是产品设计的理论基础,设计一份规范的原理图对设计PCB、跟机、做客户资料具有指导性意义,是做好一款产品的基础。原理图设计基本要求: 规范、清晰、准确、易读。
  因此制定此《规范》的目的...
  • 设计规范 逻辑架构、技术架构、分层设计、主题划分、方法论 命名规范 各层级命名、任务命名、表命名、字段命名、指标命名等 模型规范 建模方法、建模工具、血缘关系、维度退化、一致性维度、元数据管理 开发...
  • 前面的几个步骤是为了帮助我们梳理需求、验证可行性和明确细节,到了这一步的时候我们已经非常清晰的了解产品需求,此时撰写产品需求文档可以大大减少和避免了撰写文档时容易忽略的细节黑洞。 产品需求文档是将产品...
  • 1、原理图制图规范 2、电路设计 2.1、通用要求 2.2、逻辑器件应用 2.3、时钟设计 2.4、保护器件应用 2.5、可编程逻辑器件 2.6、电源设计 2.7、其他应用经验 3、可靠性设计 4、信号完整性/电源完整性设计 5、系统相关...
  • 第一部分:APP界面设计流程概要分享,总共11步骤。  1. 确定你的创意方向或者围绕主题展开您的创意是否人做过,如果类似的app,那就要多多考虑,争取超越并且一些独特的优化设计在其中  2. 定位应用和...
  • 模块化是在传统设计基础上发展起来的一种新的设计思想,现已成为一种新技术被广泛应用,尤其是信息时代电子产品不断推陈出新,模块化设计产品正在不断涌现。如何使产品的模块化设计全方位地满足市场的多样化需求,...
  • 标准的产品设计工作流程

    万次阅读 2011-11-08 14:37:24
    个产品团队都会自己的工作流程,无论这工作流程是否最高效、是否体现最大价值,但是我认为只要这流程能够为实现工作目标提供过程的保障就可以算是好的流程。 对于流程本身而言,可以因团队不同或工作任务...
  • 产品思维设计API(一)——RESTful就是骗局前言 最近公司内部在重构项目代码,包括API方向的重构,期间遇到了很多的问题,不由得让我重新思考了下。 - 一优雅的API该如何设计? - 前后端分离之后,API真...
  • 数据库是整个系统的核心,它的设计直接关系系统执行的效率和系统的稳定性。因此在软件系统开发中,数据库...数据库设计是指对于一给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足
  • Checklist设计编写规范及模板

    万次阅读 2019-03-13 23:47:57
    系统的异常对其他系统的影响,异常能否完全捕捉,数据持久层异常(redis,memcache,db异常)           系统...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 115,077
精华内容 46,030
关键字:

产品设计规范有几个方面