产品转型-简易PRD学习梳理
在产品经理工作过程中,原型设计必不可少,那么在设计产品原型的时候有什么技巧和方法论?本文系统梳理了相关PRD学习的知识,希望对你有所帮助。
最近为了获取面试机会,会被问到如何设计原型,有哪些方法论。因此系统整理下自己掌握的原型设计知识,欢迎各位大佬补充指正。
一、学习理解思维图
二、学习理解详细描述
2.1 PRD的目的还是为了详细阐述需求
所以我按需求的类型来阐述我对每类需求的PRD设计要求;在我的常用需求分类里有三种分类形式。
(1)按需求提出的形式
- 不完整的需求:需求提出方一般只提出部分概念,他也不知道要什么。所以需要产品经理有极强的业务支撑,进行需求完善并进行相应设计;PRD也需要注重完整:完整的业务方向、完整的流程图、完整的注释,从而诉请产品设计的概念。
- 缺乏用户参与的需求:用户提出需求后极少参与需求沟通甚至不参与,因此无法通过频繁交流获取需求的详细信息。此时产品经理需要寻求沟通,并极其慎重对待每一次需求沟通机会。PRD需要注重细节控制:清晰展现需求设计过程每个备受争议的细节,并提供建议性的方案描述(成本充裕情况下可以有多个),从而让用户在一次需求讨论中就可以确定想要的方案。
- 不切实际的用户需求:用户基于自己的最高期望提出需求,一些时候是不符合产品的设计方向;这种需求需要先思考,是否可以进行引导和降级,提供基于软件的方向和思路。PRD需要注重目标导向:深度理解殊途同归,在目标不变的情况下,进行产品方案设计,可以将不符合自己产品设计方向的通过外部对接或者制度协同的方式变相实现(可以通过成本导向阐述、也可以打感情牌阐述),最终完成客户的需求期望引导和实现。
- 变更频繁的用户需求:对待这类需求需要先理解需求变更频繁的原因,是业务形态多变还是初始需求覆盖面不广,需要通过详尽的用户调研并设想更多的场景用例来进行应对。PRD需要注重阶段管理:深刻理解用户业务,将用户变更的需求视为一个需求,作为需求实现的不同阶段;因此需要阐述不同阶段如何进行衔接、转变,需要做哪些预置动作。
- 不再被需要的需求:需求不再被需要,是业务暂停了还是时效过了?所以在需求设计过程中,需要充分注意需求的保值。PRD需要快速交付,保障需求的准确准时交付,来不及就直接靠嘴说。
(2)按需求设计的范围
- 业务需求:负责一个业务的重构,涉及多个业务页面或者流程更改,此类需求涉及的范围更多,需要关注页面与页面的交互。PRD一般注明业务目标,业务流程图,各页面结构功能模块,按页面交互顺序排列。
- 功能需求:一个业务页面下某个功能的补充,部分业务功能也会涉及和其他页面的交互。PRD一般注明功能的位置,与这个业务或其他业务页面的关联逻辑。
- 优化需求:某个业务或者某个功能进行逻辑或者细节优化,也有bug的修复优化。PRD一般需要列举优化的前后对比,bug导致的问题和修复的效果,做好优化目标描述。
(3)按需求设计的用途
产品性需求:基于产品业务功能需求的改进,这也是产品经理一般负责的需求。
约束性需求:基于页面展示或者其他考量,限制页面展示的数据条数或者模块。PRD上完成注释。
技术性需求:产品会基于业务扩展性提出数据调用的方式和实现方式,比如某个数据写死,某个数据需要实时从哪几个表读取。同时技术部门也会考量提出技术性需求补充。
2.2 PRD原型我常用的几个工具,AXURE、WPS、PS
(1)AXURE一般都是有多个页面需要交互的时候会用下,在进行常规产品设计时可以预置自己的设计模板,每次在基础上进行设计,事半功倍。
(2)WPS画流程图,画交互图,我用的都挺顺手的
(3)PS基本很少用,高保真的交给UI吧,希望大家都有UI。
今天就写到这了,希望各位大神们可以评论指正不足的地方,万分感谢。
本文由 @蓝白羽0414 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
我很赞成PRD是为了详细阐述需求这个观点,看了很多PRD文档,感觉他们写的就像竞品分析一样,PRD不应该就是阐述需求,做出解决需求的方案的吗
PRD就是吧需求功能交互都写清楚交给开发,让他们看的明白。