基于情感化设计的用户体验重构–贝壳找房

Sponsor

基于理性逻辑的标准流程设计可能并不会像设计师所想的那样会被用户感知到，甚至会违背设计的初衷。既然理性行为的用户研究太过理想化，不如尝试站在用户的角度，根据产品使用过程中的负面情绪来设计体验流程，这种基于错误设计的反思逆向优化设计的行为正是情感化设计的应用。下面将以贝壳找房为例，阐述在产品优化过程中如何应用情感化设计输出人性化的产品体验。

项目背景

「买房」是人生大事，而「找房」起到决定性作用。

传统的找房主要依靠房产中介介绍、带看，过程费时费力，而对房产领域不熟悉的新人用户更是饱受「假房源」、「吃回扣」的苦；而贝壳的出现就是为了打通房源和用户的桥梁，让找房不再困难。

贝壳在2018年完成了从0到1的历程，但在移动端/web端都有许多的错漏和细节的不完善。从1到2的过程相对复杂，往往在立项之后会遇到一些项目之外/历史遗留问题——在修改响应式设计的过程中查看旧版网格系统设定，发现以早期链家网为模版的网格系统在设计时还没有到移动端设备爆发增长的年代（链家在2009年开始互联网化），因此没有考虑到众多尺寸的适配方案。改则费时费力，牵一发而动全身，不改则后续设计方案处处受限，所以干脆推翻重新设定网格系统。

详情在上一篇文章《贝壳找房的响应式网页布局设计》

也以此为契机，优化产品的用户体验。虽然过程非常曲折，但顺藤摸瓜发现问题本质的那一瞬间是豁然开朗的，过程中也参考了许多优秀案例和大神分享核心技术，收获颇丰，过往一些模糊不清的概念随着论证得到了明确的解答，所以把整个思考和实践过程整理出来分享给大家。

产品特点

目前还没发展到在线买房，大部分的交易流程都集中在线下。

贝壳的互联网化主要集中在「找房」阶段的信息呈现。

贝壳找房与其他产品的不同之处在于——房产是大宗需求，是刚需。

性格、爱好、情感等因素对最终决策的影响甚微，决定性因素是财富多寡。目前较为主流的分类方式将用户分为「刚需」、「改善」、「投资」三个类型，结合具体情况看，夫妻双方的孩子多数由父母帮带，因此刚需也要分为有无孩子的情况来讨论。

而且由于房地产领域的专业术语，贷款计算方式较为繁杂，很多用户都在初次接触这个领域时会经历艰难的“适应期”——了解“满五唯一”、“红本房”、“基准利率”等这些术语背后的含义,同时很多刚需都在买房之后就不再关注地产领域，直到有资本进行置换为止；

参考数据

情感化研究

1.情感化设计由来

概念是由唐纳·A·诺曼在《设计心理学3-情感化设计》一书中提出

情感化设计是旨在抓住用户注意力、诱发情绪反应，以提高执行特定行为的可能性的设计。通俗的讲，就是设计以某种方式去刺激用户，让其有情感上的波动。通过产品的功能、产品的某些操作行为或者产品本身的某种气质，产生情绪上的唤醒和认同，最终使用户对产品产生某种认知，在他心目中形成独特的定位。

2.使用情感化设计的原因

目前主流项目的优化流程是通过产品、交互、设计的讨论，将目标拆解、量化，然后调整整体架构、交互模式、视觉层级来正确引导用户完成既定目标。

但这样的用户研究方式太过理想化。

“事实上，理性行为在现实社会很少发生，人类的大部分行为都是非理性的，人类的消费行为往往会受到周围环境（时间、信息量、目标、兴趣、参照物、他人）影响，甚至有很多用户是通过分享链接直接进入某个产品页，而不是按照设想的从主页进入。”——《Don’t Make Me Think》

因此这次以「产品使用过程中的负面情绪」为准，判断产品目前存在的问题，并以减少或消除负面情绪为目标导向进行设计工作。

贝壳想给用户的「情感体验」是什么

「买房」是人生大事，信息爆炸的时代，「找房」的成果是起到决定性作用。

传统的找房主要依靠房产中介介绍、带看，过程费时费力，而对房产领域不熟悉的新人用户更是饱受「假房源」、「吃回扣」的苦；贝壳的出现就是为了打通房源和用户的桥梁，提升找房效率，让用户想起「找房」这件事不会如以往那么多负面情绪；

「情感」作为感性因素，如何量化并运用到项目中

在项目的前期调研中，通过对其他业务线的同事的随机采访，发现很多同事在使用自家产品时体验不佳，到最终演变成很排斥使用自家产品，同时用户也有很多类似的不良体验。

针对这种情况，需要建立起「情绪」的量化标准——代尔夫特大学积极情感研究实验室立足于基础理论模型，采集大量样本进行调研分析，提炼了人类的25个正面情感指标和36个负面情感指标。

结合正面和负面的情感指标，量化用户的体验，为提升产品使用体验提供解决方向。

用户产品体验中的负面情绪有哪些

「负面情绪」即「问题」，通过对采访对象的访谈、页面的操作记录等方式，经统计共有三种高频出现的负面情绪「挫折」、「烦躁」、「困惑」。

处理问题的顺序以用户体验流程为依据

困惑1:房源命名混乱

二手房源信息的命名方式目前较为混乱，没有统一的逻辑结构，且专业术语过多，对新人用户友好度很低；同时过长的文本会导致浏览效率低下；

但这个模式非常适合投资需求的专家级用户，专家用户有自成体系的判断依据，直接浏览搜索结果的信息，甚至不需要查看详情，就能判断是否自己中意的房源，而如今许多年轻人置业时对二手房的接受度有很大提升——开发较早，配套成熟，区域优势大。因此过于向专家级用户倾斜的设计已经不可取。

另一方面，拥有房源上传权限的房产经纪人很有可能会为突出房源特色填写非房源名称，提供一套规范也是为了遏制这些不规范行为。

购房的决定性因素是哪些？

参考贝壳研究院的内部数据和第三方平台提供的数据，除去「首付」、「贷款」等个人因素和法律法规要求，可以依次排序出购房要素——「楼盘名称」、「房价」、「交通」、「户型」、「面积」、五个要素；

五要素齐全，用户就能做初步的判断是否合适，而决定性因素是「房价」和「楼盘名称」，相对而言「户型」、「面积」的重要程度相对弱。

解决方案——按需求紧急程度来展示信息

设计实现

困惑2:web端首页导航过长难以识别

原版导航栏与背景较融合，用户的视觉中心可以集中在搜索功能上，但导航广度过大，选项过多且缺少鼠标悬浮（hover）标签的反馈，

导致用户花费较长时间识别标签的内容，同时过多的选项会对响应式设计造成影响。

原理分析

针对导航广度过长的情况，根据George A. Miller提出的7加减2法则把导航栏选项控制在9个以内，根据用户的行为层级将“二手房/新房”等细分业务收纳至一级行为。

重定导航架构

进过分析，一级行为共有8项，其中核心行为是「买、卖、租」，辅助行为是「查看百科、使用工具、查看市场现状、预测行业、个人帐户」，而二级导航负责众多的细分模块。

解决方案——首页导航改版

在修改了导航功能架构的基础上，在视觉上也改变旧版密集的视觉感受——导航高度调整为88px、标签调整为16px、

标签间距调整为48px；同时增加标签再鼠标hover状态的反馈——下划线，来明确“告知”用户鼠标所处的位置和即将前往的模块。

设计落地

在修改了导航功能架构的基础上，在视觉上也改变旧版密集的视觉感受——导航高度调整为88px、标签调整为16px、

标签间距调整为48px；同时增加标签再鼠标hover状态的反馈——下划线，同时为了避免二级菜单在视觉上和一级导航的标签重合产生混淆，标签的交互分为「悬浮」和「点击」两个状态

挫折1:web端「找错城市」「找不到房源」的现象频繁发生

用户情绪曲线分析

web端产品「定位」功能视觉层级过低

大部分接受调研的用户和同事都表示在使用web端产品时初次修改定位时都没找到「定位」button,发生了不符合心理预期的「挫折」，四处寻找后终于找到在左上角home键旁边找到了自己所处的定位；

「定位」不在「视觉中心」

让用户和同事心理预期落空的原因不是没有「定位」button，「定位」有，被安排在左上角的「Home」button旁。

旧版设计之初的房价（尤其一线城市）没有今天这么高昂，城市移民能够通过个人的努力加上时代机遇，基本能实现在工作地购买房产，因此「修改定位」这个需求在当时被认为是低频需求，因此没有安排到视觉中心——这一点可以在链家web端产品得到验证。

搜索标签视觉层级过低

在主流认知中，首页的搜索框应该承担的是全局搜索功能，当然这也不绝对，与具体的业务模式相关，但目前的标签形式与副标题没有明显差异，且层级过低——几乎所有新入职员工在搜索新房内容时都“忽视”了搜索标签的存在，“被”搜索了二手房内容，结果显示为无该房源；可想而知C端新房用户的使用体验。

视觉中心区域层级过多，变化趋势不明确

web端旧版主页的视觉中心区域层级过多，变化趋势不能够引导用户的视线走向，导致最突出层级为slogan,而不是搜索框，分类标签在多次测试中都被“无意识忽视”。

调整标签形式

嵌入式的标签的视觉层级更突出，可以很好避免旧版标签导致的误操作。

嵌入式标签不能超过1个

在确定了「定位」作为嵌入式标签后，业务类型也需要调整，但是直接再次加入嵌入式标签会造成视觉冗余，同时用户在搜索前必须进行两次「选择」，这样的体验不符合大部分搜索引擎多年培养的习惯——Google，百度两大搜索引擎都是无标签的搜索框，大部分互联网用户都会习惯直接输入检索内容。因此嵌入式的标签越少越好，不超过1个，否则会让用户产生「烦躁」的情绪。

唯一的搜索框标签该留给「定位」还是「房源类型」？

形式上无法解决，就回到交互层面解决

旧版的搜索流程需要用户在首页完成「定位」「房源类型」两项选择再输入关键字进入搜索结果页；这样的交互流程符合产品的实现模型，因为「二手房」、「新房」、「租房」等业务的数据库不同，提前进行选择可以避免得到错误结果。

但从用户的心理模型出发，最佳检索就是直接输入楼盘名称就得到正确结果——实际操作不可能这么简单，因此交互应该向减少「选择」方向修改；

「房源类型」的选择可以转换为程序自动匹配关键字，进入对应的房源库，提供符合条件的房源——房源类别不是用户搜索前必须搞明白的事情，应该是产品回答用户问题，而不是产品向用户提问。

「直接抓取ip地址为默认定位」不符合需求

今天“一线打拼，二三四线买房”是大多数打工者的最优解，行为模式发生了变化，「修改定位」由低频需求变为高频需求，「直接抓取ip地址为默认定位」的交互不符合需求，因此「定位」做搜索框标签更合适，将「房源类别」的选择留给产品，从而减少搜索前「选择」。

设计实现——「定位」功能视觉层级提升

二手房和租房房源的关键字会有重合

但房源库之间有重叠的内容，「租房」和「二手」就有可能重复，因此在进入搜索结果页后仍然有切换房源类别的需求，而出于技术上的考虑，合并所有房源库，以标签形式呈现房源类型难以实现，因此「房源类型」button在结果页需要呈现。

二级导航区域过大

上图为旧版本的搜索结果页导航设计，采用的是混合布局类型，可以呈现的功能较多，方便用户在不同层级间跳转，但占据了过多页面导致内容展示效率不高。

1.「在售」、「成交」都属于类别筛选，应该收纳到二级导航的类别筛选器

2.功能重复——二级导航和一级导航都有「小区」和「贝壳指数」，「地图找房」也有重复；

精简二级导航区域增加可用面积

「成交」、「在售」本身属于数据类，与搜索房源无直接联系，仅在用户需要参考因素时会产生需求，收纳至「贝壳指数」更符合用户的心理预期。

二级导航采用收纳形式，提升内容区的可用面积，取消旧版「小区」、「贝壳指数」等重复标签。同时在二级导航保留「房源类型」button,满足切换房源的需求

设计落地——业务分类收纳至二级导航

烦躁：用户不断地重复操作和面临「选择」

买车的流程和买房类似，买家都只知道自己的预算范围，最终下单之前用户都会随便逛逛，货比三家，很少提前列好详细的需求清单，也不会有4s销售一见顾客就问要不要天窗和要不要倒车雷达，这些不重要不紧急的需求不会一开始就明确。

复杂界面只有熟悉行业的投资型用户才能应付自如，只有他们才清楚这些条件背后对价格和居住体验的影响；

用户进入搜索结果页后，首先面对有20 选项的筛选器，大部分用户在结果页面对扑面而来的二十多个选项很容易引起「困惑」和「不耐烦」，因为他们清楚的只有自己的预算范围，在勾选了「区位」「房价」「建面」「房源特色」后，筛选器会向下展开「朝向」「楼层」等非核心要素选项，此时筛选器基本上占据了所有页面，用户需要往下滚动才能看见筛选得到的结果。

筛选条件比较繁琐，但无论优化程度如何，勾选筛选条件本身是打断“心流”的事，不是最优方案——用户肯定不愿意面对和飞机驾驶舱一样密密麻麻的筛选器。

初期的修改方案是分层级显示/收纳筛选条件，在形式上先解决旧版筛选器占面积过大，选项过多的问题。

情绪曲线分析

「筛选器」占据过多页面

旧版直接呈现筛选条件，方便用户快速勾选，但是面积过大也导致了内容展示效率低下，筛选条件分布过于零散，容易造成用户操作时的停留，影响使用流畅性。筛选器位置是固定位，不随网页滚动置顶显示，使用上非常不便。因此「筛选器」的优化方向时全局显示和收纳选项，因此「抽屉式」的二级导航可以满足需求。

解决方案：筛选器收纳至二级导航

目前二级导航的余位较多，收纳至二级导航可以将筛选器“隐藏”，在用户需要时才呈现，让用户不会在一进入搜索结果页就面对复杂的筛选器。

用户不想要「筛选」，只想要结果

但房地产本身因素较多，无论如何简化筛选器，「勾选选项」这个行为本身仍然存在。

从用户心理预期出发，用户并不想要「筛选」，只希望一键得到满意房源。

「形式上没有最优解，就往产品流程方面想。」

「记录用户行为」的推荐算法不适应房产类产品

目前推送算法借鉴了电商类产品的做法”记录用户的搜索行为，以此作为参考匹配同类产品进行推送”。

但搜索行为不一定和用户需求匹配。

1.用户随机搜索了当地最高档小区，系统以此为依据推送类似高档小区，而实际上用户是刚需置业，这就造成推送无效化，进一步让用户感知为产品“不懂我”，在情感上留下不好的印象；

2.用户搜索了预算内A区的房子，系统记录到用户行为后，只推送A区附近房源，而符合用户预算的房源,C区也有但系统没有推送；

这一点房产类和电商类产品的需求差异导致的——用户使用电商类产品的需求及时性较强且多变，且交易数额普遍偏小，因此用户主观意愿权限更高。

大部分用户财富总量是线性增长，同一区间内的需求有很高的重合度——目前年轻人或多或少需要长辈资助才能凑够首付，房贷则自行承担；因此用户在建立账户时确定了自己的需求类型后短时间很少会有变动；以此为依据，设定用户可选择的人物模型，预设一些大概率选项，提升首页推送的有效率，尽可能让用户在接触筛选器之前就找到合适房源，从而减少用户面对「筛选器」的几率。

「标签化」用户，降低筛选器使用频率

用户进入搜索结果页，以用户注册时填写的需求类型为默认选项，为用户推送房源，用户也可以根据需要自行修改需求细节。以用户模型为依据进行推送，可以避免用户偶发行为对推送算法的影响。

交互流程变更

以「人物模型」为依据提升推送算法准确度，减少用户接触「筛选器」的可能。

列表无法直观呈现房源具体位置

目前产品在各端都主推「列表模式」，（主流产品如安居客、中原地产等竞品也是如此）同时引导用户使用「地图模式」，

列表模式的优势是房源信息展示相对全面（字号较大，有房源内部图片），但缺少地理位置的直观展示。

大部分楼盘在对外宣传时都号称临近地铁，但有过看房经历或了解宣传方式的用户都清楚实际情况往往大相径庭，目前普遍做法是地铁口1km范围内都算做是“近地铁”，但早晚高峰的步行感受就是天差地别了。甄别房源实际情况也是看房费时费力的原因之一。

地图模式在移动端交互手势过多

「地图模式」在移动端的交互手势较多——单手「点击」、「平移」、双手「放大缩小」，而列表模式的交互手势主要是「点击」、「上下滑动」，操作负荷较小。

怎么提升地图模式的展示效率

地图模式提供更好的地理呈现，但是在实际操作中，居住区内的楼盘较为密集，容易出现楼盘信息互相重叠、干扰信息展示的情况，因此需要重新设计不同比例尺情况下的楼盘展示元素。

问题集中在比例尺较大的情况

上下重叠的情况较为棘手，在原则上用户只需要把放大比例尺就能看清重叠的标签，问题较为集中在比例尺较大的情况。

旧版解决方案

旧版解决方案是压缩字体和标签两侧间距，缩减标签的长度来减少互相重叠的情况。但在视觉上会造成过于紧促的视觉感受,同时旧版标签不再适应4px原则，需要重新调整尺寸。

设计实现——标签重设计

为解决旧版的紧促感，标签两侧间距20px，上下间距8px。

减少标签内容

先从标签形式着手，从左往右依次显示「房源名称」 「单价」 「房源数量」，显然「房源数量」不是必要的判断依据，可以删减。

虽然房源标签的长度减少了，但居住区本身比较密集，仍然出现较多重叠的情况。

失败方案：「上下错位」、「标签收纳/展开」的解决方案

方案一：

设想过标签上下错位的方案，但仅限于小范围内使用，一但全局应用会影响视觉的统一效果，显得杂乱，且在极限密集的情况，即使上下错位也无法解决；

方案二：

标签的收纳/展开的方案，虽然能够解决重叠问题，但在交互上需要用户单机/悬浮鼠标，重叠部分才能显示；而用户在地图模式下快速浏览目标的主要操作是平移 滚轮/双击放大，直接增加新的交互方式会增加用户的操作负担，同时增加了地图模式在web端的运行负担，因此方案二性价比不高；

形式上找不到最优解，那就优化流程

能不能减少用户主动点击重叠部分的楼盘的概率？

用户在依次选择完「行政区」、「片区」后，心理预期应该是「楼盘价格」，判断是否是匹配自己的预算区间，然后才会进一步查看房源信息，而「楼盘名称」在比例尺较大的时候则相对次要——买得起是最重要的，房源叫什么不是太重要，所以解决问题的关键在于辅助用户快速判断是否自己预算区间，提升检索房源的效率

重设标签元素的层级关系

根据用户的心理预期和需求的优先级，重新排列标签在不同层级的显示元素。

大量重复的标签色块也是冗余信息

从视觉角度出发，大量重复的标签色块也是冗余信息，用户实际上需要仔细辨别其中的价格，体验并不好，

需要再次优化标签的呈现形式来提升用户甄别信息的效率，避免用户在使用过程产生烦躁情绪。

解决方案：用色彩建立价格体系

标签内容已经确定的基础上，只能从色彩方面入手。用颜色建立价格高低体系，用户可以直接通过颜色来了解价格的大致区间，快速寻找到符合预算的房源区域。

减少用户在不符合预算区域的停留时间。以深圳市为例，贝壳研究院的数据显示均价57350元/平为品牌色——强化用户关于贝壳品牌色和房价的关系。

在贝壳蓝基础上提升明度用来显示低于均价的房源；在贝壳蓝基础上加入红色同时降低明度，形成有高贵神秘含义的紫色显示高于均价的房源；

至此，解决了一部分以情感为导向发现的产品交互、设计层面的问题。

当然工作并不是到这里就结束了，这次迭代是在用户体验研究方式趋同化的今天，所做的一些尝试，希望从不同的角度和不同的方式，真正能解决「找房难，买房难」的问题，哪怕只是一些细节上的调整，也可以给用户带来好的体验，那么前期的工作也是值得的。我一直相信“完美”是不存在于世界上的，只有“合适”与否罢了。同理将产品做到极致理性的完美，结果只能是做成一部机器。也希望能在后续的研究中继续丰富情感化设计的理论体系。

——————————————————————

参考资料：
Ant Design 情感化设计
https://zhuanlan.zhihu.com/p/55364776
《贝壳找房的响应式网页布局设计》
数据支持：
深圳贝壳研究院
作者：zozo94w

赞助商链接

喜欢这篇文章吗？欢迎分享到你的微博、QQ群，并关注我们的微博，谢谢支持。
版权：除非注明，本站文章均为原创文章，转载请联系我们授权，否则禁止转载。