产品需求如何设计一个合适的列表.docx

上传人:b****2 文档编号:14000349 上传时间:2023-06-19 格式:DOCX 页数:9 大小:109.11KB
下载 相关 举报
产品需求如何设计一个合适的列表.docx_第1页
第1页 / 共9页
产品需求如何设计一个合适的列表.docx_第2页
第2页 / 共9页
产品需求如何设计一个合适的列表.docx_第3页
第3页 / 共9页
产品需求如何设计一个合适的列表.docx_第4页
第4页 / 共9页
产品需求如何设计一个合适的列表.docx_第5页
第5页 / 共9页
产品需求如何设计一个合适的列表.docx_第6页
第6页 / 共9页
产品需求如何设计一个合适的列表.docx_第7页
第7页 / 共9页
产品需求如何设计一个合适的列表.docx_第8页
第8页 / 共9页
产品需求如何设计一个合适的列表.docx_第9页
第9页 / 共9页
亲,该文档总共9页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

产品需求如何设计一个合适的列表.docx

《产品需求如何设计一个合适的列表.docx》由会员分享,可在线阅读,更多相关《产品需求如何设计一个合适的列表.docx(9页珍藏版)》请在冰点文库上搜索。

产品需求如何设计一个合适的列表.docx

产品需求如何设计一个合适的列表

如何设计一个合适的列表

在我们的日常生活衣食住行和工作中会,就会看到非常多的列表,最常见的也就是消息列表、联系人简介之类的,每个列表的功能和表达的信息某个都有所不同;分享了关于专门设计一个合适的列表,我们一起来了解回去。

我们平均每天会浏览多少个列表?

为了得到信息一个相对真实的数据,我对身边7个来自互联网、金融、建筑、医疗等不同行业的朋友成功进行了调研。

根据抽样调查的结果显示,这个数值在180左右。

且超过70%的人,每天浏览列表的数量数大于150个。

这是一个挺令人遗憾的结果。

这说明,虽然我们就每天都在各种不同的产品中使用“列表”这种形式的构成,但是我们并没有没有与生俱来意识到“列表”在产品中的极为重要作用。

所有的商品都和列表有都关系:

根据前面的调查显示,这几个朋友日常浏览的产品,其品类有社交、资讯、工具、娱乐等,几乎涵盖了大部分的领域;而且我相信,随着样本需求量的增加,这些品类只会越丰富、越完整。

比方说,我们日常使用的聊天硬件,微信和QQ,它们里面就包含了不少列表,如:

聊天室列表、联系人列表、朋友圈的朋友动态列表等;还有我们闲暇时刻杀时间用的资讯软件和视频软件,比如今日头条、抖音和快手,它们里面也有不少列表,如:

文章列表、视频列表、创列表、音乐列表等。

这些列表的形态各异、结构纷呈、用途不一,但无一列外的是,它们都在不同场景下向呈现了丰富且有用的信息,同时还在用户和数据之间架起了的桥梁。

列表是信息承载的决定论:

在互联网世界里,最重要的当然是重要信息。

从技术的角度来看,这些纷繁复杂的信息都储存在一张张看不见的数据表中;而最初的列表,正是由这些数据表演化而来;这就意味着,列表在数据存储方面,有着其他结构所不微观具有的技术优越性。

正是出于这一点,列表被大量的应用到了不同的信息展示和交互场景中,而且都很好的起到的信息承载的作用。

它们的普遍存在隐含了一个我们必须面对的问题,那就是我们如何为每一个不同的场景设计一个合适的列表?

接下来,我将带着大家偷偷地大家探索列表的本质,并向大家展示一个所列洽当的列表该有的样子;然后我会结合一个实战案例,分享列表的设计整个过程。

列表的普遍程度远超我们的想象,已经达到了能够潜移默化地走进每一个产品的地步。

有时候,我们在设计原核细胞中应用“列表”来承载数据时,并没有去想太多,也不会去深究为什么要这么做,仿佛这一切都是天经地义。

原因也许是前面提到的,列表这一形态但此在技术上的优越性,那么这种结构又是由什么元素共同组成的呢?

我认为有三种,分别是:

数据、布局和操作。

1.数据

如果不去看前端界面的表现,直接通过接口去获取列表的数据返回,我们会发现,这些“列表”是由多条结构类似的数据组成的,信息它们组成了一个有序排列的信息合集。

这个信息合集有三大特点。

最大的特点是实例的相似性。

例如电商平台的订单列表,每一行数据中所哪些是引用、哪些是数组、哪些是扩展字段等,这些大都是一样的。

第二个方格特质是数据排列的有序性。

这里的顺序,代表的先后顺序是数据展现给用户的相继次序,一般会按照时间、数量、类型等数据的典型特点来排序,便于用户的理解和使用。

下一场一个特点是数据的充分必要性。

换句话来说就是,接口返回的数据既要充分满足前端展示的需要,又数据要保证每个信息的存在都是合理的。

这是非常容易理解,但有时候特别难做到一点儿的一点。

2.布局

如果数据是积木分块,那么它们相互关系的组织方式将决定积木整体的途径最终呈现结果。

在零零散散的白板面前,我们产品人员就像一个堆积木的玩家,会努力把每一块积木放置到合适的位置上,最终实现既定的终极目标。

这个过程要注意两点。

第一,我们要保证信息结构的正确性,也就是分清信息子类的类别和层级。

这里举一个场景,比如我们正在设计商品购买页,现在需要展示的一个货品是“书”。

在这之前,我们收集到与这个酒品有关的内部信息信息有:

书名、、的详情、书籍分类、价格;那么,按照信息的范畴和层级,我们可以把这些信息组织成一张信息结构图,如下。

第二,我们美感要遵循人类视觉的规律;比如,人的视觉范围是有很强限度的,超过这个范围的集电结区域是人的视觉盲区,我们不应该不必把突出的内容放到这里;又比如,人文字感知的敏感程度远比对图形的低,所以一些需要突出重点的内容,可以应用图形的融资方案;再比如,不同的色彩能给人带来不同的市场情绪,红色是热情、蓝色是冷静、黑色是庄重等,这些都可以合理利用。

3.操作

列表之所以能够如此受欢迎,当然不只是主要用于展示个人信息信息而已,它更非常重要的表现在于近乎完美的交互体态;无论是搜索、筛选还是排序,无论是单个操作、多个操作还是全选操作,列表的抵御都游刃有余。

如果说对数据库的增删改查是一个程序员的浪漫,那么对列表的则是一个产品的艺术。

这种艺术特质,可以反映在两个方面上才。

一方面,操作要符合场景。

这里的场景,更多的是交互场景;比方说你在检索一个超市超级市场的时候,出来了一个商超的列表,这时候你看到表头里有“距离”这项;这时候大部分用户的想法,可能就是希望列表能够按照“距离”这个项来或进行排序,那么我们理所应当把筛选的操作放到“距离”上面,而不是去其他地方放一个筛选项(比如列表的头部操作区域)。

另一方面,操作是必要的。

在假说的角度来看,任何列表都可以增删改查。

可一旦列表处于某些中会场景中时,我们就需要隐藏一些不合时宜的行为;比如买家看到商家的商品列表之时,不能改删除商品。

相反,如果列表处于另一些场景中时,我们可能要可能回来丰富基础的操作;比如同样同样是买家查看商品和服务列表,我们这种方式需要提供多维度的筛选和排序方式,以供用户快速找到合适的商品。

列表的这三个原素是大部分场景下,一个合适的列表本该有的样子,但这并不意味着它们预示着相联。

我们知晓它的构成,不是为了可以照本宣科地去外观设计的,而是为了在既定的中搭配出合适的样子,需要有具体情况具体分析。

这里有这么一个场景:

在一个PC端的云文档产品中所,用户储存有许多文档,其中很多开启了分享,以便与他人协作;交流思想的方式虽然很便利,但是也存在超载,因此对特别希望能有一个地方能够用户这些分享出去的文档进行统一管理。

如果是你,你会怎么去设计这个“已分享文件”的管理列表呢?

这里我给出我自己的答案。

1.分析需要什么数据

首先,这是一个公函列表,那么坚实基础对用户来说最基本的一个数据就是文件的基础信息,用于文件的识别,如文件名、文件图标。

其次,从需求背景来看,应用程序的核心诉求在于“找到想要的东西”并加以管理,而这个“东西”就是已发想出去的文件。

那么这种文件有什么相似性特征呢?

最出现明显的一点就是“已经开启分享”,也就是说消除了分享的行为数据,如分享链接、分享的对象(范围)、分享出去的权限、分享链接的有效期。

除此之外,用户肯定还会关心文件分享出去之后所造成的结果,比如文件通过分享链接的下载量和访问量。

2.梳理信息优先级

整理好所需的数据以后,我们就可以开始定义数据的优先级,并根据信息对用户的重要程度来划分。

然后,我们要按照优先级归类信息。

过程就不赘述了,我直接上图:

3.布局

经过了前面两步的分析,我们已经相信用户内容关心的内容是什么,也知道了应哪些信息应该重点突出;那么在第三步中,我们要做的是如何把这些信息有机结合起来。

一般来说,我们会参考一些比较成型的范式,通过套用与调整,最终形成合适的列表。

详述这里我介绍三种比较通用的列表范式:

1)行列式

最大的特点是每个行列的交点形成独立的信息单元,也叫表格。

这种列表的优点在于结构清晰且具有稳定性、信息的定义明晰明了、没有投资业务倾向且可塑性强;便是缺点在于单行能容纳的信息不能太多,不然要么引起视觉疲劳,要么打破原有的结构稳定性;其次就是重点不会突出,用户的视觉焦点相当零散。

2)无列式

没有严格意义上的列,每个单元自为整体,也叫信息流、feed流列表。

解题它的优点是自上而下的信息布局符合大多数用户的阅读习惯;其次每个信息短剧单元的独立性强,因而信息自由言论单元内的信息布局比较自由,可根据管理业务形态进行拓展;不过它的缺点也很明显,就是信息的密度比较相对较低,一屏内用所能展示内所的信息单元不多。

3)无行式

没有严格意义上的行,每个单元自为整体,一般也叫瀑布流。

这种列表在保留了信息流列表绝大多数优点的下要,解决了信息单元密度低的问题。

代价就是要求大屏幕,且缺乏结构的稳定性。

回到案例当中,如果我们把已有的往这三种范式中套用,那么就会发现行列式和无行式的列表都不是最佳的。

为什么呢?

首先,在这些数据当中,优先级高的信息显着数量明显少于优先级低的信息,所以如果构造我们采用行列式结构,那么就会分散用户视觉焦点到优先级低不会的信息上,这是有悖于“查找”这一目标的;其次,用户的核心政治理念是“找到想要的东西”,而查找和定位需要列表的结构具有稳定性,那么低的无行式结构也就不适用了。

因此,我们选择了在结构上更稳定、内容布局比较自由的无列式结构。

整体的框架迪金斯了,那么每个信息单元的内容全部内容应该如何布局呢?

这里我们主要是根据需要进行广告主的视觉习惯来进行信息布置的。

在PC端,用户的使用者视觉焦点一般分布在左上、中部和右下,尤其左上。

那么优先级最高的原始数据,像图标和文件名,就理应被放在这个位置上;而次要优先级的信息,可以放在左下和右下,如分享信息和分享行为数据。

除了视觉焦点之外,我们表现形式可以借助人对色彩和图形的敏感性来调整信息的还;例如,我们会根据文档的不同类型去设计不同的图标,便于用户第一时间公文就能区分文件的类型;又比如,我们会采用不同的颜色来区分自由度文字信息的重要程度,以便抓住用户的眼球。

4.功能操作

如果说前面的三步我们都在研究用户想要“看”什么,那么在最后这一步中,我们列表要剖析的是用户想要对列表“做”什么。

在本文的案例中,用户想要做的事情前面其实虽然提到过,是“找到想要的东西”并加以管理,简单来说,就是查询和管理。

说到查询,不得不提“search全家桶”:

搜索、筛选和排序。

它们分别桥段满足了三种不同的场景,搜索满足的是只模糊记得文件名的场景、筛选满足的是用户通过文件的特性减少列表结果的场景、排序满足的是用户根据自己关心的信息去改变列表信息展示优先级的场景,这三者的积极作用无一例外都是为了提高用户的查询效率。

至于说管理,每个不同的列表场景对应的运营管理需求大相径庭,无法一概而论。

不过有一点是共通的,那就是行为本身是与列表的信息高度匹配的;例如,在已分享文件列表的场景中,用户广告主能管理的内容其实是非常有限的,如分享的对象(范围)、分享出去的权限、同享链接的有效期等;从这个角度出发,那么用户需要的管理操作无非就是修改分享行为、结束分享行为等。

小事情中也有大学问,仔细回顾回顾列表设计的整个投资过程,你会发现,这里面的和设计观其实适用于很多地方。

在产品设计的专业领域里,没有大小贵贱之分,你倾注到产品里的每一份感情,用户都是能够感知到的;只是这个世界太复杂,节奏也越来越快,大家的视线都关注点在那些高大上的东西身后身上,很多抛弃细微的存在渐渐被人们遗忘。

我不希望有心如此,愿你我成为细微里的巨人。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 医药卫生 > 基础医学

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2