用户|驯服复杂,B端设计思考( 二 )


这没什么问题,只是不知道有没有人和我一样想过,这幅图里,为什么用圆形表示心理模型,而用不知道是什么形状的图形表示实现模型呢?
一个是没有棱角的基础图形,一个是……嗯,我总试图从里面看出一只什么动物。总之,这些冒出来的尖尖角角,大概就是产品中固有的复杂度了,它之所以被列在了不好的那面,大概是:它实在很难被看出个什么形状,所以才让人困惑和不舒服。
好坏不是因为形状,也不是因为复杂,而是令人困惑和不舒服的那部分。
四、B端设计,先有条,再有理B端设计的复杂,基于各种各样满足业务场景需要的功能,许多业务自带壁垒,几句行话就把你绕的晕头转向。B端设计的复杂,基于各式各样使用目的不同的角色,有些角色即使不用这个系统,你也不得不考虑,比如客户领导。
复杂度是必然的,驯服复杂,“为人们提供适当的概念模型”(被唐纳德称为设计师的工作),我倾向于,先有条,再有理。
1. 有条,是有秩序可循谁用,这个秩序就是谁说了算,就像书里举的一个例子,有些人的桌面在别的人看来简直混乱不堪,但当事人却总能迅速的从中找到他要的东西。这片混乱不堪只是表像,在使用者看来,一切秩序井然。
秩序从两个角度而来,一个是动态的,一个是静态的。
动态的是交互逻辑线。
你也可以叫做交互流程。B端系统由于一般会涉及到不同的用户角色和权限,会存在多个主要的逻辑线并存的状态。
每个角色的用户责任不一样,工作内容不一样,使用系统的逻辑就不太一样。所以,设计师需要分角色带入场景,去确认每个角色下用户使用产品的逻辑是否符合他们的概念模型。
用户|驯服复杂,B端设计思考
文章插图
除了顺着每个角色的工作职责和工作场景将每条逻辑线理清楚以后,还需要设计师跳出来,跨越角色,从整个系统的角度去看。
比如说B端系统里常有的任务流程,一般会分为创建任务、分发任务、执行任务、查看任务结果等。在实际的业务场景下,这很可能是多个用户角色完成的,但要让整个系统的逻辑闭环,就需要将他们连成一个整体去看。在某一个环节下存在的一个功能,很可能会影响其他的环节使用。比如分发任务后,如果支持暂停,那什么时候允许暂停?暂停多久?对于执行端会有什么影响?暂停的任务在查看的地方是否需要有记录?暂停后如果再次启用如何算任务次数,对其他的任务执行会不会有影响等等。
用户|驯服复杂,B端设计思考
文章插图
静态的是界面布局和结构。
好在B端产品的界面视觉呈现变化不大,多数中规中矩,最常用的布局已经为用户所熟悉,设计的时候可以省去一些时间,把思考留给项目所需的具体元素和信息组合。
用户|驯服复杂,B端设计思考
文章插图
图片来源:Ant design
信息的层级、类型和主次在这个时候尤为重要,以用户角色的概念模型来组织它们。比如B端系统里常常涉及到的增删改查,一般来说,信息的查阅是主要的使用目的,所以大多数页面由搜索条件和表格组成,增、改总是在弹窗、浮窗、新增页面等临时空间内完成。但如果查阅不是主要目的,搜索条件和表格组成的界面就需要再行考虑。
有条的原则是:建立紧密结合的系统,而不是孤立的产品。
2. 有理,是可以被理解两层含义。
第一层:产品的实现模型符合目标用户的概念模型,至少,要让他们能够容易的建立与产品呈现一致的概念模型。这是B端设计师需要了解业务的原因。