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

推荐订阅源

OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园_首页
雷峰网
雷峰网
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
WordPress大学
WordPress大学
腾讯CDC
T
Tailwind CSS Blog
A
About on SuperTechFans
H
Hackread – Cybersecurity News, Data Breaches, AI and More
The GitHub Blog
The GitHub Blog
T
The Blog of Author Tim Ferriss
G
Google Developers Blog
The Cloudflare Blog
D
DataBreaches.Net
Recent Announcements
Recent Announcements
Engineering at Meta
Engineering at Meta
B
Blog
博客园 - 聂微东
阮一峰的网络日志
阮一峰的网络日志
月光博客
月光博客
博客园 - 司徒正美
MongoDB | Blog
MongoDB | Blog
Google DeepMind News
Google DeepMind News
Apple Machine Learning Research
Apple Machine Learning Research

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
迭代需求落地设计方程式
(*≧▽≦) · 2024-12-17 · via 人人都是产品经理

迭代设计需求是指在产品设计过程中,对原有设计进行不断改进和优化的一系列要求。作为大部分产品经理的工作内容,作者整理了一套自用的“WCPHV设计方法”,一起来学习一下。

当拿到一个迭代设计需求的时候,设计师该如何着手去做需求,本人整理了一套自用的WCPHV设计方法

  • 【W】Why:为什么要迭代?原来有什么问题、新版本要达到什么目的
  • 【C】Content:迭代的内容,明确用户场景、功能与流程梳理
  • 【P】Problem:聚焦用户的问题,收集与核实用户痛点并从中寻找设计机会点
  • 【H】How:怎么解决问题,针对已知痛点,明确设计方向和探索具体的解决方案
  • 【V】Verification:设计验证,拟定验证方案,跟进后续反馈,不断完善体验

下面以“智能外呼”的设计案例串联阐述迭代设计的具体步骤与方法

第一步:WHY

了解清楚我们为什么要做这个需求

通常B端的迭代需求常见的有四类:满足用户期望、设计创新、数据反馈分析、管理层战略规划

  1. 满足用户期望:需要了解用户现在使用遇到什么问题,可以和用户直接交流,获取一手未加工信息。因为产品经理的转达可能带着自己的理解和方案会带有引导性,局限设计思路。直面的交流更容易发现设计的机会点
  2. 设计创新:通常来源于现有市场竞品和类竞品已有的功能,这类需求没有办法知道竞品设计师的意图,只能靠产品经理和设计师自身对业务的积累与理解进行分析,这个功能可能会为用户带来什么好处,是提升了工作效率?还是降低了人工/资产成本,判断是否适用于公司本身的业务,或者怎么运用更有利于在本公司提效降本
  3. 数据反馈分析:这个是最客观的需求,通过历史数据分析用户行为,不断的完善体验,不用质疑,直接开干!当然这基于数据采样合理、分析正确的前提。例如产品刚上线一个月,没有培训,没有新手引导,说没有使用量产品功能不OK要改版肯定不合理。B端用户都有自己固定的工作流程,等用户自己探索发现新功能的概率极低
  4. 管理层战略规划:一般这个层次的需求,就是“重点项目”。老板们会给一个我想做什么的概念,那就需要产品和设计师去完善怎么好,这个时候如果时间允许的情况下做调研是非常有必要的。对于未上线的功能用户没有实际使用会给不出合理的建议,但是我们可以围绕功能的场景进行展开咨询,更合理的满足用户需求

智能外呼迭代需求设计,为什么要做这个需求? 【设计创新】

外呼主要用户是客服,每月约有2万多人访问,访问量达30万次,使用量非常大,但是对比竞品公司的页面发现,我们的产品的信息展示过多,层级不够清晰,导致页面重点不突出,阅读费力度高;页面风格陈旧,观感欠佳;简单操作下钻深,不够轻量,希望新版本在体验上有一个升级,让用户用起来更加舒适和简单

旧版本页面

第二步:Content

对迭代的内容有一个清晰的了解,包括场景、功能、流程等

  • 梳理场景的方法常用的有用户画像法、情景观察法。C端的产品对于服务的是哪一细分群体的用户非常明确,因此用户的场景会比较清晰,比较适用于用户画像绘制。但是B端的用户很多时候服务的是不同的组织,可能每个组织的管理模式不一样,岗位要求不一样,都会导致用户使用习惯不一样,因此在B端仅参考用户画像设计指导产品迭代是不太适用和实用的。建议大家有条件的使用情景观察法,实地了解用户场景和需要,条件不允许的情况下可通过产品经理间接了解用户的场景,确保设计符合用户真实心智
  • 功能和流程我们可以基于用户访谈、情景观察、页面走查、产品经理业务介绍等多种方式进行梳理绘制,在设计交互的过程中作为参考,保证流程的闭环,细节思考到位

外呼场景/流程梳理:主要采取产品经理业务介绍、页面走查的方式完成

分析了用户在呼叫前、呼叫中、呼叫后的主要操作步骤流程,以及对应的场景及目的

第三步:Problem

问题在哪里,收集与核实用户痛点

在做流程/场景梳理的过程中,会直接或者间接的收集到用户的问题,那我们需要做的是验证这些问题是否真实存在。例如一个用户说“某某功能我觉得应该怎么样设计更好”,这时候我们需要找别的用户验证,请教他们平时是否用这个功能,用的怎么样?有什么建议?不要直接问,侧面去核实这个问题是否真实存在,避免引导用户;再例如我们走查发现一个功能交互非常不友好,是不是立马改?不是的我们需要核实,首先咨询产品经理,当时这么做的原因是什么,因为我们非专业用户可能会不理解实际业务需要(B端的产品很多专业性较强,有学习成本),其次和产品经理意见不同可以直接咨询实际用户使用的场景是什么样,有没有遇到什么问题。还是那句话侧面咨询不要直接问!

外呼用户痛点分析,设计机会点挖掘

本次需求涉及改版功能主要是打电话,了解了用户打电话的场景后发现信息层级非常凌乱,操作也不够轻量,很多简单快捷的操作都需要跳转新页面解决;视觉表现欠缺

场景1:在页面电话号码处点击拨号、再在外呼点击呼叫完成打电话

场景2:对于需要重复拨打的场景要么重新找到信息拨打,要么在通话记录里拨打

场景3:除了电脑呼叫,其他方式都是转移到别的设备接听

场景4……

第四步:How

怎么解决问题,明确设计方向和解决问题的具体方案

结合自身经验以及业务了解,提炼出可以解决问题的设计策略方案,设计的方法论有很多,也是作为设计师的基本功,比如格式塔原理、尼尔森十大可用性则、简约四设计、费茨定律等等,我就不在这具体阐述了

外呼设计主要拟定了以下三个设计策略

1、拨打前:合理处理信息展示,提升易操作性和阅读性

2、拨打中:视觉升级,界面展示更清晰友好

3、拨打后:缩短回拨路径、提升回拨的效率

设计终稿

第五步:Verification

设计验证:拟定验证方案,跟进后续反馈,不断完善体验

设计验证基于需求想要达成的目标(包含用户、业务),从而制定可以衡量的指标。B端产品衡量我比较喜欢用腾讯的USE模型。一致性是基础,保证用户心智统一,除此之外,设计师设计费重中之重就是保证产品的易用性和任务效率,满意度是对产品整体的感受,包含视觉、功能、交互多个层面,也是需要关注的

外呼重点关注新版本用户满意度和使用效率,涉及指标如下

新版本选择使用率 = 选择新版本用户数/总用户数

插件内通话记录拨号量

本文由 @(*≧▽≦) 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

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