上一篇讲 **背景经历: **综合考察候选人的背景、求职动机与预期。
这一篇讲 设计技能: 考察候选人具体的UX设计能力。
设计技能篇
这一部分一般在面试中花费最多时间,考察设计师具体的UX设计能力,围绕候选人的作品与项目灵活询问。
讲一个你最有代表性的项目
通常在做完自我介绍和基本的信息调研后,这是第一个重点问题。用来考察候选人的业务背景+专业技能与招聘方的匹配度。
往往挑选项目的要求有:
- 需要和招聘方目标岗位所匹配
- 与当前职业生涯中,专业水平相匹配
1-3年应是一个单人需求,3-5年应是一个多人合作的项目,5-8年应是一条业务线或产品发展中的设计演变等。
讲一个帮业务达成业务目标的项目
考察设计师对业务的理解、业务目标的转译、设计思路核心逻辑、设计的有效性验证(结合数据分析)等。
这是一个面试的大杀器。因为每一个点都需要自己亲自操刀过,才能言之有物。
而很多设计师败下阵来都是在——最后设计有效性的跟进上。因为绝大部分设计师做完项目不会再去复盘和分析数据变化(项目前期也没先保存下来)。
可参见:设计师需关注的全局数据指标、设计师要关注的局部数据指标
讲一个较有专业难点的项目
也是一个面试的大杀器。因为专业难点的定义需和自己职业生涯里专业水平的提升有关。
1-3年或许还可以说一些技术上的难点;3-5年应是方法论或深度问题分拆与创新的解决手段,可以为团队所复用的经验等;5-8年就更多要关注在业务与设计目标的转换、大规模的系统性问题的分解及推进上,更多以年为单位去讲。
另外,有个陷阱是:有时,题目会去掉专业二字。此时,还是得聚焦在专业难点上。毕竟面试是设计师,不要把回答变成难点在公司环境、人与人的配合、或流程等非专业点上。
讲一个让你最有挫败感的项目
最不靠谱的回答就是装常胜将军说没有。如此回答只会落下自省力不足的印象。
这问题是考察候选人是否会复盘的习惯。有不足或失败的经历不重要,重要的是能在失败后总结复盘,避免第二次失败。而且往往有失败,意味着候选人勇于探索,不设边界,挑战一些高难度的任务,从而才有失败的经历。
这个问题可以转换成最有代表性、业务赋能、专业难点的项目。但需要失败的,有复盘的。
你在前公司学习到最大的收获有哪些?
考察候选人是否在相应的职业生涯阶段学习到最关键的能力。所以能比较好的回答这问题,需:
- 能定义所处阶段最关键的能力是什么
- 此项能力都包括哪些,获得的路径是什么
刚入行可以是职业化,规范的设计及自查流程;对发版流程了然于胸,Beta、RC、GA等;工作3-4年或许是某项专业能力,设计系统、信息架构、可用性测试、大型改版等。
如何证明此项目是成功的?
要证明项目是成功的。除了结合设计目标自我评价自圆其说外,需要:
内部的反馈机制。包括项目 Stakeholders 各方评价、VP层的认可、内灰阶段用户的反馈、可用性测试评估等。
外部的反馈机制。主要是设计目标相关的数据监控,包括改版前后的核心数据比对,及长期数据的同期对比(避免短期的数据上升是该时刻数据异动所造成的)。
如何度量一个产品用户体验的好坏,有哪些参数?
与上一个问题紧相关。通常上一问题通关了,才会由点及面地提问这个问题。
在这些年,设计一起看的书 里有提到一本《用户体验度量》有系统的解决方案。但需要强调一下,用户体验的定义本来就是主观的感受。所以度量用户体验也是汇集一些比较大比例的共性体验特征——通过不断叠加主观的观点,拟近「客观」。
用户体验度量归根结底就是三种:客观的效果、效率和主观的满意度。
- 任务完成率(效果)
- 任务完成时间(效率)
- 满意度和推荐值(满意度、视觉愉悦度、彩蛋等)
锚点可以比较:与过往表现、未来目标、竞争对手比较。
是否做过设计系统?在设计系统的构成及落地上有何心得?
在比较大型与业务纵横耦合的产品中,设计系统不仅可以保持全局体验在代码层到高保真设计的一致性与稳定性,还可以通过设计组件将设计师的生产力释放出来。
可以在设计系统的架构构成、通用与业务组件的分类方法、组件库的原子定义、设计指南如何约束组件使用场景及保持其场景扩展性、样式在代码中的映射链路中讲起。因为这些通常是判断候选人是否真正深度构建过设计系统的核心问题。
一般接到比较复杂的产品,你如何保证设计方案能满足各种不同类型的用户的需求?
首先是对用户的需求按照一定维度(通常不超过两个)进行分层。然后再用不用权重标记,运用相对应的设计方法。这些方法组合起来可以形成一个设计策略。
比如说,按功能的常规与高阶性分类(对应的是普通与VIP用户)形成梯度。用频次作为权重,优先满足用户基数大的高频功能。在确定主要操作流程,稳定好信息架构后,接着在此基础上叠加小众VIP用户所需的高阶功能。
可能为了能在架构上多叠加功能,对架构的弹性和功能的可发现性等诉求就会多一些。
当然按频次、用户比例是一种权重,按商业目标、用户核心程度、全球化可访问性也是一种权重。重点是如何围绕公司业务发展的底层模型与商业逻辑来定义权重。
做过什么类型的用户测试,定性和定量有什么区别,分别可以怎么做?
用户测试的种类就比较多了。有用户访谈、走廊测试、可用性测试、专家测试、眼动测试、脑电测试、纸质原型测试、问卷测试、A/B测试。可以挑几个实战过的来介绍。
定性与定量这两种互补类型的用户研究在迭代设计周期中都扮演着重要的角色。定性研究指导设计过程;定量研究为基准规划和投资回报率计算提供了基础。
定性数据提供了参与者体验系统可用性的直接评估并产生的结果,并推断出设计的哪些方面存在问题,哪些方面体验/设计得很好。一般由观察结果组成,确定容易或难以使用的设计特征定量数据。
定量数据提供了对设计可用性的间接评估。它们可以基于参与者在特定任务上的表现(例如,任务完成时间,成功率,错误数量),或者可以反映参与者对可用性的感知(例如,满意度评级)。
定性一般用来确定一项设计是否在体验达标。但在持续优化的过程中,需要定量数据来对比和量化具体的客观数据(甚至来于其他商业公式结合)。
有时,为了理解界面的具体可用性问题,设计师通常需要使用定性的方法来补充定量的数据。
解释一下MVP是什么?
也称最小可行性产品。即该产品仅包含了支撑其运作的核心功能,主要用于从0到1验证产品的市场生存空间、可用性与有效性。MVP不是若干个功能的集合,而是一款产品,为了节省时间和金钱开发出来的过渡产品。
数据监控时,何时要用UV,何时要用PV?
可参见:设计师需关注的全局数据指标、设计师要关注的局部数据指标。
考察候选人对基本数据分析的经验。
PV 是衡量页面 / 功能是否吸引用户的最主要的数据指标。PV 之于页面 / 功能,就相当于收视率之于电视。
UV 与 PV 都是同一类型的指标,用来反映内容 / 功能对用户的吸引程度(黏性)。但UV 更侧重于反映内容吸引力在用户群中的覆盖程度,一般用来辅助 PV 判断内容的定位。
例子一:一个页面,UV = 30% DAU,则比 UV = 10% DAU 吸引更广泛的人群。
例子二:一个页面,PV 较高,而 UV 较低。则说明整体吸引力强,但却是一个小众的内容,有黏性很强的受众。
你有做过角色建模吗?
基本的用户研究问题,无论设计师的背景是什么都可能被问到的问题。当我们讨论产品、需求、场景、用户体验的时候,往往需要将焦点聚集在某类人群上,用户角色便是一种抽象的方法,是目标用户的集合。
当然角色建模也有它的局限,在很多公司沦为形式主义,并没有什么参考性。另外面对全球化的海量用户,刻意使用角色建模,还会损失一些潜在的机会。
可用性与可访问性有何区别?
考察候选人在实际工作中有无意识到可访问性一类的体验问题。
在Web前端开发界,有三个词经常被提及:可用性(Usability)、可访问(Accessibility)和可维护性(Maintainability)。
其中可用性是指,用户使用产品的效率。在体验过程中,用户能否很快上手,并顺利完成任务,效率如何,以及这过程中用户的主观感受可好,是从用户的角度来看产品的质量。可用性好意味着产品质量高,是产品的核心竞争力之一。
可访问性是指,内容对于残障用户的可阅读和可理解性。提高可访问性也能让普通用户更容易理解内容。
可用性更专注在核心用户及场景,重点在效率上;而可访问性更关注体验的边缘异常,比如残障(失聪、色盲色弱、无法打字等)及异常环境(噪音过大、过暗或过亮的房间等)。
如何去除用户测试中的主观性(比如用户体验地图)?
很刁钻地考察候选人对用户测试认识的深度。因为现实来看,主观性其实是无法去除的。
可以通过多次同类问题测量,平衡掉个人主观上的浮动,再用多样本来平衡到不同人认知之间的主观浮动。
产品迭代中的功能你一般是如何分类的?如何判断一个产品是否要保留某个功能?
考察设计师在日常接受任务时,是如何对功能进行分类的,侧面也可以反映候选人对产品结构上的解剖能力及业务转译能力。
一般来说包括:
- 核心功能(我有人无的能力,一般会是产品的核心竞争力)
- 补齐功能(市场上众多竞品都有了,成本小,适合借鉴模仿)
- 优化功能(用户普遍抱怨的体验痛点,往往是因为过去版本做得不是很好)
核心功能一定要重点做;补齐功能时刻监视行业变动,敏捷补齐;优化功能有空就做。
当你向上沟通设计方案是遇到过哪些困难,当上级大幅度推翻方案时,你是如何处理的?
考察候选人在向上对齐目标及验证设计解决方案有效性上的能力。固然向上的沟通和推进自古都是困难的。可参见:为什么90%的时间管理都是无效的
当上级大幅度推翻方案时,每一个人都有自己的应急方案。但遇到这样的问题,更重要的是思考另一个问题——「如何提前预料与避免有大幅度推翻方案的情况」。
| 往期相关:体验设计师面试问题集(背景经历篇)
| 往期相关:设计师需关注的全局数据指标
| 往期相关:设计师要关注的局部数据指标
| 往期相关:为什么90%的时间管理都是无效的