设计信息架构就像你在写一篇马上要给用户背的文章,信息架构的宽度、深度有助于减少需要在用户大脑内存储内容的大小。但是在信息架构设计过程中最重要的可能还要属层次逻辑检查,既要保证不同层次间的逻辑关系,又要保证层次内的逻辑关系。
好的信息架构层次逻辑设计,就像好的文章层次逻辑一样,可以帮客户更容易找出文章段与段、句与句间的逻辑,这样逻辑清晰的文章用户更容易记忆和回想,背诵和使用起来难度也将减少很多。
对于层次间逻辑检查,需要确保每一个上层与其下层之间的“关系”是合理的,并且层次间的逻辑划分是对用户场景有意义的,有一些处于灰色地带难以界定的下层需要设计统一的规范进行安排。如下图内我举了一个关于“新闻查看”的例子来说明层次间逻辑的重要性。
在这个例子里混合划分方案我认为是最不合理的,有两处明显的不合理:
- 一是主题和呈现方式分类大范围混用
- 二是层次内逻辑不清晰(这部分在下一小节介绍),时政->视频->体育->语音这个顺序组合没有发现任何明显的逻辑关系。
|
其次我们看看按呈现方式划分方案,该方案的划分咋一看较为合理,因为用户可能有的喜欢阅读,有的喜欢看视频,有的喜欢听语音。但是如果回到用户真正“查看新闻”的场景,我们会发现看新闻的场景往往代表他们有空,而在有空的情况下查看新闻,在主题和呈现方式上,主题应该占据更重要的位置,因此使用呈现方式来划分新闻可能就没有按主题形式来划分新闻更能满足用户需求。(因为举例是为了介绍概念,因此以主观分析为主)。
对于层次内逻辑检查,需要确保同层次内的信息维度是一致的,或者至少是遵循了一种确定的规范的。容易出现歧义的分类要尽可能避免,不能轻易将区分歧义的任务留给用户。
例如采购管理、库存管理、结算管理,每个管理功能都需要做一些基础参数配置,那么这个参数配置入口就最好放置在层次内的同一个位置上,或者统一抽取出来组成集中配置入口,便于用户查找。如果这个配置入口在不同功能内放置在不同地方,有的采用Tab做入口,有的采用按钮做入口,有的采用二级菜单做入口,有的放在系统统一配置内,那用户可能就要疯了。
(3)文案检查
层次逻辑检查,往往只是在产品设计者层面使得信息架构清晰了。但真正想把层次逻辑准确呈现给用户,还需要合理文案的配合。
认真检查调整文案的字数,会让信息架构看起来更简洁。认真检查文案本身的清晰程度,避免歧义并切近用户及场景习惯将极大程度增加产品的易用性。“抠字眼”般的“强迫症”我认为本该就是产品经理的习惯和责任,真正逼迫产品经理暂时改掉这个“强迫症”的不应该是自己的懒惰或不重视,而应该是ROI与MVP这两个希望产品可能更快递送价值和获得回报的思维工具。
(4)层次的呈现方式检查
信息架构的深度可以抵达4-5层之深(甚至更多),除了菜单栏、导航栏以外,其实还有Tab甚至按钮等信息架构承载形式(往往它们用于承载信息架构末端的信息)。
合理利用Tab及按钮等呈现方式,可以节省菜单及导航的复杂性,增强用户的体验流畅程度。
(5)一致性检查
以上提到的层次逻辑、文案及呈现方式,仅考虑单独优化的情况,但实际上,对于信息结构来说更重要的一点是一致性。如果一个每一个一级菜单都遵照层次逻辑、文案和呈现方式设计,但是各自所遵照的层次逻辑、文案和呈现方式不同,则可能会给用户增加学习成本,需要为不同的一级菜单记忆不同的逻辑。
为了减少这样类型的用户负担,在结构层的最后,需要对信息结构设计的整体一致性进行检查,保障用户可以用最小的逻辑负担承载下我们产品提供的强大价值。
信息架构的设计还有许多有意思的地方需要动脑筋开动,例如一个网站可以具备两套甚至多套导航入口,最终满足不同逻辑习惯的用户。
2.驱动模型检查
市场上遇到太多的产品实际上真的提供了价值并可以满足用户需求,可是为什么却迟迟不被用户认可以获得大范围使用呢?
产品往往创造价值,但是价值不是自然而然与用户连接在一起的。在创造之后还需要一个传递价值的过程,这个过程会遇到许多不一样的阻力。常见阻碍用户选择产品的阻力来自于三方面:
- 一是痛点不被用户所知
- 二是产品不被用户所知
- 三是产品价值难以被用户所知
第一、第二点大部分在于市场营销(产品运营)范畴,在产品设计自检过程我们着重关注第三点。在进行驱动模型检查时,我主要检查两个方面:
- 一是产品核心价值功能入口是否充分暴露(驱动用户启动体验)
- 二是关注产品核心价值功能从入口到价值体现的过程是否通畅(驱动用户完整体验)
有许多产品核心价值可能来自于多个功能使用完毕的叠加,尽管功能入口暴露充分,但是因为用户迟迟不能完成前期步骤而使得产品价值无法体现,导致产品最终被放弃。
3.实体关系检查
随着设计的逐步深入,产品经理容易基于当前设计的框架、思维以及竞品或标杆的实现打磨自己的设计,而忘记用户思维的构建。一个产品至少拥有四个实体逻辑框架:一个是现实业务的实体逻辑框架,一个在产品经理心中,一个在技术部门心中,另一个在实际用户心中。
理想情况下我认为:
- 现实业务的实体逻辑框架是产品经理心中的实体逻辑框架的基础,是对当前现实业务的直接反映。
- 产品经理心中的实体逻辑框架是对当前现实业务的简化和抽象(因为有了技术手段),用于产品设计及用户培训。
- 技术团队心中的实体逻辑框架是对产品经理心中的实体逻辑框架在技术角度的补充实现,增加了技术实现需要的部分及优化,最终的呈现形式是数据库结构设计。
- 用户心中的实体逻辑框架是产品上市后,实际在用户心中形成的实体逻辑框架,是用户对产品功能与现实业务的实际理解。
在实体关系检查部分,我主要检查两个方面:
一是现实业务的实体逻辑框架 VS. 产品经理心中的实体逻辑框架。
确保产品经理心中的实体逻辑框架充分借鉴合理的现实业务实体逻辑,包括词汇与关系,避免生造词以及难以直观理解的业务关系。
另外还关注从产品设计层面是否可以对现实业务进行简化和合理的重构,帮助用户真正减轻业务压力。
二是产品经理心中的实体逻辑框架 VS. 用户心中的实体逻辑框架。
理论上我认为这两部分实体逻辑框架一模一样是最理想的状态,因为它是产品经理认为在业务层面最为简约高效的逻辑关系。但是现实情况往往差强人意,产品经理设计的产品实体逻辑关系A往往被用户理解成A’甚至C或者D。
这一层检查需要更多的是产品经理的现实“仿真”能力以及“用户同理心”。站在用户角度看看他们在第一次看到系统时、在使用系统时是怎么理解系统的。
最后,还想要强调一下关于“避免生造词”的检查。
为了保持系统对用户的简单和清晰,产品经理应该确保系统内对同一个实体的名称、状态、操作使用同样的文案,与实体无关的信息也尽可能有自己的文案规范。尽可能避免相同概念采用多种文案的情况,例如“编辑”、“修改”这样的操作,常见都是对一个实体的更新,如果没有特殊区别,不应该在一个系统内同时存在。
4.用例路径检查
产品由若干独立的用例组成,每一个用例由不同呈现(页面)和交互(操作与反馈)组成。用例独立流程检查包括:
(1)用例路径长度检查
用例路径的长度往往来自于现实业务的复杂度以及系统业务需要,用例越复杂,往往路径越长,当系统希望额外获得用户信息那么路径也可能被延长。
通过竞品、标杆研究,我们可以找到常见完成某一个用例的参考路径长度,通过对比找到差别较大的用例,检查是否需要优化。也可以通过思路推导的办法,先将用例路径规划为最短路径长度,然后通过一个一个要求增加路径长度的理由逐步增加路径长度,最终得到一个合理的最短路径。
(2)用例路径阻力
单纯检查用户路径的长度不能代表用例设计的好坏,因为用例路径复杂度取决于路径上每一步阻力的总和。因此路径检查还需要考量用例整体阻力,这取决于用户在路径上每一步交互与操作的复杂度。
这一检查,我们可以通过[线框层]部分检查的结果来汇总得出。
(3)用例路径阻力分配检查
在检查完路径长度、路径阻力后,非常容易忽视的一步是用例路径阻力的分配。这涉及到用户行为学及心理学知识,例如“沉默成本”、“损失厌恶”等。
例如在一个重要却复杂的用例路径中,利用”沉默成本”概念,将业务划分为5步,其中把阻力低的环节布置在前四步,而把最复杂的步骤放在第5步。当用户进入第5步后发现都已经完成4步了,为了“沉默成本”将可能增加他继续完成该步骤的几率。
5.长业务路径检查
长业务路径检查的基本方法与用例路径检查基本一致,只不过长业务路径往往是多个用例路径的结合。
例如“商品购买业务”是“商品搜索”、“详情查看”、“商品选择”、“订单支付”、“订单跟踪”、“订单评价”六个用例的结合。因此需要站在业务路径角度审视路径,同时要保证各用例间的衔接,确保用户可以很好地完成整个业务。
6.新用户入门路径检查
新用户入门路径检查的基本方法与用例路径检查基本一致,只不过产品经理在此时要以新用户的角度来审视整个路径。确保产品核心价值路径可以被新用户成功探索,在用户的实体逻辑框架构筑期间,通过引导等手段帮助用户构筑逻辑。
例如可以通过隐藏高级功能选项,增加新手指引或者动效动画的形式减轻新用户操作复杂度和逻辑学习负担。
7.老用户高频路径检查
老用户高频路径检查基本方法与用例路径检查基本一致,只不过产品经理在此时要以老用户的角度来审视整个路径,确保老用户可以快捷,高效地完成业务。
例如减少不必要的弹窗提示,增加重复业务的模板管理或流程配置项。
有时,我们会发现针对“新用户”和“老用户”的检查结果会有所冲突,例如新用户需要更少的高级操作来突显关键路径,而老用户可能需要高级操作来准确完成业务。此时我们就需要在产品设计上进行权衡了。
在产品创立初期,技术资源少,检验产品价值时,可以更多考虑核心用户感受适度平衡。到了技术资源充足时,可以考虑把新用户和老用户的路径独立开,变成两套路径独立设计,这样就可以更精细地服务新老用户了。
随笔感悟3-运营经理的“漏斗模型”,产品经理的“白墙模型”
运营体系的同事经常使用漏斗模型来分析用户在关键路径中的流失情况,而我将“漏斗模型”的思维采用到产品[结构层]设计的分析中,形成了“白墙模型”(相信应该有前辈定义过该分析方法,但目前我的阅读范围没有覆盖,所以就自己取了个名字)。白墙模型是首先以用例为单位来分析产品[结构层]的。
在“白墙模型”里,用白墙面积代表用例路径上每一个页面的阻力。阻力又划分成两方面:一部分是“动脑复杂度”,另一部分是“操作复杂度”,分别用白墙的高和宽来表示,路径上的白墙的面积总和就代表这个用例路径的用户阻力。
一个用例要完成的事情,可能会拥有多个路径,例如例子上骨科完成商品挑选,可以通过三个路径“搜索挑选”、“分类筛选”以及“广告直连”。当然除了分析一个用例路径的阻力还不足以分析出路径的好坏,还需要结合通过路径达完成用例后,用户对完成结果的满意度。例如通过广告直连查看到的商品往往可能并不是用户真正想要的,而通过分类筛选出来的结果可能更精准。
“白墙模型”对我有什么帮助呢?
- 首先,这个模型帮助我建立了网站地图的思维,在大脑里将形成整个网站的网站地图,并给这个地图的每一个环节增加了阻力表示,让我可以快速找到阻力大的业务,满意度低的业务或者对可选用例路径进行筛选。
- 其次,为[结构层]的路径优化提供具象的表达,通过白墙面积高、宽的具象化,路径不同页面的具象化,帮助我在阻力(白墙总面积)已经无法减小的情况下,可以考虑结合用户行为分析进行阻力分配策略的设计。因为在我内心存在一种理解,那就是尽管路径阻力一样大,但是阻力的合理分配和调整仍然可以促进用户路径目标的更好达成。毕竟环境、用户、技术在变,阻力组合也要随之而变。
减小白墙面积,分配白墙面积,平衡阻力与满意度,就像是游戏,让设计变得游戏化,充满技巧和趣味。
[线框层] —— 确保用户路径上的每一步布局与交互设计合理
1.页面导航检查
页面是人机交互的信息承载,导航是页面跳转的衔接,在结构与文案已经在[结构层]定义清楚的情况下,[线框层]需要产品经理选择合适的导航样式承载页面跳转诉求。
- 逻辑位置展示检查。在进行页面导航检查时,首先我们要检查页面是否清晰告知了用户他目前身处什么位置?例如一些系统通过面包屑或者导航高亮的形式来告知用户。
- 关键路径强度检查。在进行页面导航检查时,在关键路径中,我们要考虑在[线框层]是否给予了足够的强度来告知用户他们下一步应该做什么?例如一些系统在业务路径中增加了步骤导航栏,标识用户正处于什么业务的什么环节,下一步环节做什么。
- 路径前后通道检查。在进行页面导航检查时,我们要明确在路径中某一环节某个状态是否可以回退上一步,进入下一步,以及是否可以跳出路径。确保进行回退、前进及跳出的导航操作存在。
- 多余导航检查。导航往往占用很多页面区域,结合业务路径上下文背景,我们可以针对部分页面进行导航栏优化,上下文环境中不需要的或者低频的导航去掉。
- 任务式引导检查。任务式引导式关键路径强调的一种形式,越来越多的系统希望通过任务式引导来减少用户负担,清晰准确完成产品业务路径操作。产品设计过程中,注意结合实际情况检查系统所提供的用例及路径,探索是否有形成任务式引导的必要和可能。
2.信息录入检查
因为信息录入是用户与系统交互时最耗用户操作的交互类型,与用户对产品的满意度有很大关系,需要用心设计,不可小视。信息录入的两种主要场景是用于信息登记及用于信息查询:
- 信息登记类型的信息录入,目的是将信息登记入系统存储以便后续业务的开展;
- 信息查询类型的信息录入,目的是告知系统希望检索的信息范围,以便系统为用户找到所需信息。
对信息登记类型的信息录入区域进行检查,着重确保用户理解所需要填写的内容,准确录入信息:
- 在文案及布局上,恰当的文案及区域划分,将关联性强的信息打包在同一个录入区域有助于用户快速地在大脑中调取需要填写的信息。
- 在组件上,可穷举的内容可考虑采用可穷举的交互组件(如下拉菜单),可校验的内容配合校验提示组件及时向用户反馈校验失败的内容,可自动带出的内容可利用级联等形式为用户自动带出,减少用户的思考和输入复杂度。
3.信息展示检查
目前计算机与人的主要交互形式主要还是基于视觉、听觉,部分硬件设备会支持触觉,本小节将主要基于视觉介绍对产品设计信息展示的检查。在视觉上可以采用的元素主要包括静态(文字、静态图片及布局)和动态(视频、动画、动态图片及动效)两种。
信息展示的重要目的是通过合理地使用静态元素与动态元素结合的方式向用户高效地传递信息,因此在进行信息展示检查时,我主要考量:
- 组件与样式选择:不同类型的信息适合使用不同的组件与样式,例如订单数据使用列表展示,百分比占用使用饼状图展示,商品列表使用图文混合列表,商品详情使用图文组合。检查你所设计的产品的每一个主要展示区域,通过与竞品标杆比较以及用户习惯检查需要展示的信息使用了恰当的组件与样式。
- 易读性:信息展示于页面,页面就像一个小型的产品,也需要[结构层]设计。主次分明,维护恰当的逻辑关系,并且提升通页的一致性将有助于用户更轻松地习得信息展示所要传达的内容。
- 实用性:用户阅读信息尤其既有的目的,信息展示设计得让用户可以更快完成阅读目的将有助于提升用户效率,进而提升用户满意度。当然有时这个实用性来自于系统要求,我们可以会考虑给用户暴露一些对产品有价值的“信息”来达到产品目的。
4.功能操作检查
功能操作是用户与产品交互的重要连接,功能操作就像信息架构的最末级节点,为了保证操作更为符合用户的逻辑,我们需要对操作的数量、文案、放置的位置进行检查。
(1)操作数量:
在思考可能存在的操作时,我们往往可以从现实业务中收集业务操作、从正向操作中联想到逆向操作、从实体上寻找“增删改查”操作或者实体间的相互操作。这些操作数量往往非常庞大,可是却不总是必要的。
例如对于订单下单我们可以支持取消订单,可是对于已支付订单就不应该随便设计取消支付操作了。对操作数量的控制需要产品经理仔细核对每一个所设计操作的必要性,以及某些低频操作是否可以用另外的操作所替代。
如果可以那么就可以为系统减少不必要的操作数量,从而减低系统实现以及用户学习产品的复杂度。
(2)操作文案:
好的操作文案就像好的[结构层]文案,帮助用户快速理解操作的含义而无需在查看操作释义。
检查操作文案时,我一般会检查并控制文案长度、与操作所对应的实体对照确定逻辑关系证件,并且尽可能确保操作与操作间不存在歧义以避免用户困扰。
例如对“购物车”设计一个[丢弃]操作就不如文案[清空]来得恰当。
又例如对一个“视频”设计[查看](实际是查看视频详细信息)和[观看]操作,就不如[详情]和[播放]来得清晰。
(3)操作位置与多入口:
从一方面看,用户可能会在不同场景针对不同实体触发同一个动作,因此设计产品时我们会考虑顺应用户业务路径设计衔接操作,以满足用户操作连续性。
但从另一个方面看,每一个操作就像是一个选择,对用户来说选择多了未必是一个好事情。产品经理需要掌握这两方面诉求的平衡,对核心业务路径提供操作便利上的支持,如果难度较大,可以考虑使用任务式引导。而对非核心业务路径上的操作,需要检查必要但是低频的操作并考虑将该其放入核心业务路径之外的承载页面里,或者隐藏到“更多操作”里。
5.页面信息自动填制与保留检查
用户在产品中或业务路径中流转时,会填制各种信息。产品经理通过合理的页面信息填制与保留设计,可以避免用户因为重复填制而产生的负面情绪和满意度下降。
例如电商平台下单时,产品级默认送货地址往往自动带出。
例如分步填写注册信息时,回退上一步或重新进入下一步,能保留的信息避免用户重新填写。
(来源:西部数码)