用户体验已经成为 衡量应用软件质量的重要标准。在过去我们可能会惊叹于某个Web应用的华丽界面,现在,随着HTML5的强势登场,各类表现层技术及开发框架的发 布,Web与窗体应用的界限正在被逐渐模糊。虽然技术已经焕然一新,但很多开发人员并不是专业的信息架构师,可能还在使用传统的、平凡的UI设计风格。富 应用已成定局,过去难以实现的效果在今天看来已如此简单。本文旨在通过借鉴Web界面设计经验,来探寻系统UI设计的最佳实践。
一 指导原则概述
二 UI设计流程
第一步:理解需求并了解我们的用户
一个系统的开发与实施一定有明确的目标。开发系统的第一步就是要理解用户需 求。需求分析的工作一般由PM领导,主要由需求顾问完成。我们通过与用户访谈,旁观用户的工作,咨询行业专家或借鉴各类相关数据来得到用户场景。通过对用 户场景的分组,过滤,以及挖掘,我们可以得到用户的角色以及不同角色对系统的需求。
了解系统中的角色,以及他们之间的关系。在设计UI前,我们应该知道这些角色 能够做什么,期望做些什么以及不能做些什么。我们要了解这些角色的主要任务,并深入研究他们的工作习惯、知识层次以及他们理想中的软件应该是什么样子。与 这些代表不同角色的关键用户交谈,为他们每一个人编写一个场景来描述他们理想中的最佳体验是个不错的方法。作为设计者来说,我们必须清楚用户的习惯。在某 些行业,可能从业者所希望的界面风格是常人无法理解的,但对于该角色确实是可行的。这些信息,如果不与用户面对面的沟通,恐怕很难从文档中获取。
一般步骤如下:
补充:需求分析很多时候有业务顾问担任,但根据项目规模,可能这部分责任也会落在你的身上。下面分享“5W1H”,供读者借鉴。
What 用户要做什么?用户的期望是什么?
Why 用户的目标什么?用户为什么有这样的想法?
Where 用户处在何种场景活应用环境中使用系统?
When 用户什么时间使用这些功能?
Who 谁在使用这一系统?他们有什么差异?他们的习惯有何不同?
How 用户的业务流程是什么样的?系统如何帮助用户完成任务?
第二步:定义功能,划分模块
进入这一阶段表示需求已经被分析并定义。UI设计者应该确认以下事项是否已经清晰:
如果上述问题还存有疑问,那么就应该停下来把前期工作做好。
一般步骤如下:
第三步:设计全局导航与局部导航
导航与标识的设计体现了设计者对复杂事物的组织能力。导航与标识往往密不可 分,很多时候导航就在充当标识。标识如同系统中的地标,帮助用户了解:他们身在何处,他们的目的地在哪,以及他们如何完成操做等。在大型系统中,标识帮助 用户不会迷失。导航则帮助用户迅速达到目的地。
有3类导航,分别为:
导航有2类模式,分别为:
一般步骤如下:
“用例图”和“系统 结构图”都能反映出系统的功能结构。但是,它们都无法反映出用户如何使用系统。“路径图”反映了用户如何使用系统,包含了业务逻辑,以及各功能模块之间的 调用关系和数据流向。“路径图”显示了用户完成任务,需要在系统中行走的路径,就如同地图一样,反映出不同功能的复杂程度。
通过分析“路径图”,我们可以通过合并模块来将过程冗长的路径缩短,或者通过增加模块,更加详细地分解活动,实现更细粒度的控制和授权。但这一切的修改,都应该与关键用户共同来完成。
确定导航栏的位置 放在顶部可以增加内容区域的面积,但是导航条目过多时,一行就放不下了。放在左侧,可以增加导航栏的面积,可以放入比横行更多的按钮,但是会减少内容区域的面积。两者给有所长。需要根据需要选取。
设计导航树 设计导航树要考虑两个问题。第一,导航树要适合进行权限控制。第二,导航树的层次要便于用户使用,一般常用功能的排列靠前,还有考虑树的深度,太深了会增加用户的记忆负担。
首先,要确定局部导航的形式,可能的形式包括:包括在Logo中添加链接,在数据查询结果集中添加链接,“面包屑”等。
然后,确定局部导航的规模,局部导航过多会使系统路径相对复杂,增大开发工作量。因此,应该压低局部导航的数量,力争做到简单实用。
具有动画的导航具有 更高的用户体验,而且对于数据需要延迟加载的导航来说,动画效果是必须的。然而,使用的场合要区别对待,并不是效果越绚丽越好。动画只需要流畅并能够个用 户以反馈就好,毕竟对于应用系统而言,业务处理才是其核心价值,不能浪费项目组的宝贵资源来打造一个“花瓶”。
第四步:界面设计
界面设计最简单的方法就是参考同类系统的UI设计,结合实际项目和用户需要 进行调整。界面设计有极大的自由度,因此也带来的一定的风险。设计者需要很强的业务知识,如果缺乏对用户工作的了解,很可能无法理解用户的真正期望。因 此,调研和沟通非常重要。界面设计长犯以下错误:
问题 | 描述 | 解决方法 |
少字段 | 这类错误经常在后期开发阶段才能发现,即便是使用原型向用户演示,常人也很难发现缺少某些数据。 | 在设计界面时,就严格筛选界面包含的实体及其属性,考虑数据的收集和流向问题。 |
界面假死 | 当程序执行某个耗时的操作时,没有给用户以反馈,用户错误认为系统down掉了,此时有些用户不会耐心地等待系统反馈,而是以设计者难以预期的方式操作。 | 使用动画来提示用户系统“忙”。 |
风格凌乱 | 当多位设计人员参与到界面设计时,容易发生风格不统一是事情,如样式差异,多种同义词,处理方式的不同等。 | 约定规范,统一风格,由责任人负责统领全局。 |
有去无回 | 某些操作完全是单向的,一旦进入无法返回,UI设计没有为用户提供相反的操作路径。 | 严格审核“路径图”。 |
歧义 | 同一界面中多个标识指向相同的位置,让用户感到迷茫。 | 减少不必要的局部导航。 |
无法实现 | UI设计人员不了解开发技术,错估技术难度,设计了超出成本或超过开发团队能力的界面。 | 技术人员参与UI设计。 |
海量信息 | UI给用户呈现了过多的数据,让用户感觉到系统难以使用,并且极大地破坏系统的美观程度。 | 优先“隐藏”而非“禁用”;展示用户期望的数据;分层次展示数据。 |
大量的手工输入 | UI没有帮助用户完成信息的采集,没有进行验证,也没有试图减少用户使用系统的工作量,造成用户在录入数据上过多地承担责任。 | 让系统尽力分担用户工作,减少用户使用系统时的工作量,并对用户信息进行验证,对错误进行提升。 |
缺少提示 | 用户在进行某些重要操作时,UI没有尽到提升义务,易造成用户使用时无意识地破坏数据。 | 确认对话框。 |
臆测界面 | 设计人员从自己使用系统的角度出发来设计界面。由于缺少业务经验,往往会与用户期望发生偏差。 | 沟通,沟通,以及沟通。 |
无序且没有重点 | UI的标识不明显,没有起到引导用户的作用,导航栏显得没有秩序,用户看不出当前界面有那些重点。 | 为功能需求排序,常用功能应该得到更好的位置。 |
第五步:界面分割与整合
第六步:开发原型->演示->收集反馈->改进
以用户为中心设计系统的很重要的一步就是收集用户反馈。完成原型开发,并及时向用户演示,与用户频繁地交流,共同测试系统原型,能有效促成UI的高可用性。
三 设计图标
图形隐喻就是通过图形暗示用户的一种技巧。比如Windows里的回收站,历 代Windows系列产品,只要我们看见那个“垃圾桶”我们就知道那是回收站。可见,好的UI,往往需要对图标进行定制化设计,使其包含某种隐喻来引导用 户使用系统。图形隐喻可以推广到整个UI设计,不仅仅是图标设计,尤其是在游戏软件中。令我深有感触的就是《星际争霸II》,其UI设计无疑增加了游戏整 体的用户体验。但是,使用图形隐喻存在一定风险。UI设计者的个人看法,如果与大多数的人有偏差,就会适得其反。毕竟,我们做的仍然是应用软件而不是游 戏,不会有强大的美工和设计团队,在我们追求前卫设计的时候,可能会让用户感到困惑。因此,笔者从风险和成本角度考虑,并不建议在应用软件中过多地依赖图 形隐喻。也许,我们的软件没有什么特点,但作为应用软件UI,简约、易用、高效才是我们设计的目标。所以,在此我只考虑图标的设计原则。
图标设计的核心思想——用美观的图形抽象现实事务(事物)。以下是一些指导原则:
图标设计,可能已经超出了我们大多数人的技术范畴。这类工作更适合于专业的美工来完成,而不是UI设计人员。如果你不擅长矢量作图,请一名专业美工可能更好。
下面我分享下我自己绘制的LOGO:
联系客服