|
|
|
|
公众号矩阵

设计师要怎么做产品分析?来看总监的经验!

UX设计流程中,需求分析是绝大多数流程的开端。所以今天,我们先从产品分析作为切入点,进入到 UX 进阶知识中的第一篇分享。

作者:超人的电话亭来源:优设|2020-11-18 14:01

UX设计流程中,需求分析是绝大多数流程的开端。所以今天,我们先从产品分析作为切入点,进入到 UX 进阶知识中的第一篇分享。

产品需求的认识

产品需求分析被念叨了很久,但是很少有人能真正搞明白我们在分析的是什么东西,以及作为一个和产品经理工作内容有交叉的知识点,有很多网上的分享只是照搬了他们的要求而已,但并不适用我们的工作。

所以在理解设计师所需的产品需求分析技能以前,我们要首先搞明白,产品需求本身是什么!

通常展开项目前,要先制定“需求”,即这次项目要做什么事情的具体指示,是要开发新功能、优化操作流程、调整界面样式,还是修改现有BUG。

只有有了项目的具体指示,我们才能去推进项目的执行,约等于游戏中的“任务”,没有任务你就只能在地图中瞎跑。

产品经理就是分发任务的 NPC,他们会将需求制作成相关的文档,供团队成员查阅或参考。

说起文档,我们就要了解,产品提供的文档包含了3种常见的类型:BRD、MRD、PRD。

1. BRD:

  • Business Requirement Document 的缩写,也叫商业需求文档,是在开发产品前,对商业目标、战略愿景进行分析和说明的文档。

2. MRD:

  • Market Requirement Document 的缩写,也叫市场需求文档,是针对面向市场范围进行调研、统计、分析并得出结论的文档。

3. PRD:

  • Product Requirement Document 的缩写,也叫产品需求文档,是对所开发产品包含什么功能、逻辑进行具体描述的文档。

这三层文档是一个从宏观到微观的推导过程记录,先从战略层出发,描述大方向上要做的目标,再根据这个目标划分出的市场范围进行调研分析,找出应该提供什么样的功能点才能符合市场的实际需要。

最后,在产品需求文档内,将产品包含的所有功能、逻辑详细描述出来,比如一个退货流程需要经过哪些步骤,退货成功和不成功的条件等等。

PRD 包含了我们这个版本中所需要做的具体工作内容,而 BRD、MRD,是为什么要做这些产品功能的说明,这就是一套完整的产品需求说明所需包含的内容。

BRD、MRD 这两种文档,出现的频率并不高,通常也只在新产品立项、大版本调整的时候才会做。而 PRD 文档则是我们主要接触的内容,需要深入了解。

产品需求PRD的具体认识

PRD 文档作为产品需求说明的文档,也可以理解成是一份产品说明书。它最大的作用就是以书面的形式,记录下来产品要做成什么样,避免口头上的随意性。

一份专业的 PRD 文档中,通常会包含这些模块:

  • 版本信息
  • 文档目录
  • 版本概述
  • 产品结构
  • 功能说明

下面,我们分别对这些模块进行简单的讲解,进一步了解 PRD 文档的细节。

1. 版本信息

版本信息是这个文档的有关 “属性” 记录,记录由谁修订撰写,时间点,版本号,面向系统等等。

这个记录是方便在后期回看以前的 PRD 时可以对上时间线或负责人,通常由一个简单的表格来呈现,比如下面这样。

2. 文档目录

文档目录则是整份文档的索引目录和内容结构表现,对于一份比较完整的产品 PRD 来说,会有大量的信息层级和模块,如果缺乏这个目录,我们就很难从中快速翻到自己想要的模块里。

目录是一个很常见的东西,我也就不截图了。不过对于一份靠谱的 PRD 文档来说,目录应该是做成可以快速跳转到指定位置的格式的,类似线上文档工具自动生成的目录。

3. 版本概述

版本概述是对这次项目做一个整体性的概括,包括改版的原因、工期、环境、人力资源介绍等等,最重要的,是在这个模块罗列本次项目的实际需求项。

通过这种表格,可以帮助团队成员快速建立对本次项目更新内容的认知框架。

4. 产品结构

产品结构包含了页面层级结构、信息结构、功能结构等类型,通常由思维导图中的树状图表现。

页面层级结构图就我们正常访问的页面从属关系,也是最好理解的。

功能结构图则是不管页面怎么安排,就在 “范围层” 的角度描述产品包含的核心功能和下级功能。

信息结构图,则是在不同页面中包含的 “模块”、“字段” 有哪些,树状图的最底层将不再是页面单位,而是信息颗粒。

5. 功能说明

前面四条都是比较笼统的讲解整个应用的信息,而在功能说明中,才包含我们应该如何具体进行设计、开发的信息。

功能说明通常会将前面需求条目中单独罗列出来进行说明,这个说明是为了让看的人能看懂,所以没有任何限制,靠编写者自由发挥。

常见的功能说明中,除了文字描述外,还要搭配大量的图形和表格。例如应用原型进行注解、流程图、泳道图、关系图等等。


功能说明占据了整份 PRD 的绝大多数篇幅,也是指导我们具体工作的内容,看懂功能说明是每一个团队成员职责,包括设计师也是。

当然,不同产品经理的文档书写能力是不同的,要写一份大家都能看的懂的文档,是考验撰写者 “讲人话” 的能力的。如果出现了无法理解的地方,就一定要记得和相关编写者进行沟通。

设计师如何进行分析

有了一份 PRD,下一步,就是设计师进入分析的环节了。

常见的分享对设计师要掌握的需求分析能力有主次不分的问题,设计师的需求分析,不是抢产品经理饭碗,制定需求内容、划分需求等级、评价需求价值。

在一个成熟的团队中,PM 在制定 PRD 中必然也会处理这些工作,而设计师需要做的。是在需求评审、PRD 中,整理和设计有关的内容,并制定后续的工作内容。

PRD 并不是只写给设计师看的,更多是给前后端开发当开发依据的说明,必然有一部分需求点是和设计师没有关系的,比如 BUG 修复、算法推荐优化、统计埋点等。

我们要根据多方面获得的信息将涉及设计的需求整理出来,并罗列出一份明细,这份明细包含设计的页面、模块或者图标。

然后,再对每条需求标记上相关的数量、优先级、设计目标、时间要求、负责人等,作为一份设计项目清单,比如下图这样的表格。

一份清晰的设计项目清单,可以很好的帮助设计师团队规划工作安排,不至于整个过程手忙脚乱。

这个过程与其叫分析不如说是整理,而真正需要做专业分析的时候,是你发现了产品当前某些交互、体验中的问题可以改进,向产品经理提出建议。

或者,当你觉得某些产品需求不合理,影响产品的体验,那你就可以通过一些专业的分析来制作一份说服产品经理的报告,说服他们调整需求。

要牢记——决定需求制定的人是产品经理,而不是设计师。

今天分享写到这边,在后面我还会更新更多和分析有关的专业理论和技巧。

【责任编辑:未丽燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

云原生架构实践

云原生架构实践

新技术引领移动互联网进入急速赛道
共3章 | KaliArch

28人订阅学习

数据中心和VPDN网络建设案例

数据中心和VPDN网络建设案例

漫画+案例
共20章 | 捷哥CCIE

193人订阅学习

搭建数据中心实验Lab

搭建数据中心实验Lab

实验平台Datacenter
共5章 | ITGO(老曾)

119人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微