产品研发过程中UCD目标的制定与实现

摘 要:以用户为中心的设计(UCD, User-Centered Design)是保障产品具有较好用户体验(User Experience)的基本活动,其中可用性目标是有效衡量 UCD 活动最终效果的重要指标。本文将介绍一种可用性目标的制定过程,包括可用性目标维度及衡量指标,以及可用性目标与其他设计指标结合时其优先级的确定,可用性目标描述规范等。

关键字:以用户为中心;可用性目标;用户体验

作为一名研发咨询顾问,在为客户进行培训和咨询服务时通常遇到这样的问题:

1)究竟什么是UCD,产品的UCD包括哪些范围?

2)UCD的度量标准是怎样的?如果衡量UCD达成的目标?

3)如何收集用户对UCD的需求?

4)在开发团队中谁对UCD负责?

5)UCD的工作如何考核?

6)公司需要专门的UCD团队吗?

面对以上的问题,许多企业的研发管理者无从下手,很多产品管理人员对于UCD的设计还仅仅停留在模仿的层面,即抄袭竞争对手的UCD,或者拍脑袋,没有科学的流程制度和管理机制,以保证UCD在产品开发实现中的落地。我们先来看看UCD的定义:

UCD是User Centered Design的缩写, UCD是把易用性(Ease of use)设计到产品的用户整体体验(Total User Experience)的一个方法。它能够使团队(组织)开发出容易销售、容易安装、容易学习、容易使用、容易升级的产品。它需要多学科团队来设计用户看到、接触到的任何东西,并且在开发过程的各个阶段收集用户的输入和反馈。UCD是一种设计方法,它设计的是用户整体体验。目前国内大部分的产品创新型企业都设置了UCD团队和组织,如华为、阿里巴巴和腾讯等公司。尽管业界提出了一些可用性检查表等方式来帮助评估或测试的全面性和客观性,但不可避免对于UCD评估或测试往往存在主观性,评估或测试结果一方面容易引起开发人员的争议,另一面也经常因项目周期等因素而难以得到改进。其中最重要的原因就是开发前没有制定可衡量的、多方认同的可用性目标。

本文将介绍一种可用性目标制定方式,来帮助产品开发过程解决如下问题并从而提升 UCD 活动效果:

一为产品设计人员(包括交互设计人员、视觉设计人员和开发人员)提供具体的、清晰的可用性目标,使其设计有的放矢。

二是为可用性评估及测试人员提供测试的验收标准,使其在产品开发不同环节的评估及测试中有具体的衡量标准,也使得测试结果能得到广泛认同。

如何进行可用性目标制定?可用性目标有效制定无疑将为 UCD 活动提供有依据的衡量标准,从而提升 UCD 活动效果。可用性目标与产品开发过程之间的关系如下图:

如上图可见,可用性目标制定需要用到市场及技术分析结果、产品规划目标,如果是多代开发的产品,则其上代产品的市场反馈结果也可用于制定可用性目标。用于制定可用性目标的数据主要有:目标市场及竟品信息、目标用户及用户特征、产品特征、技术约束、用户反馈等。可用性目标一旦制定,将影响到产品规划、产品设计一直到上市等各个环节,一方面将为设计人员提供设计依据,另一方面将为评估及测试提供衡量标准。另外,可用性目标也可随着设计、开发和测试等过程推进中,不断优化。以下是制定可用性目标的三步法:

第一步:进行维度选择

如何进行维度选择?描述可用性的维度有多种方式,国外有些资料记载将有效性、效率和满意度作为可用性的基本维度,一些文献中将易学、易记、易用、容错和满意度作为可用性描述维度,而随着人们对情感的关注,还有研究者将情感的一些因素也作为可用性考虑因素之一。本文从介绍方便的角度,采用下表中的可用性维度案例子来介绍可用性的维度定义并进行简要说明。一般来说,产品在可用性方面应至少着重考虑这些维度中的一种,具体维度选择往往需要根据产品需求综合选择维度,比如娱乐类应用要着重考虑其吸引力,而学习类应用则应着重考虑其易学性,办公类则应更关注有效性和效率,等等。

第二步:进行可用性衡量指标定义和说明

什么是衡量指标?所有的目标最终是必须可以量化的,可用性目标也不例外,也需要相应的指标进行描述,把可用性目标分为定性目标和定量目标。本文根据可用性目标反映人和产品之间使用性能的固有特点,从表 3 中的时间、精确性或正确率、成功率和满意度等四个方面来描述可用性目标。

可用性的 5 个维度和以上 4 个衡量指标相结合,可以精确描述出无歧义的可用性目标;衡量某个可用性维度时可以是 4 个衡量指标的 1 个或多个。

也可以将多个维度和衡量指标结合起来,形成一个综合衡量的可用性目标,比如:新手用户在不需要帮助的情况下 5 分钟之内最多只出现 2 次错误就能成功地完成笔记本无线网络配置工作,且满意程度不低于 4 分。该目标就将有效性、效率、容错、易学和满意度等维度。综合为在时间、正确、成功和满意度等具体的具有可衡量标准的可用性目标。

具体实践中,还会存在量化的问题,比如为什么限定不能出现 2 次以上错误?这些量化的数据需要结合多种学科的研究结果,如心理学、社会学、人体工程学等等,有些数据是可以从这些学科总结的数据中直接提取,如一些人体尺寸方面的要求,或利用这些学科的方法通过实验获得,如通过心理学实验获得出错率和反应时间等;此外,还有些比较简要的方式就是直接分析竟品或类似产品,从中获得可以衡量的数据,比如发短信的操作效率方面,可以从业界操作步骤最少的手机中得到相应的可比较数据。这些数据经过积累之后,可逐步形成经验数据乃至公司同类产品的标准,为后续产品开发提供依据。

另外,这些衡量指标也需结合具体任务和目标用户来选取,如时间方面,新手用户和熟练用户应有所差别;而对于准确性要求高的任务如超市收银则需要时间和正确率等。

第三步:进行优先级设定

结合产品、用户、任务等产品使用背景信息之后,采用可用性描述维度和衡量指标,即

可形成一系列的可用性目标,但这些目标形成之后,需要结合产品目标、项目环境和任务特点等相关信息,确定这些目标的优先次序,也即必须给可用性目标分优先级。分优先级的基本思路为:

如果给某目标赋予高的优先级,必须考虑该目标是否对产品的成功最有帮助。

如果可能的话,低优先级目标也要识别出来并完成,但是必须在保证高优先级的目标得以实现的,而且这些低优先级目标也不会占用项目额外的时间和成本的前提下。

与通常产品其他目标类似,可将可用性目标分为三个级别:

— 一级目标:最高级别的可用性目标,严重影响产品的成功与否。比如:关键功能的图标能否被正确理解并与其他图标有效区分。

— 二级目标,对产品的成功影响较产品其他目标较为次要,尽可能争取资源来保障。比如:新手用户 1 分钟进入某功能界面(当产品主要目标是稳定性或其他要求时,就可以把该目标作为二级目标)。

— 三级目标,产品的成功不是可用性来决定或需要长期才能衡量出来的可用性目标。比如:产品的整体满意度目标。

设置可用性目标的优先级之前,可按作用将可用性目标分为三大类,可更好的设置产品可用性目标:

— 关键目标:产品可用性必须达到的最低限度的可接受水平,即无论什么情况下最起码要达到的可用性目标。通常为一级目标。

— 基准目标:分为两种,一种是在设计迭代评估中使用,用于确定何时停止迭代,特别是在资源紧张的情况下或可用性不是产品主要目标时,应根据实际情况设置的可用性目标:第二种为用于在资源紧张但可用性是影响产品成功与否的关键因素之一时,设置的产品最终能否上市的可用性目标。

— 理想目标:如果费用,时间,以及其他的日程冲突不在考虑范畴时,用于作为一个长期的目标,直到产品发布之后仍跟踪改进的可用性目标。

以上优先级关系可如下表所示:

三个步骤执行完成之后,UCD目标和度量的标准也就基本成型了。当然,除了一些基本的度量标准,对UCD设计人员的创新意识、对客户需求的敏感性也非常关键。

时间: 2024-08-03 02:46:47

产品研发过程中UCD目标的制定与实现的相关文章

精益之识别和消除研发过程中浪费的思路和模式

本文基于精益思想和精益软件开发,针对研发过程中的"浪费现象"进行深入分析.浪费分成存粹的浪费和必要的浪费,其中存粹的浪费需要消除,而必要的浪费可以进行压缩.结合日常研发过程,本文对如何识别这些浪费.如果消除存粹的浪费以及如何压缩必要的浪费进行剖析,并提供思路和模式. 一.理论基础 精益思想来自制造业,引入软件行业不过10年,目前很多理念还是停留在理论阶段,很难在实际研发过程中进行直接应用和推广.精益的很多思想个人认为是对软件行业有参考价值的,例如本文的主题"消除浪费"

产品研发管理(三):产品研发过程管理概述

概述 这是产品研发管理系列文章的第三篇:产品研发过程管理概述. 生产型企业通过企业研发生产过程,制造出产品,销售给客户,为其提供价值,从而赚取合理利润.软件企业作为生产型企业的一种,它区别于其他生产型企业的特点是它的产品是无形的. 除了传统的生产并将软件卖给客户的软件企业以外,现在出现很多运营型企业.比如:携程.淘宝等.他们不直接将软件卖给客户,而是使用软件为用户提供服务.这种企业里一般还是分为研发部门和运营部门.这种企业研发的产品的客户是自己的另外一个部门:运营部门. 研发生产过程的管理系统是

社交系统ThinkSNS+在研发过程中,如何做到 Laravel 配置可以网站后台配置

什么是ThinkSNS+ ThinkSNS(简称TS),一款全平台综合性社交系统,为国内外大中小企业和创业者提供社会化软件研发及技术解决方案. 本文分享下利用 Laravel 的 Bootstrapping 达到网站后台设置 laravel 配置. 需求场景 首先,ThinkSNS+ 作为一个用户可以使用的「社交系统」和开源网站程序一样拥有后台,有一些配置,Laravel 是要求写在 /config/*.php 的配置文件中的,例如 app.name.app.debug 等信息的配置,以及 Jo

如何用Bugzilla系统管理产品研发过中相关需求和bug

目 录 1.Bug处理流程及状态说明 2.bugs字段说明 3.查询报表的使用 4.bug系统与需求系统的整合 5.流程和用户权限 1. Bug处理流程及状态说明(1) BUG状态流程图 BUG的状态说明 bug的处理状态说明 BUG的状态和处理状态图表说明 2.bugs字段说明(1) 3.查询报表的使用(1) 4.bug系统与需求系统的整合(1) 以前我们的需求,是放在另一个单独Bugzilla系统上.在新系统上,需求和bug 进行了整合. 需求作为一个bug,提交到Bugzilla上.并通过

研发过程中需要进行的测试

1.接口单元+边界测试 使用Golang的Test单元测试方法,每个接口必须在Test目录下存在对应的单元测试文件,并进行自我测试,包括rpc层和web层,缺一不可. 在单元测试中,必须对于用户输入的参数全部认为可能非法,检查进行边界录入异常检查,并测试通过. 2.接口压力+疲劳测试 接口压力测试统一使用wrk进行测试,并需提供每个接口的压力测试报告,后面将根据实际情况,提供基准,低于基准的需优化至达标后方可通过. 疲劳测试必须达到12小时,并提供疲劳测试报告. 3.模块压力+疲劳测试 在一个业

android产品研发-->总结(持续更新中)

转载请标明出处:一片枫叶的专栏 最近的android产品研发系列主要讲解的是android产品研发过程中涉及到的技术,技巧,实践等.前面我们讲解了android源码系列的文章,源码系列的文章东西比较多比较复杂,并且一些东西还没有讲完,这里已经更新了30篇了,后续的东西一定会更新的.考虑一直讲源码系列可能看的比较累,这里就有了产品研发系列的文章.本个系列的文章主要是讲解android产品研发过程中一些需要注意的技术技巧与实践.其主要面对产品研发,对App稳定性,友好型,兼容性要求较高的App. 下

android产品研发(二十一)-->UI优化

转载请标明出处:一片枫叶的专栏 上一篇文章中我们讲解了android产品研发过程中的代码Review.通过代码Review能够提高产品质量,增强团队成员之间的沟通,提高开发效率,所以良好的产品开发迭代过程中,代码Review是一个必不可少的步骤.那么如何进行代码Review呢?我们主要讲解了团队成员之间的代码Review,代码lint检查,开发规范等方面的知识点,更多关于代码Review相关的知识可参考我的:android产品研发(二十)–>代码Review 本文我们将讲解一下android U

android产品研发(十)-->不使用静态变量保存数据

转载请标明出处:一片枫叶的专栏 上一篇文章中我们讲解了Android中的几种常见网络协议:xml,json,protobuf等,以及各自的优缺点,一般而言主要我们的App涉及到了网络传输都会有这方面的内容,具体可根据项目的需求确定各自的网络传输协议.这里可参考android产品研发(九)–>App网络传输协议 而本文讲解的其实并不是一个技术方面,而是一个android产品研发过程中的技巧:尽量不使用静态变量保存核心数据.这是为什么呢?这是因为android的进程并不是安全的,包括applicat

android产品研发(一)-->实用开发规范

从这篇文章开始我们暂停一下对android源码的分析,开始讲一下android产品研发中一些常用的技术,技巧,方法,实践等姿势.这里需要强调的是我们所讲解的这些东西可能对产品开发中比较常用的,因为对于项目开发中,可能更多的强调管理,进度方法的东西,对工程化的东西比较强调,而我们这里更多的是对产品技术方面的归纳总结. 而本文中选择将开发规范作为这个系列的第一篇文章,就是个人感觉产品研发过程中,开发规范真的很重要,很重要,非常重要(重要的事情说三遍),一个好的开发规范可以让团队中的人对他人的代码更熟