标签：roc idg 就是 文档 快速迭代 交互 bsp 完成 计数
从2017年起开始接触产品设计这一领域，也陆续兼职了公司几个项目中的产品经理职责（主职位是技术架构），总结一下在产品设计过程中的一些细节吧。
首先，什么样的产品原型算得上一个好的产品原型呢？可能很多人会从高保真程度，交互还原，文档注释等方面给出不同的评价标准，但是我想说的是，必须先明确产品原型面向的是哪类人群，然后针对性的满足产品原型阅读者的需求，这是判断产品原型好坏的根本标准。
把所有查看你的产品原型的人看作为你的用户，分析用户需求。 这里以我自己的经历举例：
| 原型阅读者 | 需求是什么 | 怎么实现 |
|---|---|---|
| 老板/客户/需求方 |
实际中我的第一用户是我的老板，可视作产品需求来源，最终的决策者；
希望看到一个产品原型完整地将他对于产品的想法以可视化的形式呈现出来，并在此过程中体验产品效果，验证想法，完善细节，最终达到一个确定的”产品雏形“ |
形成整体的信息架构图、分层业务逻辑图，此用来梳理产品的核心逻辑
形成初步的产品交互原型，包括涉及到的终端，核心的功能操作，让产品想法初步变为一个可操作，可讨论，视觉化的体验 |
| UI设计师/交互设计师 |
根据原型去设计视觉，交互体验 |
走到这一步说明产品经过了第一阶段的初步确认，起码达到了第一个版本。
针对设计师用户，需要定义出整个设计规范，设计风格，以及交互要求。视自身的axure或者其他原型工具的掌握水平，可做高保真的交互原型，也可以将要求以文本或者参考效果的形式表达。
|
| 技术工程师 | 根据原型设计数据库，技术架构，功能实现 |
这里是很多非技术型的产品经理弄不清楚边界的地方。
技术人员更容易接收”确定的“，”完整逻辑覆盖“的需求。怎么说呢？每种业务可能出现的情况，产品设计要有对应的解决方案，大到一个完整处理流程，小到一个错误提示，都需要你”想到“
如果作为产品经理，不提前设计好这些规则，那么就提前健健身吧 哈哈... |
传统软件工程中的需求规格说明书，概要设计，详细设计等等一系列文档，好确实是好，但是有点重，放在如今的互联网产品设计中跟不上快速迭代的脚步。
我个人比较喜欢将需求文档和产品原型进行一个整合，所以我的产品原型一般都是这样的结构：（以一个租房平台产品为例）
主页会加上产品的需求描述，阶段性目标
?
业务流程里会定义核心产品流程，整体解决方案的关系图
?
交互原型最好有一个目录，这样多个终端的原型可以聚合到一个产品原型中
?
具体页面交互，列清楚每个字段的规则，用法，业务逻辑，以及设计要求。
?
原型可以高保真，也可以框图化，其实只要把需求表达清楚，让后续负责技术，负责视觉的同事能够接收到该接收的信息
?
?
做完产品原型，你的产品经理的第一个阶段性工作就算完成了，如果说需求方、设计师、工程师，这些是你的产品原型用户的话，接下来你的大部分工作内容就是售后了！
涉及到产品设计细节、交互细节、业务逻辑，你需要经常去了解下你的用户把你的原型用的怎么样了！有没有什么疑惑，有没有细节是漏掉了的，进度怎样了？很多时候，产品经理和项目经理甚至有一些职能重合，产品经理需要整体把控产品的推进，不是说做完原型就万事大吉了的。基本上只要和这个产品相关的事宜，你都要参与其中，起码都要了解。
产品上线后，就是进入到产品的运营+迭代的过程了，需要根据数据，市场反馈来做产品相关的调整啦。需要和很多部门进行协作，比如业务部，推广部，技术部等等。基本上就是一个老母亲的角色。成为一名好的产品经理是非常难的，对人的综合素质非常高，而成为一名一般般，做产品过程等于斯比过程的产品经理呢，倒是轻而易举的。想到这里才体会到”人人都是产品经理“的含义啊！
标签：roc idg 就是 文档 快速迭代 交互 bsp 完成 计数
原文地址：https://www.cnblogs.com/andmobi/p/11828655.html
