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

推荐订阅源

H
Help Net Security
G
Google Developers Blog
aimingoo的专栏
aimingoo的专栏
博客园 - 聂微东
酷 壳 – CoolShell
酷 壳 – CoolShell
小众软件
小众软件
Stack Overflow Blog
Stack Overflow Blog
美团技术团队
博客园_首页
T
Tailwind CSS Blog
博客园 - 三生石上(FineUI控件)
B
Blog
D
DataBreaches.Net
腾讯CDC
C
Check Point Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
U
Unit 42
月光博客
月光博客
V
V2EX
Vercel News
Vercel News
T
The Blog of Author Tim Ferriss
The Cloudflare Blog
博客园 - 叶小钗
Y
Y Combinator Blog

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
B端产品设计的五个过程输出物
洗七七 · 2023-12-04 · via 人人都是产品经理

下面这篇是笔者整理分享的关于B端产品设计的五个过程输出物的文章,里边包含项目立项书、需求清单、用例图、时序图、原型设计(原型+备注)的内容,对此感兴趣的同学可以进来看看哦!

一、项目立项书

B端产品的来源一般是客户,客户说我要一个什么,或者高层发现客户需要一个什么。那么公司内部就会申请立项,会有一个《项目立项书》,里面包括了:why-为什么做,how-怎么做,what-做成什么样,who-谁来做,是high level且粗颗粒度的阐述。如果立项书无法讲清楚这个事情,那么请退回到商业计划书(商业计划书是立项书的前一步,一个商业计划需要多个项目立项来支撑),谨慎判断做这个项目的价值。

此时,我们有了第一个输出物:《项目立项书》

二、需求清单

需求清单是收集客户需求的必要工具。

  • 清单必填项:需求点、需求描述、需求来源(提出者、提出时间)、需求创建(创建者、创建时间)、简单备注。
  • 优秀清单的判断标准:是否方便追溯这个需求以便真伪(无法追溯来源的需求,会在后期造成需求难辨真伪的情况,易造成团队精力的浪费)。

产品经理需要花费大量时间收集需求。

  • 全量足量:功能是否全面是判断B端产品好坏的重要标准。
  • 真实客观:需求阐述者往往也不清楚自己要什么,那么产品经理就需要与需求方共同挖掘真实的需求,抽丝剥茧。

挖掘需求的工具主要是深度访谈;其次是实习观察;再次是竞品调研。

  • 深度访谈:必须带着不吝赐教的态度,逐一与各个利益相关方深度沟通,只要与这个项目有关的所有人,都需要一一交谈,往往会对产品设计起到关键作用。
  • 实习观察:去到产品使用的场景中,亲自实习,或观察使用者。
  • 竞品调研:官网、公众号、展会、业内好友,都是信息收集来源;还有一个办法,就是以招聘或面试的方式去了解竞品。

通过各种方式,可以得到了很多零散的需求信息。

整理归拢后,我们有了第二个输出物:《需求清单》

备注:需求清单的工具并不重要,根据公司情况选择合适的,可以是本地excel,也可以是云端在线文档。

三、用例图

用例图,是用户与产品的最简交互形式,展示了不同用户与系统的关系(操作员、生产主管、管理员等不同用户与系统的关系是不同的,需要操作的功能也不同)。

用例图是在需求清单的基础上,把零散的需求点,串成与用户的逻辑关系。

此时,我们有了第三个输出物:《用例图》

四、时序图

时序图又名序列图、循序图,是一种UML交互图,是根据时间线展开的业务逻辑图。

时序图需要说明不同模块在时间线上如何开展业务逻辑,功能步骤是如何的。当产品功能较多时,可以分成多个时序图来说明。

此时,我们有了第四个输出物:《时序图》

五、原型设计(原型+备注)

原型设计我偏向是原型图+备注的形式,包括的信息有:导航关系、页面布局、整体说明、按钮说明、输入框说明、弹窗说明、跳转说明,以及版本记录。

原型设计的原则:准确秒懂+清晰无歧义+变更记录。

此时,我们有了第五个输出物:《原型设计》

另外,性能需求如安全性、稳定性、鲁棒性、可维护性,这些需求也需要同时提给团队。

到此为止,团队对于做成什么样应该很清晰了。(在用例图时,开发团队就可以开始介入,同步设计技术架构和实现方案了,此篇不展开)。

重要说明:全程必须有客户相关方参加,以免陷入闭门造车的境地;参与方式可以是会议、邮件、即时聊天,但参与结果必须书面记录,切记书面记录!

本文由 @洗七七 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

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