详解交互设计师如何进行业务分析

有一些设计师尤其是像我这种没什么实战经验的新人,没有形成系统化的分析方法,在进行业务分析时,就会比较碎片化,拿着这样的分析结果进行设计以及和其他成员交流起来就非常困难。在此,经过学习大牛们的设计套路,分析整理了一套业务分析流程,用以指导以后的项目。

在4月初回归了团队,开始接手新的业务,根据平时看的书以及其他设计师的设计沉淀了解到,作为交互设计师对业务的了解程度是非常重要的,好的设计师刚开始接到产品经理给的需求时不会急着画交互稿做设计,而是花费很多时间及精力去分析梳理业务,甚至有时候会帮助PD一起来整理业务逻辑。如果一个设计师在给其他人员讲自己的设计方案(尤其是对上级),被问及“这里是怎么考虑的”、“为什么是这些功能逻辑”等业务上的问题而不知道如何回答时,就会显得非常得不专业。

1,了解项目背景

了解项目背景很重要,因为你在后续时间需要和多人多次描述你的项目,我现在接手的一个项目业务逻辑非常复杂,而且之前也没接触过这类平台的项目,所以PD很耐心地跟我讲解这个项目的由来、原因、展望等等,进行多次充分沟通,这样在后续跟其他同学描述你的项目时(尤其是上级)就可以很清楚的复述出来。做好前期的沟通工作对后续项目的进展也有很大的帮助。

一般来说,项目背景主要是:

1. 为什么做why:为什么要做这个项目,有什么原因导致需要做?用户有什么需求没有满足需要做?现在的产品存在某些问题需要解决?还是即将迎来XX节日需要做这样的活动?用户为什么要来使用这个产品?等等

2. 给谁做who:目标用户是谁?谁来使用这个产品?谁能看到这个产品?产品涉及的各方人员有哪些?等等

3. 做什么what:产品具有哪些功能?能给用户带来哪些价值?等等

4. 怎么做how:用户如何使用这些功能?这些功能如何实现?以及项目的排期是怎样的?等等

2,定位业务目标和设计目标

理解了项目背景后,设计师需要定位出业务目标和设计目标,《五导家设计法》中对两者的定义是:

业务目标:用[某策略]给目标用户带来[某价值],以实现[某变现方式]。

设计目标:用[某设计策略]给目标用户带来[某价值],以助力[某变现方式]。

我个人觉得这个定义已经属于哲学层面的概念,理解起来还是比较抽象和复杂的,我自己读过很多遍这段内容但在分析时还是很难运用起来,而且很多项目其实只有一个总体的目标并不会细化到这样的颗粒度。于是我去我们平台查阅了一些设计师的分析部分内容,整理组织一下发现大致的信息是这样的:

详解交互设计师如何进行业务分析

接着继续细化其中的规律整理得出两个目标的描述方式:

业务目标

详解交互设计师如何进行业务分析

主要是这几部分,可以组合其中一部分作为业务目标,例如:

1. 以XX策略为用户提供利益点,提高用户在网站平台的上线占有率

2. 通过XX功能为用户满足便捷搜索需求,从而提升用户在网站平台的使用效率,实现XX目标

设计目标

案例中的设计目标其实结构和业务目标基本一致,由于自己的实践经验以及能找到的分析案例有限,所以只说个人的理解:设计目标是相对业务目标更加具体化的策略和实现方式。其描述方式同样可以使用上面总结出来的套路,例如:

1. 用户1通过XX功能进行设定活动目标和XX方式,并在必要时进行XX操作,以帮助完成目标。

2. 用户2在XX平台进行活动配置,并查看实时效果,进行评估和验收。

3,场景化业务流程

PD在给设计师描述项目时,一般会讲解业务的流程图,常常比较复杂,且涉及各方资源模块的内容。这些内容可以帮助我们更好更快地理解整个项目的情况,但在设计分析时,一方面业务流程中的很多内容与设计无关,太多内容会对设计师的判断产生干扰,以致找不到设计环节需要关注的核心信息;另一方面业务流程图缺少一些细节内容或没有涉及每一个需要考虑的元素,造成最后产出方案时的设计缺失。所以在了解完业务后设计师需要以用户的角度来场景化业务流程。通过梳理细化流程图,设计师也可以更好的理解项目并查漏补缺每一个元素,以帮助PD进行项目核心信息判断及风险预估。

像我最近的项目中,业务流程复杂,涉及很多后端、算法的功能模块,甚至一些线下的人肉操作模块。涉及三方人员(后台管理人员、商家和平台),所以我就分用户按场景进行流程分析梳理,列出所有的操作路径以及各种状态,一方面检查每一个元素帮助自己理解业务,另一方面也常常能发现一些核心问题,并反馈给PD沟通,得到“这是个好问题,我怎么没想到”,“你理解地很到位”这样的赞赏。

PD给的业务流程:

详解交互设计师如何进行业务分析

设计师进行再梳理后的用户操作流程:

1. 基本流程

详解交互设计师如何进行业务分析

2. 用户1 操作流程

详解交互设计师如何进行业务分析

3. 用户2操作流程

详解交互设计师如何进行业务分析

4,找出项目的核心信息

需要罗列出来的项目核心信息主要包括:

用户背景:用户有哪些特征(基本特征和行为特征)?产品的使用经验?

功能类型:产品有哪些功能类型?各种功能之间有何联系及限制?

关键功能:最核心的功能是什么?操作是否便捷?

关键场景:最关键的使用场景是什么?这个场景的特征有哪些?会有哪些影响因素?

运行机制等:产品功能、算法、技术的运行机制是怎样的?(这个虽然是技术上的内容,但是设计师也需要了解清楚,以便设计的方案更接地气)

做这样的工作有以下好处:

一方面,可以和PD共同确立项目设计的重点,检验自己对项目的理解是否与PD一致,便于后续能够做出出彩的地方。有时候甚至可以圈定大家各自工作的职责范围及重点。

另一方面,在与项目组其他不了解业务的人员进行沟通时,也会更加方便,将带有这样分析内容的设计方案交付给他们能助其更容易理解并抓住重点。

5,记录问题点

记录分析业务中的问题点,与PD讨论确定下来,并且一定要达成一致!这样在与别人交流方案时,当他们问及同样的问题就可以轻而易举地解答并说服他们。

以上内容纯属个人观点,如有不合理之处欢迎指正。