交互水深 08 | 列表设计,不止是控制欲望的游戏

初学交互设计,照猫画虎未尝不可。然而,临摹过程中,控制设计师的欲望,需要刻意练习。因为纵欲无度,不小心写了4500字,够看半小时。

整理不断膨胀的欲望

例如,设计教务系统当中的学籍管理模块,其中包含一个列表,产品经理提供的需求通常是类似『数据字典』的东西:

开始设计之前,对数据项目进行一下分析:

唯一约束型

比如『学号』,这类不允许重复出现、也不允许重复利用的项目,通常作为数据库主键存在。它们通常不太容易记忆。当然对于ToB产品来说,强制运营人员用唯一约束沟通是具有一定优势:非常高效。

个性化 静态文本型

比如『姓名』,这类可以任意填写,一旦保存就几乎不会改变的项目。作为查询条件,比『学号』更容易记忆。

限定 静态文本型

比如『性别』『民族』,这类在某个限定范围中的单选,一旦保存就几乎不会改变的项目。布尔值(是或否),可以视作一种特殊的限定静态文本类型。通常作为筛选条件存在,非此即彼。

自增数字型

比如『年龄』,这类以某个固定时间周期不断自我增加的项目。区间筛选、排序,两者皆可。

自定义数字型

比如『身高』『体重』,这类可以任意填写的数字项目。区间筛选、排序,两者皆可。

静态日期型

比如『生日』和『入学年份』,代表某个里程碑时刻的日期时间项目,一旦保存就不会改变。区间筛选、排序,两者皆可。

状态型

比如某学生的状态可以在『在读』『借读』『肄业』『毕业』……等一系列限定范围之内切换。通常是系统自动更新,最主要的筛选项目。

多值数组型

比如『职务』,即是班长,同时兼任团支部书记。允许多个值,使用分隔符组成一个数据。组成数组的值,可以是某个限定范围的,也可以是完全无限定的离散量。如果是限定范围的多值数组,可以进行筛选。

累加记录型

比如『三好学生』,实际上指获得此类荣誉的次数,背后蕴含另外一个相关列表的统计。

假如把需求当中的数据项统统扔进列表,大概是下面的设计:

根本看不清,对吧?因为纵列太多!并且,随着产品迭代和业务深化,整个列表的项目会越来越多,远远超过屏幕宽度所能承受。

纵列臃肿,造成横向滚动,这种设计无论是桌面端还是移动端,都将带来巨大的可用性问题。某些设计师朋友们提议:使用流行的『卡片式设计』能解决这个问题呀?没错,卡片式设计的确可以避免纵列太多的问题,但是,当每个卡片内容超过屏幕高度的时候,使用效率会非常低。

面对这样的窘境,设计师必须要大刀阔斧进行缩减设计,窍门就是用户任务颗粒度的控制。

明确用户任务

基于『学生列表』,或许需求已经明确指出,并且设计师们还可以脑补出非常多的『使用场景』,诸如下面:

  • 通过姓名、身份证、家长姓名、家长手机号码能精确找到某个学生;
  • 通过『在读』和『班级』能准确输出当前在某个班的在读学生名单;
  • 利用『毕业年份』筛选,快速找到『某一届毕业生』的数量和名单;
  • 利用『转学』『退学』筛选,统计历年生源的流失情况;
  • 通过筛选年龄,排序身高、体重,可以得出学生们的身体发育情况;
  • 通过筛选入学年份和年级,可以获取『留级』的学生名单;

除此以外,可能还有:

  • 根据状态和当前用户权限,对某个学生的资料进行增删改查操作;
  • 对多个学生的资料进行批量操作,或者批量导入导出功能;

当然,只要脑洞足够大,还能扩展出很多『好玩的场景』;当然,所谓『场景』越来越多的时候,设计们会发现要思考的维度越来越多,最后脑力枯竭了!这就是很多新手设计师经常遇到的问题,『控制不住膨胀的欲望』。

在此,Hozin提出一个值得争议观点:实际上,『场景』可能是个有害的东西!设计师完全没有必要思考太多的场景,只要将用户任务高度解耦,回归『一个界面一个用户任务』的原则,实现『以不变应万变』。

学生列表,这个界面的核心用户任务是什么呢?其实只有一个:

查找某一条或某几条学生数据,无它。

为了完成这个任务,必须先搞清楚另外一个问题:

如何区分两条学生数据,无它。

思考第一个问题:在生活中,如何区分一个人和另外一个人呢?

  • 名字,的确很方便,但是『同名同姓』的情况大量存在;
  • 面孔,的确很方便,但是图片不容易量化描述,并且体貌特征相似的情况也存在(孪生),同名同姓并且面貌相似也是存在的,虽然概率非常低;

于是,在生活中,有了『身份证号码』这样的东西,彻底区分两个自然人,但是它的劣势也很明显,不太容易记住!

思考第二个问题:对于学校来说,仅靠身份证号码能够实现区分学生吗?

抱歉,这还真存在问题!身份证号码的确能区分学生,但是对学籍来说并非唯一条件:

  • 学生甲,从本校初中3年制毕业,又考入本校高中部,就会产生两条学籍记录;
  • 学生乙,从本校初一年级转学,一年后,回到本校初三年级借读,也有可能产生两条学籍记录;

基于上面两个问题,设计师应该明白:虽然数据记录是『学籍』维度,但『学生列表』包含另外一个隐含维度『自然人』!

控制欲望,减法设计

生活中,的确不存在同一个人同时就读初中和高中的情况;但是在高等教育中,存在同一人同时就读两个专业(双学位,部分学分共用)的情况,为了让系统兼容更多的业务,需要对数据做『学籍』和『自然人』两个维度的区分。

同时,还可以进行另外一项工作:区分哪些项目可以进行搜索、筛选、排序操作。

  • 唯一约束和自由填写项目,通常可以进行搜索,比如『学号』、『姓名』、『身份证号码』、『家长姓名』、『家长手机』;
  • 限定范围的项目,通常可以进行筛选,比如『性别』、『民族』,对于数字和日期时间格式,可以进行区间筛选,比如『生日』、『身高』、『体重』;
  • 所有的数字和日期时间格式,都可以进行排序操作,比如『生日』、『身高』甚至『三好学生』这样的统计项目;

有关搜索、筛选、排序,实在太复杂,Hozin将在后续文章中专门来写,此处点到为止。

在『自然人』维度,Hozin保留了如下的数据项目:

照片

考虑到Face To Face快速确认身份;

姓名

搜索最便捷的搜索项目,使用率会是最高的;

性别

为同名同姓准备的第一道防线;

年龄

辅助照片共同完成Face To Face确认身份;

身份证后八位

同时代替了生日数据,作为同名同姓的最后一道防线;

在『学籍』维度,Hozin保留了如下数据项目:

学号

唯一约束主键,比姓名搜索更高效,给运营人员使用;

班级

由于数据记录落在了『学籍』维度,因此把状态和班级进行了合并;『在读』直接显示『年级 班级』,其他情况直接显示『发生年份』 『已转学』『肄业』『毕业』;『借读』情况单独说明。

根据以上的减法,Hozin分别重新设计了桌面端原型:

当然,也包括移动端『卡片式设计』的原型:

并且,以『学籍』为维度,允许同一个自然人出现两次,比如当查询某个用户时,可能的结果是:

至此,仿佛完成了『学生列表』这个界面的核心用户任务:查找某一条或某几条学生数据。为什么是『仿佛完成』呢?请往下继续看吧

『最简列表』的扩展设计

上面那个『最简』设计,Hozin预估会有以下两种不同的声音:

第一种声音来自产品经理和其他设计师:神啊,虽然是简单了,但是,如果想知道有哪些同学是共青团员怎么办?如果想知道2017年哪些同学留级了怎么办?如果想统计初二年级的身高体重怎么办?

第二种声音来自程序员:这活没法干了,数据接口都写好, 这数据项变化也太大了,交互设计师这么搞,是要返工重来吧,想让程序员集体辞职?

ok,这些问题有办法应对么?

回答产品经理:

1.政治面貌的按照『共青团员』筛选,将是下面这样的列表:

2.想知道哪个同学留级了,将是下面这样的列表:

3.除了根据筛选项/排序项联动,甚至可以让用户自己控制显示列表中的哪些其他项目:

4.关于『统计』相关功能,有可能违背了『一个界面一个用户任务』的原则,需要设计专门完成统计任务的新界面。Hozin将在后续文章中专门来写,此处点到为止。

回答程序员:

心智模型和实现模型,是两件事。这样的设计并没有影响数据库设计,底层数据接口也无需重写,只是前端工程师要根据界面交互对数据进行二次加工。

配合使用,优雅的起舞

如果,经历撕逼、拉锯式评审和种种磨难,终于完成了界面的高度解耦,回归了『一个界面完成一个用户任务』的根本原则。那么就来看看,这个『学生列表』完成对学籍的管理,还需要哪些其他界面:

学籍记录详情

针对某一条学籍记录展开,包括入学信息、毕业信息、职务、学分等,包含各种变动记录的统计入口;

自然人卡片

属于这个用户本身的属性,包括身体变化,学籍变迁,家长家庭信息,也包括在各个学习记录下的各种变动统计入口;

各种变动记录

围绕这个自然人,在各个学籍记录下的各种单项的变化历史记录;

这些界面之间的运作关系,如下图示意:

具体到列表界面原型交互,可能有如下设计:

控制『操作』的欲望

在列表设计中,遇到批量操作问题,已经在交互水深 06 | 单选小坑,多选大坑(下篇)有过相关讨论,各位读者已经成竹在胸。但是,对单条记录进行操作也要有节制!

假如不加节制,单条记录的操作,可能会变成这样子:

产生这种情况的原因有两种:

第一,每条记录状态不同,会拥有不同的操作项目;
第二,当前用户权限不同,也会拥有不同的操作项目;

这样设计的问题也显而易见:

第一,可能操作区非常靠近,此时,既要确认目标记录,又要从多个操作中选择某一个,此时误操作的可能性非常高!即便设计成下拉框操作,依然存在误操作风险!

第二,因为不同记录可能存在操作顺序不一样,上下移动鼠标会存在不同操作,用户代价非常高。当然,可以设计成下面这样,但是很吃藕!

第三,浪费大量的屏幕空间!见上图↑↑↑↑↑↑

第四,浪费开发工作量!因为在列表中实现一系列权限判断和操作,在详情界面中往往还需要再开发一次相同的权限判断和操作;

综上所述,Hozin推荐的做法是:对于列表中的单条记录,只有一种『管理』或『查看』操作,所有其它的单独操作都去往该记录的详情界面完成。

这样设计的优势显而易见:

第一,界面高度解耦,功能迭代方便,节约开发工作量;
第二,列表界面操作高度一致性,利于养成用户习惯;
第三,在详情页用户会明显确认目标记录,几乎不会误操作;
第四,列表界面将节约大量屏幕空间;

小结

按照『一个界面完成一个用户任务』原则,推荐以下步骤进行『列表设计』:

首先,对数据项目进行分类整理,区分变化与不变,限定与自由;

其次,明确列表的核心任务是『找到目标,无它』,然后具体问题具体分析;
再次,根据核心任务逐一辨别数据项目,生成『最简设计』;
进而,在『最简设计』的基础上利用联动进行扩展变化,必要时提供用户自定义项目功能;
最后,列表界面要和详情界面、变动记录界面配合完成更多的用户任务。

『场景』对设计师可能是有害的,应该将界面高度解耦,努力寻找『以不变应万变』的设计方法!

批量操作使用收集器完成;单条记录操作应该尽可能放入详情界面,而不是在列表界面浪费屏幕空间和开发资源。

总之,每当面对复杂问题,请设计师别想太多,缩小思考范围,『控制自己的欲望』。

文章标签:

0 条评论 369 次阅读

  1. 既来之,则言之。

发表评论

Top