Salesforce的设计原则

Clarity-Eliminate ambiguity. Enable people to see, understand, and act with confidence.

Efficiency-Streamline and optimize workflows. Intelligently anticipate needs to help people work better, smarter, and faster.Consistency-Create familiarity and strengthen intuition by applying the same solution to the same problem.Beauty-Demonstrate respect for people』s time and attention through thoughtful and elegant craftsmanship.

比起Fiori的晦涩难懂,Salesforce的设计原则不但非常的简洁,而且非常实用。不论是入门还是资深的设计师,不论什么类型的企业级应用,我觉得这4条原则都是适用的。清晰,高效,一致,美观,优先顺序依次递减,非常有指导意义,比较容易遵从。

Salesforce非常强调的是这4个原则的优先顺序,目的是为了做设计决策。对于设计师来说,指出一个不一致的问题非常容易,但解决这一问题很难。设计上所有的地方都一致了,问题就解决了么?在实际项目的讨论中,分歧是最常见的现象,每个人都会基于自己的立场看问题,那么设计决策应该怎么做?很多时候会因为无止境的讨论而得不到有效的结论。项目越大,这个现象越严重。Salesforce的设计原则的本质是要制定一个所有人都接受的共同立场,大家在碰到冲突的时候能够基于这个准则快速的得出结论并且做出决策。

那么,Salesforce为什么按照清晰,高效,一致,美观这样的顺序来安排优先顺序?详细的解读可以看一下Salesforce的UX Design Architect的这篇文章(来自Medium,需要翻墙)。我在这里大概的翻译一下。

  • 清晰:用户需要清晰的完成任务,达成目标。如果我们能够通过不断的让用户成功的达到目标,那么我们会赢得他们的信任,忠诚和感谢。所以把这个原则放在第一位。
  • 高效:这是个在用户嘴里被不断重复的高频词。本来我们想把它放在第一位,但是我们还是决定把它放在第二位。因为我们注意到一个问题:一个命令行对于一个专家级用户来说是很棒,但对新手来说就晦涩难懂了。如果我们把高效做到极致,那我们大部分用户将会不知所措,他们会不断的犯错,并且因此耗费大量时间。所以高效是第二位的。
  • 一致:无论是构建用户的直觉还是设计师遵从设计规范,一致性非常重要。如果把一致性排第一,系统会因为创新被遏制而止步不前。如果有个设计很棒但是违反了一致性怎么办?所以我们把一致性放在第三位。
  • 美观:虽然说美观对设计师来说非常重要,但是这不是定义产品的指标。在这个领域里,设计的目标是解决问题,设计了一个美观但是难用的系统并没有什么意义。美观可以引人注目,但是对企业级应用来说并不是第一位的,所以放在第四。

作为一个企业级应用的设计师,觉得这4个原则真是说到心坎上去了,干脆利落,振聋发聩。Talk is cheap, show me the design. 我们来看一看Salesforce的系统是怎么把这些原则融入到设计中去的吧。

系统结构和导航

Global Navigation

Setting - Vertical Navigation

App Launcher

Salesforce系统的信息结构不同于传统的模块式的结构,采用了混合的形式,引入了角色的概念。在App Launcher中,一个App对应一个角色,一个Item对应一个功能模块,一个App其实是多个Item的集合。当你选择一个角色,比如Sales,系统自动把整个导航栏切换成对应的Sales的内容,这些内容都是和Sales相关的Item。除此之外,业务模块和配置模块在系统上是隔离开来的,可以理解为两个平行的系统。我们可以看到设计都是为业务服务的,通过App Launcher和Global Navigation用户能够非常清晰的了解系统的结构,只关注和自己有关的内容。一致性在这个层面优先顺序很低,如上图中,系统的导航形式并不一致。

Salesforce Global Navigation - 展开

Salesforce的菜单的导航效率非常的高效。点击区域分为Label和下拉图标两块。拿Opportunities(销售机会)来举例,直接点击Opportunities区域显示的最近查看的,而不是所有销售计划的列表,因为all其实并没有太大的意义,对于实际的业务操作人员,通常还是需要一个过滤条件来缩小目标的范围。Recent Records会显示最近查看的3条销售机会,可以在菜单上跳过列表层直接访问具体的一个销售机会,对于追溯一个销售机会非常方便。Open "Recently Viewed" in New Tab则是一个非常灵活实用的功能,方便在导航标签上挂起一个最近查看的列表,可以方便的来回切换进行比对。Salesforce的导航菜单完全不同于传统的导航,传统的导航非常在意层级的表现力,但是在这里,我们可以清楚的看到,它是怎么以业务为导向,为用户设计出高效的导航菜单。

创建行为

Global Navigation上的创建

列表页上的创建

全局创建

创建一个单据的同时创建一个主数据

系统中存在4种创建行为,分别对应著不同的业务场景,非常典型的为了高效牺牲了一致性。

  • 菜单上就有直接创建的按钮,不需要用户导航到对应的列表页再点击创建按钮。
  • 列表页保留的创建按钮符合用户传统的认知。
  • 全局创建可以在任何页面任何状态唤起创建窗口,该创建过程应对著是突发,会打断用户,优先顺序较高的任务(比如突然接到客户的电话)。全局创建唤起的窗口属于shell层的内容,所以是独立的进程,用户只需要填写最基础的4个栏位,即可将单据快速创建出来,后期再补充完整。非常Nice的一个功能,Salesforce特有。
  • 创建单据的同时创建主数据。这在业务中比较常见,当你创建一个单据的时候发现少了一个主数据,这时候不需要跳转到主数据的模块,直接在当前页面唤起创建主数据的窗口完成创建,并且不会中断单据的创建。

编辑行为

图1 Quarterly Performance - Goal的编辑

图2 卡片上触发一个单据或主数据的编辑

图3 列表上的编辑,假冒的Inline Edit

图4 详情页上的编辑,假冒的Partial Edit

图5 普通编辑

图6 Update Active - 直接编辑

Salesforce的编辑行为可以说五花八门,基本上在任何一个用户想要编辑的地方都可以触发编辑的行为。不像传统的软体,必须到对象的详情页,才能触发编辑的行为。如果只是为了考虑一致性,很多创新的设计会被遏制,系统中根本不会存在这么多样化的编辑行为。又是典型的为了高效牺牲了一致性。

还有一个非常有意思的地方就是在列表页和详情页触发的实时编辑(图3图4),虽然可以直接编辑,但是不能实时保存,还是需要点击页面下方的save,所以我叫它们假冒的实时编辑。有经验的设计师一下就能明白为什么是假冒的,实时编辑在开发上实现的成本很高,如果是产品半路改成这样的行为需要动到开发架构。Salesforce的设计师用了一个非常聪明的方法,权衡了体验和技术上的冲突,在设计和实现上找到了一个平衡点。非常值得学习的小细节,很多时候设计上的精益求精对于设计师本身没错,但是对于整个产品和项目来说,是需要权衡的。

页面布局

销售机会

这个页面的布局从业务的角度看非常清晰,信息的优先顺序排布的很有序。橙色部分优先顺序最高,蓝色部分其次,绿色部分最后。把里面的内容分别提取出来是一个这样的结构(字体的颜色和上图遮罩区域颜色对应,优先顺序依次递减)

头部

  • 关键信息(从整个业务对象中提炼出来的核心内容用于快速识别)
  • 销售机会的进度条

内容部分

  • 动态(为了更好的追溯当前销售机会的变化)
  • Chatter(一个轻量级的Slack,为了团队内部成员之间更好的交流)
  • 详情(显示一些静态的信息,创建单据的时候填写的内容)

边栏卡片

  • 相关的快捷链接(可以通过滑鼠悬停直接显示列表的预览)
  • 活动影响
  • 联系人
  • 报价
  • 产品
  • 笔记
  • 附件

Nesting Tabs

整个销售机会的内容其实很多,但是可以很好的被一个页面有序的呈现出来,Nesting Tabs这个控制项很关键。通常来说,两层Tab的堆叠是一个挺难处理的设计用例,但这里是一个很巧妙的解决方案(第二层的Tab采用卡片来包裹里面的内容),用一个简洁的控制项承载了复杂的结构和大量的信息,让页面看起来非常整洁清晰。

Salesforce设计原则的总结

在实际的项目中,每个设计决策都要去权衡来自于各个方面的因素,4大原则的优先顺序在这一点上非常的实用。Salesforce的Lightning在2015年第四季度发布,整个系统在2017年之后趋于稳定,一直到现在,视觉和交互上几乎没有太大的变化,可见这些设计还是经得起业务和市场的考验的。除了上面举例的部分,系统里面还有很多精妙的设计,在业务的上下文中体验很好,限于篇幅,无法把更多的细节逐一分析。但总的来说,清晰,高效,一致,美观,四个原则贯彻落实的很好。

从设计师的角度而言,清晰和高效两个原则是需要设计师对用户的角色和业务有著深入的理解的,不能仅限于表现和框架层面。Salesforce的控制项如果脱离了业务的上下文,看起来索然无味。它很好的解释了业务驱动设计的产生,而不是先造控制项,再往里面填内容。如果像第一章的实验一样,只是考虑控制项和框架的特性,硬把内容塞进去,会导致用户使用起来非常违和。


推荐阅读:
相关文章