交互设计师的设计需求与分析(一)

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

应当避免一个产品变成产品经理自己的设计、或者某个领导拍脑袋的想法。作为产品团队的一员,交互设计师有责任和义务进行需求调研,拿到第一手需求资料,而不是接受莫名而来的需求列表。

这个比喻有点形象,当需求经过多人之手,传递到设计手里经常都变了味道,貌似所有接触过需求列表的人都喜欢改两笔,尤其是初成长的产品团队

很多设计师都是坐办公室里完成界面设计的。阅读本文后,倒是希望大家能去看看你们的产品市场,用户的使用场景,用户的需要,用户使用产品的想法,以及用户的期望。

收拾下,申请外勤出差吧~不去看看真正的市场,你可能发现不到,团队内有时候纠结的那些问题,对用户实在太微不足道了。

在之前的文章《可用性测试:让交互设计变被动为主动的利器》讲过,设计师的的强大后盾是用户,考虑他们的立场、思维和体验,你的设计一定不会差。

设计师,你理解需求了吗

我遇到的一个例子:

产品团队纠结“用户列表”功能界面是不是该新增一个按钮叫做“用户分组”。

为什么需要分组呢?

因为作为一个人员管理的工具,产品经理认为对于有相同属性的人员是应该归类为一个组,这样,调阅一组名单可通过组名来选取。

很多同事也会认为,这个新需求就是在界面上加一个新增分组按钮。如果用户勾选了列表里的一批用户名单,点击新增分组,输入分组名称,分组就完成了。

好像这就是日常~

直到有一天,跑过现场的同事收集到了情报:

分组功能很多用户不知道,也没用过。他们只是按名字和电话搜索用户而已。

会议上:

  • “我们是不是要培训,要教育用户?”
  • “是不是设计的不好用啊?”
  • “加个引导吧”

好了好了,别跑远了。可能起初的需求就有点拍脑袋的意思,这个需求用户并不觉得重要。

为避免上述情况,设计师最好领一下任务,任务做完,你就升级了~拒绝不合理需求,做有意义的设计。

产品需求到设计需求的转化

产品需求大多是纸面的文字,excel表,word文档,里面列出了产品需要的功能。我很好奇有多少人对产品需求提出过质疑,貌似每一个都超级重要。

这里我的经验是,产品需求与设计需求是相关联的,相辅相成,但并不等同。产品需求给了产品想要的功能模块定义,优先级大多与研发周期挂钩,优先级越高,说明越要最优先实现。

设计需求由主导产品的交互设计师确定,作为设计师的你需要进行需求转化,依据重要性,使用频次,层级关系等把产品需求转化为可视化界面。这些可能不是产品经理直接能给你的,你也很难自己一个人搞定,准确无误。

不要看到需求就一上来画线框稿,先来需求转化。

举个例子:

产品需求是:用户列表、业务1、业务2、结果分析四大模块;每个里面还有细节的功能点,这说明产品经理构想出了产品大致的轮廓架构。

交互设计师需要理解相关概念,其次,问问为什么?

产品经理可能会说“这是第一版,后续还要考虑XX功能,,当前XX功能不考虑,如果某个地方用的好,我们可能考虑…”

我相信你问了,产品回答可能会有点模糊,尤其是少竞品、从无到有、又要体现功能特色的产品。正式上线前,新生产品的功能块、使用频次、重要性、优先级等等产品经理自己可能也是模糊的,尤其是新手产品对产品的预期更不明确。

指望产品经理回答所有问题,他的压力很大的。设计师们,我们的存在是解决问题的。

对于不明确的需求,我们可以找用户。

别怕费时间,因为真的很有意义。

洞察需求方法一:通过“重要性-满意度”调查得出设计重点

这个阶段,设计师可以让产品经理安排几个用户,进行简单的测试。前期调研,哪怕人数少,也好过前期不做,后期找一堆人改。

把需求列表里几个主要功能名称,拿去给用户看看。

1.可以做一个功能-重要性-满意度列表,每一项进行打分。


重要度高,满意度低的功能点,应该是设计的重点。

可以设定重要性、满意度打分范围均是0-10分,综合分数表明机会所在,产品的机会就是用户痛点,也就是对用户很重要,但是用户非常不满意的功能项。比如,业务2,重要性得分:9,满意度3,那么综合得分:9+max(9-3,0)=15。之所以有max存在,是因为重要性比满意度权重更高。如:

  • 重要性10,满意度0;(用户觉得非常重要,但是非常不满意)
  • 重要性0,满意度10;(用户觉得不重要,但是非常满意)

以上两个,你觉得哪个是你的设计重点?

这里避免一个误区,是直接相加。因为重要性的权重更高,重要的功能是设计的重点。对不重要的功能做过多的设计其实是没抓住核心。

重要性-满意度打分是常见的用户调研的方法之一。具体分值指标,可以在调查表中设计并调整。

  • 不重要,很满意:属于过度满足,考虑减法或隐藏,别喧宾夺主(衍生或非核心功能的情况);
  • 很重要,不满意:属于用户痛点,集中在痛点区域的一系列需求,都是设计要点。

大的功能模块刚刚得出重要性优先级别排列,接下来,我们需要对每一项需求进行进一步拆分。如果这个事情是产品经理做了,那么设计师需要好好理解大功能下的小功能模块是如何切入进去的。

洞察需求方法二:核心功能的细分,绘制“Job Map”

对核心任务的理解,可以设置几个关键点串联:

Plan:计划——Execute:执行——Moniter:监控——Conclude:结束确认

来个栗子:德国博士Bosch,一个做电动工具的公司,把电动锯产品的核心功能——锯木头功能,做了Job Map。

采用当面访谈、用户调查、电话访谈、集中研讨等多种方法,依据细分步骤,搜集用户在每一步期望达到的效果(outcome)。每一个outcome,都是一个顾客需求。

收集并明确了需求,才可以定义设计指标,找出让用户提高工作效率的方法,或者设计出更便捷的流程。

总结

现在,明确产品的需求来源(1页PPT)及需求内容(2页PPT),来源大致是5W(调研的时间when、地点where、谁who、调研了什么what、为什么why),再做上面列出的需求洞察方法:重要性-满意度分析痛点、或画出Job Map。你就能够明确需求,排除需求干扰项,推动你的产品设计思路。

搜集和筛选需求不止这两种方法,以上两种方法是我在工作实战中的经验总结,你可以利用这两种方法的步骤,明确你的设计重点。

要明确你的设计重点,排查不合理需求。

可能,一些不合理需求并不是真的很不合理,只是不分析,它的重要性与层次会误导很多人,这个把控就在你了,产品或交互设计师。

当然,只有洞察需求还是不够的,我们还没转化完成。

对于每一个设计内容,都需要一个可衡量的指标,确定之后再考虑出图流程与步骤。

后续我会再发一些经验帖,上述仅是我个人偏好的方法汇总,当然方法不止这些,大家可以选取喜欢的方法进行需求采集与分析。感谢大家的关注。

 

本文由 @葛达尼尼 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自PEXELS,基于CC0协议

欢迎打赏支持原创
6人打赏
评论
有话不说憋着难受