作者:司马西(简书作者)
原文地址:http://www.jianshu.com/p/ee34d566766c
IXDC获授权转载
前言
从事设计与交互设计工作已6年有余,一直以来、无论圈内圈外都会谈到交互设计是什么?具体做什么?交互的价值是什么?交互设计的专业壁垒是什么?每每向别人解释这些问题时,总没有办法很好的答案。如:
-
思考人的问题、塑造用户行为、时间线上的体验美学。感觉高大上有木有,但也可能被认为假大空!!!
-
承接需求、分析业务规则、设计使用流程。会让人觉得格局略窄?
-
分析使用场景和用户动机、发现隐藏需求或欲求,为其提供解决方案。好像抢了产品经理的饭碗!!!
-
平衡商业需求和用户需求,选择合适的设计方案为企业提供更大价值。有点忽悠嫌疑,对吧!!!
-
用户调研、根据用户群体的认知,设计符合用户习惯的使用方式。来来来,解释一下认知这个词,噗~~~~。
为了解释交互设计的专业能力和交互设计的价值,我根据自己的工作经验和工作理解,从两大方面,共四篇文章来回答我自己的疑问。
一、交互专业角度
-
交互设计的专业性--用户体验认知与落地(本文)
-
交互设计的综合性--后APP时代交互设计师的主场(明天更新)
二、交互管理角度
-
交互团队管理者--塑造团队氛围的能力
用户体验认知与落地
如何通过用户体验认知并推动其落地呢?我个人归为6大点,如下:
1. 需求层次与用户体验解构
交互设计岗位是用户体验设计的重要角色。而用户体验是一个宽泛的词,可以应用在各类产品、各类场景,不具有落地性和可执行性。如果要真正落地和被执行,首先要对用户需求和体验进行解构,个人粗略的解构为三个级别:
-
核心需求----目标达成与否----核心体验(根本)
-
感知需求----视觉、触觉、听觉----感知体验(强)
-
任务需求----任务流&操作流----过程体验(相对弱)
面对不同产品,体验的侧重不同:
-
B端产品核心体验是第一位的,如公司业务管理需要、公司盈利需要、控制成本需要等;核心在于公司内部需要,重点要满足管理者、决策者。可以称之为“客户体验”。
-
C端产品感知体验要高于核心体验,因为C端同质类产品太多且基于相似的核心需求,所以感知需求就更为重要,如快速打开、准确找到、美观新颖、简单直接等;
-
不同产品都会存在过程体验,如任务流程,产品过程,对高级功能需求等,此类体验基于产品本身动态变化,如强势的B端产品(政府、医院)过程体验设计可以略弱,C端产品则需要精心设计过程体验。
面对产品的不同阶段,体验的侧重也不同:
-
产品导入期:重点满足用户的核心体验,在过程中一切向达成用户核心目标妥协;
-
产品成长期:核心需求被验证,积极改进感知需求,强化感知体验;
-
产品成熟期:打造品牌认知,感知体验和核心体验形成一个整体,形成品牌优势;
LOFTER作为C端、成熟期、小而美的格调性产品,其需求可以分解为:
内容消费者核心需求:阅读、收藏自己感兴趣的内容(快/慢)
内容创造者核心需求:记录、创造自己兴趣范围内的内容并传播;”
用户使用的感知需求:美观、自我格调;
根据其需求的关键词,将用户体验解构,如下:
个性:满足用户自我的兴趣需要;
准确:准确的遵从用户兴趣;
高效:快速的为用户提供内容,并尽可能的节省用户成本(时间和流量);
简单:减低用户认知负荷,简单就是力量;
传播:帮创作者传播,获得更多曝光;
美观:具有高要求的视觉愉悦性;
创新:坚持创新,为用户带来更好体验;
经过解构之后,产品的用户体验一目了然,根据解构后的准则进行针对性设计,如:隐形的收集用户兴趣、为其提供准确的内容、提升加载速度、打开即消费等,如此可以快捷的创造出相对出色的使用体验。
2. 定义问题与识别需求,修正需求和组织最优方案
首先交互设计岗位与产品经理的区别在于:
-
产品经理定义产品战略,用户群体,产品差异化竞争策略,落地于功能策略(包括优先级、取舍与克制)、商业推广、品牌运营时机等组合方案。虽概览全局、不乏谨慎细致、但鲜有克制;
-
交互设计定义用户在产品(社区、工具、电商)内的生活方式、生活感受、把握体验的节奏,落地于信息设计、情感设计、任务设计、工作流整合、架构设计、导航设计;虽细腻严谨、却往往拘于一点或一线,略失全局;
其次交互设计师在接受项目时的思考过程:
交互设计承接需求后,会了解需求要解决的问题,会了解问题产生的原因,会了解用户的动机,分析用户动几下可能产生的行为,会根据用户的认知能力和使用经验,来设计合适的展现方案,设计合适的使用流程,会考虑理解难度和使用难度。所以交互的思考过程:
-
重新定义或理解要解决的问题(如拉新、维旧、优化改进、修复错误),识别问题是否存在,发现问题的关键点。
-
识别用户需求强度 、理解问题在全局的价值,控制交互力度和节奏。
-
识别用户群体的认知能力,如以往的经验,学习成本、认知推断等,以此来组织页面元素。
-
识别用户所需时机(问题发生时机),根据感知阀限和情感诉求,来在合适的时机提供解决方案。
交互根据自己的理解和分析,用逻辑推论和数据分析的方式来进行需求修正、指导方案设计、为产品提供最优解,最大程度的解决问题;
备注:
认知能力取决于消费者的学习、经验、认知、记忆,属于认知心理学的相关知识 ;
认知阀限取决于消费者感觉,包括视觉、听觉、嗅觉、触觉等
需求时机产生于用户在域内生活的关键环节中,在关键环节中进行交互影响,容易形成更有节奏的用户体验。
以上将在把握用户体验节奏中阐述。
3. 数据收集与分析,用“相关关系”来取代“因果关系”
正如第2点描述,交互设计过程属于前期的创造性阶段;前期的用户体验解构、问题定义、用户认知、需求时机等皆是因果关系下的理论逻辑推导;而因果关系只是逻辑上可行,但因果关系本身是一个悖论,并不具有说服力。(简单理解因果关系如:“因为努力学习,所以成绩好”)
如果要让推导结果和方案设计更具有可行性和说服力,还需要通过数据呈现和数据证明的方式来在团队内外进行说服。即:利用数据的相关关系来告知我们“是什么”。(简单理解相关关系如:“火灾严重情况和消防站派出的消防车数量有相关关系”)
所以交互设计会进行:
-
尽可能收集现有数据,避免小样本下部分特征被放大而导致问题中心偏移。
-
观察并呈现数据之间的相关关系,利用数据之间的相关关系设计方案或判断需求时机。
如“微信运动22:00左右通知一天运动步数,是基于22:00与用户活跃的相关关系”;
亚马逊商品详情页的相关商品推荐,是基于大数据下商品与商品之间的相关关系;
-
根据数据之间的相关关系,推演数据预期并转化为可被计算的商业价值,使交互方案更具有信服力,如:
LOFTER电商化过程中,跟进用户操作路径研究,预计流量提升100%,实际提升80%,订单量提升50%;
LOFTER注册优化过程中,根据用户调研和访谈,以及操作行为数据进行优化,使注册转化率提升5个点;
LOFTER某一版本留存异常,经过数据分析定位相关因素并指导未来工作,使数据恢复正常。(数据涉及产品机密,在此不方便展示)
4. 需求响应与分拆
在经历了需求重新定义,数据之间的相关关系呈现和推演后,交互设计还有重要的一环即方案输出,在此不介绍交互四策略中:“删除、组织、隐藏、转移”,而介绍执行过程中相应的思路:
针对老产品的优化是梳理、分拆改进的过程,重点在于收集数据并将数据基于用例(用例为用户使用场景)进行呈现,根据用户使用频率和必要性将用例拆分为1、2、3等级别,按照级别进行顺序输出,优点在于:
-
可以明确输出重心、避免工作量繁多或被辅助用例影响核心用例,从而导致用户目标不到满足以及用户体验策略出现执行偏差。
-
可以团队内部分拆(按模块分拆为不同设计师执行),分担风险,保证输出质量的同时保证输出效率。
-
分拆执行但依然可以灵活上线(基于分拆上线或合并后上线),以此来分拆团队整体压力,控制各个环节的风险。
基于新产品输出的思路大同小异,相对于老产品规划的主次可见、用户行为习惯都已经建立,新产品的难点在于:
-
信息架构设计中尽量突出核心竞争点并尽量减少辅助功能的影响,以此来突出产品核心。
小红书的首页是商品心得分享;
网易美学首页是合辑;
云音乐是个性化推荐的歌单。
-
尽量沿用同类产品的任务流设计,继承已有的用户习惯,降低用户的进入难度。
-
由交互衍生的功能要尽量克制,交互场景往往尽善尽美,其衍生功能很容易影响产品 方向的明晰 ,如评论回复可能衍生私信,私信对社区类产品却是一种伤害,因为用户会建立联系后一起去微信;
-
创新性的交互形式,其操作线索要尽量明显,如“摇一摇”,“Pinterest”等。
5. 输出内容规范化与可阅读性
所谓规范化可阅读性是指个人、团队内部的他人针对输出标准保持一致,类似建立一种语言规范,在相同的语言规范下,团队上下游的合作人员阅读更快,理解更容易。
高度规范化,阅读性强的交互文档是交互设计师最基础的部分,也是专业性的体现之一;主要体现在以下方面:
-
输出内容的完整与严谨性
文档封面:项目概述,项目周期,项目参与者,项目阶段,更新记录等
问题定义:将上述的问题定义和需求理解,用书面的语言呈现给团队,方便统一目标;
数据呈现:将收集到的数据结构化并标明预期呈现给团队,提升工作意愿;
layout呈现:将项目架构图或业务流程图整理,或拆分或聚合,让团队概览整个项目;
-
统一站点地图的结构展示:以信息架构的方式组织模块,以任务流的串联页面;将页面内过于复杂的模块拆分为独立模块详细描述;
-
输出物进行页面编号和统一命名标准,如结构为“ 01功能模块 -A 页面(工作流)名称”;
-
统一页面内部结构:
用页面描述说明页面信息,如:聊天-P1至P4-左右阅读结构,作者:simaxi;
固定页面坐标和间距:如坐标始于width=50;height=50;页面间距=200px
固定结构,如APP 端统一左右结构,PC端统一上下结构或分拆单独页面。
用连接线进行操作指示,固定模式方便浏览,如往下游时行走与页面上方,往上游行走于页面下方。
统一标注方式:标明用例出入口,业务规则、界面规则等。
-
常用/独立组件模块化,复用或共同调用;如分享,评论,喜欢等将常用的、可独立于任务流的组件模块化,不但可以调高输出效率还可以降低错误可能。
-
用最简练的语言描述。如将文字转化为公式,将形容词等描述语删除,如:
尽量使用“≥” “=” "≤"、命名方式=名称+尺寸+颜色、排序方式=最近发布时间降序排列、小计=单价*数量+运费。
规范化可以粗略的分为交互输出规范、交互规范(如toast,action sheet ,alert,tab,tips,分步数量、导航等使用标准等) 、UI规范,UI输出规范、内容更新、邮件行文等规范等,此处不一一赘述。
6. 方案维护与跟进,拒绝被动
在完成了交互文档的输出后,会交付至整个纵向链条的团队成员,即使最细致的交互设计师也会存在丢失、遗漏的情况。所以配合过程中的跟进极为重要,在此罗列几种跟进过程中的注意事项:
1)跟进过程中的方案补充不能改变或影响该方案在全局的位置;跟进过程往往是针对某一点的补充优化,由于比较具象往往出现过度设计,由于过于细节也经常出现隔靴搔痒。跟进过程的补充如果要恰到好处,需要结合问题定义,数据预期,产品交互体验策略来综合考虑。
2)跟进过程中的妥协,不能损失核心交互;跟进过程中另一常见的情况是技术方案的限制或者说时间成本下的技术限制,此时经常出现砍需求、特别是砍体验需求,这类情况的妥协原则是:“所有体验类需求中都可以区分核心、次要、辅助,删减辅助类,次要的体验类需求来完成核心的80分,也是不错的选择。
3)跟进过程中的修改,涉及目的更改的需求要慎重进行 根基过程中有可能会出现对目的的更改,也许是因为新的场景、用户意愿、额外政策等,此类修改要重新进行问题定义,需求分析修正和数据整理。
4)跟进内容要及时整理进交互文档,保证文档正确性 无论是哪一种跟进修改,过程中的修改点都需要及时更新至文档中(甚至说明原因)保证文档的正确性,以方便团队及时知晓情况、作出变化。
另外交互文档还有归档备查的作用,所有产品的呈现都不能展现全部情况,交互文档或者产品文档的正确性归档对团队的后续工作极为重要。
推荐阅读:
原创文章,作者:Tinadmin,如若转载,请注明出处:https://www.iamue.com/21010/