惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Vercel News
Vercel News
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
雷峰网
雷峰网
有赞技术团队
有赞技术团队
罗磊的独立博客
博客园 - 叶小钗
Jina AI
Jina AI
博客园 - 司徒正美
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
T
Tailwind CSS Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
人人都是产品经理
人人都是产品经理
Apple Machine Learning Research
Apple Machine Learning Research
阮一峰的网络日志
阮一峰的网络日志
Microsoft Security Blog
Microsoft Security Blog
大猫的无限游戏
大猫的无限游戏
量子位
MyScale Blog
MyScale Blog
V
Visual Studio Blog
博客园 - 聂微东
The Cloudflare Blog
Engineering at Meta
Engineering at Meta
小众软件
小众软件
宝玉的分享
宝玉的分享

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
产品转型-简易PRD学习梳理
岁末凌蓝 · 2023-11-09 · via 人人都是产品经理

在产品经理工作过程中,原型设计必不可少,那么在设计产品原型的时候有什么技巧和方法论?本文系统梳理了相关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 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。