【giszz笔记】产品设计标准流程【4】

（续上回）

我们继续把扩展考虑UX环节的产品打造标准流程，来进行梳理。

一千个人心中有一千个哈姆雷特，本文将日常大家耳熟能详，但是又未必人人心中成体系的产品打造标准流程，进行总结。

考虑了两种项目，一是外包，即存在一个外部的出资人，核心要达成出资人的需求和意志。二是互联网产品，即重要干系人为内部出资人，核心要达成产品的成功和公司的战略目标。

三、产品功能分析

主要参与角色是PM-产品经理；

主要的标准成果物是《产品需求文档》即PRD。

产品需求文档是对产品的需求分析后，以设计语言进行描述，将作为开发阶段的主要输入物之一。

如果是通用型产品，PRD要遵循BRD，借鉴MRD。在这类项目中，PRD在产品项目中是一个承上启下的作用，对上是基于BRD、MRD内容的深化和落地，对下是要把内容设计语言化和技术化，向研发人员说明产品的功能特性和性能指标。

在这里，我们抛开市场元素，只从产品本身的功能特性来看，我们约束PRD要体现以下的一些内容：

详细我同步传的PRD模板和BRD模板。

PRD模板下载

BRD模板下载

PRD指产品需求文档（Product Requirements Document），其核心要素应该包括以下内容：

1. 产品的目的和背景：阐述产品的设计初衷和市场需求。

2. 用户人群和市场情况：描述产品的目标用户和市场规模。

3. 功能需求：明确产品的功能需求，包括基本功能、可选功能、操作流程等。

4. 界面设计：规划产品的界面设计和用户交互方式。

5. 性能需求：阐述产品的性能指标，如响应时间、可靠性等。

6. 安全性和隐私：明确产品在安全和隐私方面的需求和要求。

7. 国际化和本地化：阐述产品的国际化和本地化需求，包括语言、时区、货币等。

8. 支持和维护：说明产品的支持和维护需求，包括软件更新、技术支持等。

9. 项目计划和进度：规划产品的开发计划和进度，并制定相应的里程碑。

10. 风险和约束条件：明确产品开发过程中可能遇到的风险和约束条件，为制定风险应对策略提供依据。

11. 成本预算：制定产品开发的成本预算和资源投入，为项目管理提供参考。

我个人一般会要求比较重要的流程要有流程图，泳道图等，比较重要的界面，要有高保真的原型图。

四、总体架构设计

这个步骤包括了信息架构设计、技术架构设计等，可以体现一套完整的解决方案。在实际项目中，我个人习惯是把本部分和PRD同步来进行。毕竟技术总监、架构师不能让他们闲着吧！

本部分成果物是《信息架构设计说明书》，或者《总体架构设计》文档。

这里说明一下，本系列文章的主题，是“产品设计”标准流程，包括一部分的前端工作量，但是后端开发的接口设计、数据库设计、相关评审，迭代的过程，不做重点的讨论。

实际上，在本部门，是技术人员充分的参与到产品设计的环节中，提供产品成功的必要保障，避免前后脱节的情况出现，比如产品设计完工后，在技术实现、部署和上线时，发现严重的技术漏洞、成本超预算或者其他设计过程中未考虑到的问题。

内容一般涵盖：

1.信息架构策略和蓝图设计：

（1）确定系统的需求和功能，理解业务场景，确定系统的使用场景和业务流程，讨论系统的可用性、可靠性等方面的需求。

（2）绘制产品方案的全景图，必要的时候，对核心的流程和场景进行细化，绘制时序图、活动图，确定状态的变化，从技术角度对产品的功能需求进行映射，便于下一步的原型设计和交互设计，能够更加符合产品的目标。

关于相关的图表，请参考我的文章：不会画这10张图，还好意思说自己会管理项目？-CSDN博客

附：信息架构设计中的内容映射（content mapping）指的是将用户需求和任务与网站或应用程序中的内容进行关联和匹配的过程。它能够帮助设计师将用户需求和任务与网站或应用程序中的内容和功能关联起来，并使之更易于访问和使用。通过内容映射，设计师可以更好地了解用户的需求和目标，并为其提供更好的体验。此外，内容映射还可以帮助设计师更好地组织和管理内容，使其更加易用、易搜索和易理解。

2.技术架构设计：

（1）设计系统的整体框架和模块，确定系统的技术架构、数据结构、算法、安全、性能等方面的设计，选择合适的开发工具、开发平台和数据库等。

（2）考虑产品需求实现的可行性、架构选定的合理性。

3.初步的接口规划：

设计模块间的接口，包括API接口、消息接口、数据库接口等，确保不同模块之间能够协同工作并保持数据的一致性。

注意这里不要求对全部的接口进行一次性的设计完成，因为后续的交互设计尚未开始。因此用接口规划来代替设计。

这里重要的是，要做好一些接口、模块配合的约定，这将直接影响后续的人员分工、工期把控等工作。

4.系统集成设计：

将不同模块和组件集成到系统中，测试系统的整体功能和性能，处理模块间的兼容性问题。

对于复杂的系统，可能需要集成模式。比较典型的是涉及物联网、互联网的集成，但是，即使普通的产品，也有开发小组的分工。比如电商平台，可以按业务划分，例如主数据、订单、财务等。如果采用云原生的微服务架构，系统集成实际不会作为一个独立任务来考虑。

5.部署和维护规划：

将系统部署到目标环境中，例如云服务器、本地服务器，进行调试和优化，确保系统的稳定性和可靠性，同时，需要定期更新系统和修复漏洞。

在一些集团模式下，可能有传统业务中台的复用，例如SAP独立部署在某个特定的服务器环境等。这里需要考虑是私有云、公有云，还是混合云的部署方式，是否要拉专线。现在很多产品，都会使用短视频的模块，这里大部分企业都是用的云计算的能力。产品在设计的时候，不会考虑短视频的存储、流量、视频压缩、优化等问题，但是作为技术VP，技术总监来说，要提前规划。绝对不能等到产品多设计好了，再参与进来，造成不可避免的损失。

（未完待续，明天我们来数量原型制作和组织评审的相关工作流程、注意事项。）