其中,核心属性决定了一个自然人的底层核心属性,是在时间和际遇的长河中缓慢形成的,很难突然发生很大的变化。它和向往及偏好属性之间是相互影响的,最终影响用户的整体消费偏好。
比如说,年轻人比老年人更喜欢旅行和萌宠,男性比女性更偏爱于游戏和数码电子。不同的目标用户对同一类产品有着不同的诉求,所以,在体验设计上,就会有不同的倾向性。
其实,明确目标用户这件事,很多人都懂,但是很多人也常常会忽视。尤其是刚入职的新手设计师,往往想的总是怎么做出一个精美或者酷炫的设计,却忘了他的用户喜欢不喜欢。
## 体验如何分层?
拆解完用户,接下来,我们分析一下“一句话”方法里的后半句:用户发现的是哪种体验的问题。
用户在使用一个产品的时候,也许他会说,这个产品哪里体验好,或者这个产品哪里体验差。那么,我们能不能把“体验”分个类呢?
虽然体验看似很抽象,但也是可以拆分的。如果你了解过体验设计,那么你可能听说过Garrett老师在2007年出版的[《用户体验要素》](https://book.douban.com/subject/6523997/)这本书。
在这本书中,Garrett提出了一个从五个要素自下而上地建设用户体验的观点,如今看来,这样的划分还是非常系统、专业和适用的,而我们就可以利用书中提到的五个要素,把“体验”这件抽象的事具体落下来。
从图上来看,这五个层次还是很好理解的。我举一个我的例子,来给你简单地说明一下。
最近,我在一个电商App上用积分买购物卡,一张购物卡的面值是100元。我想购买500元,就将购买数量改成了5,点击购买,订单提交成功,系统把5个购物卡拆成了5个100元的单独订单。但在支付的时候,我犹豫了一下,我决定还是先买3张购物卡。
等我在原有订单上选择3张购物卡支付时,发现订单不能只选择3张卡,付款300元,只能一次性付款5个订单的500元,而且,取消订单也只能一次性取消5个订单。你看,体验很不好!
那么,这个“体验”,主要说的是哪个层次的体验呢?因为它是在流程上对极限情况并没有考虑完整,所以这里说的是框架层体验。
接下来,我们试着练习一下,看你能不能把下面例子中的体验分层。
半夜3点,你的肚子饿了。于是,你下单了一个外卖,但是太晚了,你担心商家不接单,你就等呀等,突然,页面弹出了这么一个提示,“商家接单了”,你饥饿的心一下子就稳了。
在等待的过程中,你想知道外卖小哥到底去取货了没有,距离你还有多远的配送距离。这时候,你再次打开了App,找到了“我的-我的订单-查看配送”,诶,还有5分钟,你的外卖就快到了。
这个例子,我相信你也不陌生。很多看似日常的体验场景,也是可以分出层次的:
App很明显地告知你“商家接单了”,这个提示信息是为了让用户看到,用弹窗或者某种更加亮眼的配色、动效等,这个体验设计属于表现层的设计;你通过“我的-我的订单-查看配送”的路径查看配送详情,这是在规划用户使用产品的路径,所以这块的体验设计属于框架层。
表现层和框架层的设计还是比较好区分的,接下来我再说一个结构层相关的体验问题的例子。
小红书这个App,我想你应该也听说过。在小红书早期的时候,主打的是内容社交,后面随着流量的增多,希望通过流量变现,就逐步上线了商城的功能。但其信息结构上,“我的”Tab里面只包含了我的笔记、我的收藏、我的点赞等和内容相关的功能入口,但“我的订单”功能入口却被放在了“商城”Tab里。
所以,在小红书的“我的”Tab里面,是找不到“我的订单”相关入口的,这个结构划分就会跟大多数用户的操作习惯相矛盾。因为,依据目前一些购物类App的结构划分,订单之类的功能入口都设置在了“我的”模块里面,用户已经养成了一定的认知和使用习惯。
你看,用户在小红书查找“我的订单”时遇到的问题,是不是就属于结构层的体验问题呢?
**在用户体验五要素中,表现层、框架层、结构层会直接关系到用户体验的好坏,设计师应该重点关注**。但如果想把用户体验做到更好,你还应该对范围层和战略层有一定的了解和研究。
范围层一般指的是产品要包含哪些功能,并且这些功能的优先级怎样排序等;战略层一般指的是要做一个什么产品、这个产品能满足什么用户的哪些需求、要达到什么商业目标等。**它们虽然不会直接影响用户的操作**体验,但是在大的方向上,也决定了用户体验的好坏。
当你熟悉用户体验五要素并加以运用到你遇到的每一个体验问题中,你就可以很快地定位问题的所属层次,也会很快地就想到精准的解决办法。
## 用户体验设计是一种底层思维
**用户是目标用户,体验是分层体验**。用户体验就是,你的目标客户从认识你的产品那一刻,到决定购买、使用以及他们在这个过程中一步步过来的感受。
所以,如果我们再一次遇到用户对产品吐槽,我们可以这样分析:
- 这个用户是我们产品的目标用户吗?
- 这个用户在吐槽什么问题呢?
- 他吐槽的这个问题是哪个层次的呢?
- 反映了他有什么样的需求呢?
- 他是不是为了吐槽而吐槽,纯粹只是刷个存在感呢?
分析工作做完,我们就有了一致的导向目标,各个职能就会想尽办法,把这些目标一步步拆解成可落地的执行方案,然后发挥自己的专业实力,最优化地解决问题。
其实,不光是处理用户的吐槽,我们还可以通过用户体验的角度去优化我们产品的现有设计。举个我最近在做的一个B端金融产品的例子,这个产品的目标用户是小微企业主。
当时,在拜访一个企业主之前,我们观察到这个用户在我们产品上的行为数据,只有转账、复核这种基础操作行为,也就是说,他对我们这个B端金融产品的其他功能完全没有兴趣。
可是,我们那个阶段的目的是希望用户能使用记账功能。于是我们试图去找企业主聊一聊,了解情况。
但是,他们平时的工作很多,很杂,所以一开始,这个企业主并不愿意花时间跟我们聊,后来我们观察他吃饭、喝水都比较简单,我们就买了些奶茶和零食,才打开了他的话匣子。
>
我们:记账功能好用吗?
他:好,很好,挺好的。
我们:好的话,为啥不用我们产品上的记账功能呢?
老板回复说:用纸和笔记习惯了。