Lous Blog

APP通用设计流程

[TOC]

设计流程

产品的研发流程分为四个步骤:

  1. 产品定义
  2. 交互设计
  3. 开发
  4. 测试

这四个步骤也分别对应研发中的四个角色:

  1. 产品经理
  2. 设计师
  3. 开发工程师
  4. 测试工程师

产品定义

用户需求和产品需求

首先必须要搞清的是用户需求不等同于产品需求。

用户需求,简单来说是用户希望同构使用某一款产品来实现和满足某种需要。如安全、娱乐、沟通、交友等。用户需求是用户对某类产品真实需要的反应。

而产品需求,是某一类产品或服务能够满足用户需要的集合。也就是说,用户需求并不完全传递到产品需求当中去。而产品需求的获取渠道也不仅仅是用户需求。

获取产品需求的方式

用户需求

用户需求是产品需求的核心来源。但并不是所有的用户需求都能转化为产品需求。用户需求需要子可行性和必要性验证上,才可以转化为产品需求。

相关利益合作伙伴

开发商、咨询机构、制造商等等。他们通过对市场的研究分析和对运营所积累的产品需求,是设计分析产品需求很好的参考。

竞品分析

对竞争对手主要产品进行对标研究,分析其产品的成败关键和发展趋势,了解市场对类似产品的反馈。

标杆市场

标杆市场是国内外在同类产品上运营比较成功的热门行业,通过对标杆市场中知名企业所运营的相近产品的功能进行剖析。可以了解国际与国内在该类产品上的先进做法。

内部产品研讨

项目组内共同研讨

用户需求的提取与挖掘的方式

了解用户需求的有效方式是用户研究,这是用户中心设计流程的第一步。其主要研究方式是:用户访谈、用户观察、问卷调研、焦点小组、眼动实验等等。并对由此得到的信息与数据进行处理和分析。从中提取制作出初步的用户需求文档。

显然这些需求是不够的。这些需求仅仅是用户在现有需求上的反馈。此外,设计师可以利用在用户研究阶段所生成的人物角色(人物画像)这个工具,并放置到具体场景中,从而挖掘用户可能的潜在需求。

通过用户研究直接获取

用户研究阶段可能会出现各式各样的问卷及数据列表。这些数据的收集活动并不难,所需要付出的只是耐心和时间。

为了更多更好的获取初步用户的需求,用户研究员需要在问卷调查的问卷设计 、用户访谈、焦点小组等的脚本设计中,明确哪些问题或者选项是为需求而设置的,以便后续阶段的整理。

在场景中运用人物角色进行挖掘。

人物角色的来源、概念及功能:人物角色不是真实的人,但它是基于我们观察到的那些真实的人的行为和动机,并且在整个设计过程中代表真实的人,是在人种学调查收集到的世纪用户行为数据的基础上形成的综合模型。在研究阶段我们观察用户的行为模式,在建模阶段将其模式化,最后生成人物角色。

也就是说人物角色源自于用户研究。研究人员通过用户研究,通过一定的标准将众多的用户进行细分,从而得到不同的细分用户群组。

细分的用户群组经过一定的评估、调整,从而确定细分角色群组。角色群组经过一定的润色。诸如为每个角色群组赋予具有代表性的照片、名称、职业、性格等鲜明的人物属性,从而形成不同的人物角色。

人物角色通常因其重要程度及特定定义为:首要人物角色、次要人物角色、不重要的人物角色、排斥的人物角色。

通过建立人物角色,从而将用户研究结果以一种简单直观但又非常有效的方式使设计团队成员(决策人员、产品经理、交互设计师、视觉设计师)等对大家所面对的客户群形成一致的了解。

场景的概念与作用:用户角色是死的,静态的东西,只有将其放到一定的场景中去,才会鲜活起来,与产品产生交互。

场景是人物角色与产品进行交互的“理想化”情景。它讲述的是每个人物角色如何与产品进行交互的故事。每个人物角色都将对应一个场景,甚至更多,以求覆盖用户使用场景的各种情形。

在场景中使用人物角色进行需求的挖掘:针对每个人物角色,设计合理的场景,然后集合相关的工作人员(不仅仅是交互和视觉设计师)一起进行头脑风暴。再此阶段每个人要有深度的同理心,并在每个关节点将所能想到的可能性完全说出来,记录下来,此时的气氛也是不加约束和不带批判的。

用户需求提升为产品需求,由此得出产品功能需求列表

以上得出的用户需求,并不能直接转入产品需求,需要经过一定的评估和帅选考察其可行性和必要性。

可行性

目前的技术和企业资源是否有能力,是否能在现行的情况下,与进度时间表等现实条件下开发出完全满足用户需求的产品。

必要性

用户的这些需求是否有需要满足,满足这些需求企业需要付出的代价,以及是否有足够的企业效益来支撑市场的运营。

需求列表

经过上述验证,并结合前面所叙述的相关利益合作伙伴、竞品分析、标杆市场及企业内部研讨会等所得到的用户需求,从而得到完整的用户需求列表。

在此所有的产品需求都转化为产品功能。工作人员可以将之前用户研究阶段收集的功能需求合并到后来利用任务角色在场景下挖掘的需求列表中。他们本质上也相应对应着不同的人物角色。

在这里,角色的权重(可以根据首要人物角色、次要人物角色、不重要人物角色等分成3点量表或者5点量表)与对应的任务的权重的乘积,就是功能总的重要程度。

交互设计流程

草图——低保真原型——高保真原型

草图

就是使用纸和笔去手绘这个界面草图,以便快速的和产品经理以及其他同事进行讨论,在进行想法具体化。

低保真原型图

就是在草图的基础上,通过计算机的帮助,由简单的线框和文字去绘制这个界面。当然,低保真原型不能只是简单的看,还要进行一些简单的交互操作。用白话来讲就是动态,可以简单地进行体验一下这个设计,尽可能的发现一些问题。去进行一定的修改。

高保真原型图

就是先在这个线框图的基础上进行视觉设计,在将这个视觉设计稿呢制作成可进行交互操作的原型。这个效果很可能都能和最后的那个产品相差无几,甚至你可以在你的手机上进行模拟的操作。

高保真原型呢一般用于交付给开发与测试那边。开发人员将按照高保真原型进行开发。测试人员将以高保真原型为基准,对开发人员交付的产品进行测试。

开发

接下来就到了程序员编写程序的三个步骤了。(关于开发,在这里不做详述)

功能模块编写

界面模块编写

Demo成型

demo自己试用和体验几遍后,根据情况修改

尝试寻找beta用户

根据测试用户的反馈,重复 前三个步骤

测试

测试工程师,一般就是从用户角度出发,检测开发工程师做的东西是不是符合产品的需求,或是用户体检好不好?不要求有太专业的知识,但是要细心,对产品敏感。所以有很多不是计算机专业的人员照样可以做测试工程师,因为我们的产品需要不同的人来说嘛。

也有比较专业的白盒或是灰盒测试,这就要求测试人员会些儿编程技术了,但是要求不太高,不必会某种语言的高级编程,普通应用或是代码段能看懂就行。问题要考虑全面,细致,有原则,不能跟着开发和产品走,这是测试人员的要求。

软件测试的测试流程有:

  1. 制定测试计划
  2. 编辑测试用例
  3. 执行测试用例
  4. 发现并提交BUG
  5. 开发组修正BUG
  6. 对已修正BUG进行返测
  7. 修正完成的BUG将状态置为已关闭,未正确修正的BUG重新激活.

规范的测试流程

需求分析

需求分析由产品人员制定,他们要做的不是一份简单的文档,而是细化每一个功能的细节,每一个按钮的位置,对于稍大或复杂一点的需求都进行建模。

需求评审

这里会叫上所有参与项目人员进行,开发人员、测试人员、QA人员。测试人员提出需求,开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问,以便才能根据需求写用例。QA人员是最终对软件质量进行验证的人,所以也需求了解需求

开发人员编写排期

开发人员需求根据需求功能点进行排期。然后将开计划转交给测试人员。

测试计划排期

测试人员根据开发计划,对测试具体测试时间,也就是开发功能完成后的时间,进行几轮测试等。然后,把项目的开发与测试计划发送给各部门负责人及参与项目的所有人员。

编写测试用例

根据详细的需求分档,开始进行用例的编写。

用例评审

在用例进行评审之间,先以邮件形式将用例发送给相关人员,以便他们事先了解用例对哪些功能进行验证以及验证的细节。

然后,测试人员组进行用例评审,开发人员对用例与实际功能不符合有哪些,产品人员对会通过用例对功能的具体实现进行把握等等。

提交基线

开发人员完成所有功能后,会对自己的功能进行一个自测。自测完成后提交测试人员进行基线。

参考