APP研发设计流程，看这个就够了！

I.研发过程

总体观点

产品开发过程分为四个步骤：产品定义— —交互设计— —发展 - mdash; —测试。这四个步骤也对应于研发中的四个角色：产品经理— —设计师— —开发工程师— —测试工程师。

产品定义阶段的目标是识别用户场景并定义产品的功能和范围。

设计人员需要与这些用户场景和功能区域进行交互。

然后，开发工程师将根据产品经理和设计人员的计划编写代码，将解决方案实施为可用产品。

然后，测试工程师进行产品测试，以确保产品符合产品经理和设计人员的要求。

分步：

首先，产品定义

最初根据用户需求定义产品功能

1.关于需求

这里要讨论的主要内容是用户需求和产品需求。

1.1用户要求和产品要求

必须澄清的第一件事是用户需求与产品要求不同。

用户要求，简单来说，用户希望使用某种产品来实现并满足某些需求。如安全，娱乐，沟通，交友等。用户要求是用户对某类产品真实需求的回应。

产品需求是满足用户需求的产品或服务的集合。换句话说，用户要求并未完全传递给产品要求。对产品需求的访问不仅仅是用户需求。

1.2获得产品要求的方法

（1）用户要求：用户要求是产品需求的核心来源。但并非所有用户需求都可以转化为产品要求。用户要求需要进行子可行性和必要性验证才能转化为产品要求。

（2）相关利益合作伙伴：开发商，咨询机构，制造商等。他们对市场的研究和分析以及对运营中积累的产品的需求是设计和分析产品需求的良好参考。

（3）竞争产品分析：对竞争对手的主要产品进行基准测试，分析产品成败的关键和发展趋势，了解市场对同类产品的反馈。

（4）基准市场：基准市场是国内外同类产品成功运作的热门行业。分析了知名企业在基准市场中运作的同类产品的功能。您可以了解此类产品的国际和国内先进实践。

（5）内部产品研讨会，员工经验和内部专家评估。

1.3如何提取和挖掘用户需求

了解用户需求的有效方法是用户研究，这是用户中心设计过程的第一步。主要研究方法有：用户访谈，用户观察，问卷调查，焦点小组，眼球运动实验等。处理和分析由此获得的信息和数据。从中提取初步用户需求文档。

显然这些需求还不够。这些要求只是用户对现有需求的反馈。此外，设计人员可以使用在用户研究阶段生成的角色（个人肖像）工具，并将其置于特定场景中，以探索潜在的用户需求。

（1）通过用户研究直接访问

在用户研究阶段可能会出现各种各样的问卷和数据清单。收集这些数据并不困难，您所要做的就是耐心和时间。

为了更好，更好地获取初始用户的需求，用户研究人员需要确定在问卷设计，用户访谈，焦点小组等的问卷设计中为要求设置了哪些问题或选项，可以组织后续阶段。 。

（2）在场景中使用角色人物挖掘。

角色的来源，概念和功能：角色不是真实的人，而是基于我们观察的真实人的行为和动机，并在人种测量调查中代表整个设计过程中的真实人。基于收集的世纪用户行为数据的综合模型。在研究阶段，我们观察用户的行为模式，在建模阶段对其进行建模，最后生成角色。

换句话说，角色来自用户研究。通过用户研究，研究人员通过某些标准细分了大量用户，以获得不同的用户群。

评估和调整分段的用户组以确定分段角色组。角色组有一定的触觉。例如，每个角色组被赋予独特的角色属性，例如代表性照片，姓名，职业，个性等，从而形成不同的角色。

角色通常由其重要性和特定定义来定义：主要字符，次要字符，不重要字符和排除字符。

通过创建角色，用户研究结果以简单，直观但非常有效的方式为设计团队成员（决策者，产品经理，交互设计师，视觉设计师）等形成。一致的理解。

场景的概念和作用：用户角色是死的，静态的东西，只有把它放到某个场景中，才会活着，并与产品互动。

场景是一种“理想化”场景，其中角色与产品交互。它讲述了每个角色如何与产品互动的故事。每个角色将对应于场景，或甚至更多，以便覆盖用户使用场景的各种情况。

使用字符字符挖掘场景中的需求:为每个角色设计合理的场景，然后集体讨论相关人员（不仅仅是交互和视觉设计师）。在这个阶段，每个人都必须有一种深切的同理心，并且在每个联合点，可以想到的可能性被完全解释和记录。此时的气氛也是不受约束和不加批判的。

在这里，以时间轴为“生命中的一天”为例，利用人物角色为移动浏览器产品进行需求挖掘。例如：

早上起床，起床：查看天气预报，日历中可能涉及的功能：天气查询，日历。

当你吃早餐时：你可以阅读新闻，电子邮件和你自己的博客。这将针对新闻，微博和电子邮件。

在途中：早上办公室：中午午餐：下午办公室：上班前：上班途中：在餐厅：在家里：在床上，等等，探索可能使用的功能。

每个角色按一个或多个场景分类，列出所涉及的功能，并根据每个角色在每个角色中的重要性定义每个角色的权重，并创建一个excel文件。

1.4用户需求增加到产品需求，导致产品功能要求列表

上述获得的用户需求不能直接转移到产品需求上，经过一定的评估和选择后，有必要评估产品的可行性和必要性。

可行性：当前的技术和企业资源是否有能力，是否有可能开发出能够在当前条件下和日程安排等现实条件下完全满足用户需求的产品。

必要性：是否需要满足用户需求，满足这些需求的公司成本，以及是否有足够的商业利益来支持市场运作。

经过上述验证，结合相关利益合作伙伴，竞争产品分析，基准市场和内部研讨会获得的用户需求，获得完整的用户需求清单。

所有产品要求都转化为产品功能。工作人员可以将在先前用户研究阶段收集的功能需求合并到需求列表中，这些需求稍后由场景中的任务角色挖掘。它们也对应于自然界中的不同角色。

这里，角色的权重（可以根据主要角色，次要角色或不重要角色分为3分制或5分制）和相应任务的权重是总重要性功能。

二，交互设计过程

（1）三阶段互动设计

素描——低保真原型——高保真原型

草图：只需使用纸和笔手绘这个界面草图，这样您就可以与产品经理和其他同事快速讨论，使这个想法具体化。

资料来源：苏帅的博客

我们看到的图片实际上是非常规则的，它已经是一个完整的产品架构图。但是我们工作中的文字可能只是方便，并且画了一些笔画。没关系。草图强调它可以快速体现想法，然后与其他同事讨论。

低保真原型：它基于草图，通过计算机的帮助，界面由简单的线框和文本绘制。当然，低保真原型不能简单地查看，而是通过一些简单的交互。在白话中，它是动态的，您可以简单地体验这种设计并尽可能地发现一些问题。去做一些修改。

资料来源：网易UEDC

高保真原型：它是基于这种线框的视觉设计，视觉设计被制作成可以交互的原型。此效果可能与上一个产品相当，您甚至可以在手机上进行模拟。

高保真原型通常用于开发和测试。开发人员将根据高保真原型进行开发。测试人员将测试开发人员基于高保真原型提供的产品。

来源：车站冷光玻璃盏

因此，您可以看到，在设计过程中，设计人员首先必须通过草图与产品经理和其他同事讨论，以确定产品的设计方向。然后做一个低保真原型来完善设计。高保真原型将在稍后生产，交付给开发和测试人员。

因此，设计师的整个设计工作是与其他角色沟通的过程。我们刚刚提到的设计的三个步骤也是围绕通信建立的。

（2）为什么要绘制原型

降低修改成本并促进沟通讨论

绘制原型的最大目的是降低后期修改的成本，使用低成本的原型来体验讨论，修改，尽量避免开发再修改。其次，交互式原型更便于与他人沟通和讨论。所谓的画面胜过千言万语。所以图片比文字要好得多。然后，如果它是原型，或者可以交互的原型，它的通信效果比图片好得多。

因此，应该强调原型只是一种设计工具，而设计理念才是真正的核心。因此，在学习好工具的基础上，你应该花更多的时间在思想的设计上。

三，发展

下一步是程序员编写程序的三个步骤。 （关于开发，这里不详述）

1，app软件开发大功能模块代码编写

2，app软件开发可能是接口模块的准备

3.连接了大致的界面和功能后，将会出现应用软件开发的近似演示

4，演示自己尝试和体验几次，根据情况修改

5，没有大错误后，0.9版本可以尝试找到beta用户

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

第四，测试

测试工程师，一般从用户的角度，测试开发工程师的工作是否符合产品的需求，或者用户的体检是否良好？不要求太专业的知识，但要小心并对产品敏感。因此，有很多人不是计算机专业人员，他们仍然可以成为测试工程师，因为我们的产品需要不同的人。

还有更专业的白盒或灰盒测试，这要求测试人员具备一定的编程技巧，但要求不是太高，不需要语言的高级编程，普通的应用程序或代码段都可以理解。问题应该是全面，细致和有原则的。它不能跟着开发和产品。这是测试人员的要求。

（1）软件测试的测试过程是：

制定测试计划——编辑测试用例——执行测试用例——找到并提交BUG——开发组修复BUG——返回更正的BUG——修复已完成的BUG将状态设置为已关闭，并且重新激活未正确更正的错误。

（2）标准化测试过程

需求分析：需求分析由产品人员开发。他们并没有做一个简单的文档，而是改进每个函数的细节，每个按钮的位置，以及为更大或更复杂的函数建模。

需求评审：这将被称为所有参与项目的人员，开发人员，测试人员，QA人员。测试者询问要求，开发人员考虑功能实现的解决方案和可行性，当然还涉及开发责任。测试人员主要关注理解需求，以便他们可以根据需要编写用例。质量保证人员是最终验证软件质量的人员，因此他们还需要了解要求

开发人员编写计划表：根据需求功能点计划开发人员要求。然后将计划转发给测试人员。

测试计划安排：根据开发计划，测试人员对特定测试时间，即开发功能完成后的时间进行多轮测试。然后，将项目开发和测试计划发送给部门负责人和项目所涉及的所有人员。

编写测试用例：根据详细的需求分级开始编写用例。

用例审查：在用例审查之间，用例通过电子邮件发送给相关人员，以便他们事先知道用例的哪些功能得到验证以及验证的细节。

然后，测试人员组进行用例审查。开发人员不同意用例和实际功能。产品人员将通过用例等掌握功能的具体实现。

提交基线：一旦开发人员完成了所有功能，他们就会对自己的功能进行自我测试。自检完成后，将测试仪提交到基线。

（3）具体测试过程：

开发人员测量基础测试线的功能，通过缺陷管理工具识别问题，开发人员修复问题，然后准备第二轮。

在测试者完成第一轮测试后，他或她需要编写测试结论并将其发送给相关人员。然后测试基线后的第二轮，第二轮将重点关注第一轮中发现的问题。

测试通过：经过两到三轮或四轮测试，直到没有发现新问题，或暂时无法解决，或不紧急。它可以通过上级的确认传递。编写测试报告和验收计划。

验收计划由QA验证。在当前公司的流程中，测试与QA分开。测试人员关注功能是否可以正常运行。质量保证关注整个过程的质量和最终用户的质量。有些公司不区分质量保证和测试，但这需要更多的测试。除了关心功能外，他们还需要关心整体流程和质量。

过程分析：该过程是标准化的，测试真正集成到整个过程中，它也起着非常重要的作用，也有效地保证了软件产品的整体质量。

那么这个过程是完美的吗？不，这个项目过程太难以提升各种文件。让我们看一下测试工作，测试计划，测试用例，测试结论，测试报告，验收计划和问题提交跟踪。事实上，我们真正用于测试的时间非常短。在一周内，可能只有一天或更短的时间进行测试。测试人员只会在测试时显示他的价值。大部分工作都没有反映他的价值。

当然，我会省略与主要测试过程无关的事情。在真正的测试工作中有很多琐碎的事情。

（4）敏捷测试过程

上面提到的第一个过程，或者第二个过程是瀑布。严格来说，第一种简单不能称为瀑布。对于为期三个月的项目，该产品分析了开发的要求。然后产品很好;在开发和开发完成后，进行测试，然后开发人员不忙。

测试完成后上线。然后在产品分析阶段，开发和测试都可以（这里只针对一个项目）。

在开发阶段，产品和测试基本没问题。同样在测试阶段，产品和开发无关。

敏捷测试的一个核心是迭代，在每个时间点，所有项目人员都有事情可做。

1.以下是我理解的敏捷测试的流程图：

第一阶段：通过上述流程图，对于一个月的需求分析，在敏捷中，可以在三天或五天内确定。这种需求将非常模糊，但总体框架还可以。该产品确认其中一个模块的功能，开发人员开始编码确认功能，开发人员的功能在编写开发人员的过程中被分解，因为很难根据具体用例编写模糊要求，因此只能尽可能地解决功能。进行详细分析并标记需要验证的内容。

第二阶段：开发完成后，将其交给测试人员进行测试，开发人员继续开发新功能。那么测试人员发现了什么？怎么办？将从开发团队中抽取一个人来解决测试中发现的问题。但是由于测试，开发进度并没有停止。

过程分析：在此过程中文档被削弱，强调个人的沟通。通过这种迭代方法，这个为期三个月的项目可以在两个月和两个半月内完成。

但这个过程并不完美。在需求分析阶段添加函数是错误的，因为它是一个迭代和渐进的过程。它一直只会出错。

2.处理测试题

上图更清楚地显示了问题的过程。

第一个面板是开发人员尚未实现的功能。第二个面板是开发完成功能。测试人员对其进行测试，发现如果失败，它将被放回未开发的面板中，测试将被放入第一个三个面板中。

文：第六夫人来源：简报