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

推荐订阅源

C
Cisco Blogs
Cyberwarzone
Cyberwarzone
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
SecWiki News
SecWiki News
Martin Fowler
Martin Fowler
T
Tor Project blog
N
Netflix TechBlog - Medium
C
Cybersecurity and Infrastructure Security Agency CISA
V
Vulnerabilities – Threatpost
V
Visual Studio Blog
GbyAI
GbyAI
PCI Perspectives
PCI Perspectives
D
DataBreaches.Net
Jina AI
Jina AI
H
Heimdal Security Blog
云风的 BLOG
云风的 BLOG
P
Privacy International News Feed
A
About on SuperTechFans
J
Java Code Geeks
美团技术团队
H
Hackread – Cybersecurity News, Data Breaches, AI and More
N
News | PayPal Newsroom
有赞技术团队
有赞技术团队
MyScale Blog
MyScale Blog
博客园 - 司徒正美
C
Check Point Blog
T
Threat Research - Cisco Blogs
Attack and Defense Labs
Attack and Defense Labs
宝玉的分享
宝玉的分享
AI
AI
Simon Willison's Weblog
Simon Willison's Weblog
C
Cyber Attacks, Cyber Crime and Cyber Security
I
Intezer
P
Proofpoint News Feed
Blog — PlanetScale
Blog — PlanetScale
Apple Machine Learning Research
Apple Machine Learning Research
Hugging Face - Blog
Hugging Face - Blog
The Last Watchdog
The Last Watchdog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Vercel News
Vercel News
I
InfoQ
阮一峰的网络日志
阮一峰的网络日志
Cisco Talos Blog
Cisco Talos Blog
W
WeLiveSecurity
Hacker News: Ask HN
Hacker News: Ask HN
Recent Commits to openclaw:main
Recent Commits to openclaw:main
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
D
Docker
博客园 - Franky
Security Archives - TechRepublic
Security Archives - TechRepublic

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
用户体验研究应该在哪里进行?为流浪的 UXR 部门寻找一个归宿。
Kaysen用户研究 · 2024-07-23 · via 人人都是产品经理

将UXR置于设计、营销、产品管理或独立部门中有什么利弊?作者通过个人经验和行业观察,引导我们理解不同组织结构下UXR的作用和挑战,为希望优化其UXR战略的组织提供宝贵的视角。

我的用户体验研究职业生涯始于一个几乎无处不在的角色,在一个未定义的团队中,在一个新组建的部门中——说我试图通过模糊性来管理职责,这还只是轻描淡写。几年后,我经历了一些不同的组织变革,这些变革将我们的用户体验研究部门置于不同的群体层级之下。每一次变革都为我们带来了一系列优势,为我们的成功奠定了基础,并为我们未来改进流程提供了一些机会。

在做了一些初步的行业研究之后,我决定退后一步,公开探索 UXR 的每一个可能的“归宿”。

一、高水平的 UXR

用户体验研究包括行为观察、商业策略、心理学、数据分析、设计、团队协作等– 取决于公司结构和职位需求。UXR 可以有不同的风格,因此可以在整个行业的各个部门之间流动。我见过一些团队加入设计部门,一些加入营销部门,一些加入产品管理部门,这取决于公司的规模和类型。在我任职期间,我自己的团队也曾加入过以下每个部门。

那么……是否有一个部门能够更成功地为 UXR 带来影响?这就是我想要找到的。

UXR 部门是否应该生存……

二、在设计团队中

1. 优点

研究 + 设计密不可分:用户体验研究已成为许多 UX 设计师工作职责中不可或缺的一部分,UXR 的核心是为设计提供信息。研究指导交互,并从一开始就嵌入设计流程中。通过在设计团队中设立专门从事研究的部门,可以形成强大的联盟。让更广泛的设计团队制定总体用户体验策略,可以使研究和设计流程更加统一。设计师也往往对如何改善体验有很好的想法,并且通常很高兴看到最终用户与他们的想法互动。这促进了强大的测试、迭代和再次测试文化,直接与将对体验进行更改的人进行。由于这两个过程结合在一起,洞察力可以立即应用到设计中。

相似流程: UXR 流程与传统设计流程也非常相似。设计主管可以非常无缝地了解研究的各个阶段:审查现有数据、进行生成性研究、汇编信息和寻找模式、进行进一步研究或分析、创建报告、展示研究结果、发布后测试及后续工作。同时:从设计概念开始,征求意见,进行测试以查看哪个更好,迭代设计,创建最终构图,展示它,并在发布后及后续工作中进行迭代。设计和 UXR 始终希望携手并进,共同努力改善数字体验。

2. 缺点

研究≠设计:并非所有设计师都能进行研究,要么是因为他们根本没有时间,要么是他们没有接受过研究方法方面的培训。(相反,也并非所有研究人员都是设计师。)通常,公司会自动假设设计师也做研究人员的工作,反之亦然。这对最终产品来说可能是灾难性的。特别是在小公司,设计师需要身兼数职。这意味着他们有时需要进行自己的研究。不幸的是,这意味着招聘部门和领导团队会假设“设计”和“研究”如果没有明确定义,它们可以互换。(注意:这并不意味着有些设计师不合格,视觉设计师/平面设计师、UI 设计师和 UX 设计师的技能组合是有区别的,但我不会在这里讨论这个问题!)

用户需求可能会被遗忘:有时,专注于设计计划的路线图会以过于狂热的创意驱动力来创建,而不是基于数据或研究。很多时候,创意人员会执着于他们喜欢的新想法,即使它不是源于用户需要的东西(我们有时都会犯这种错误)。不幸的是,这意味着研究可能是一种事后想法,更多地用作验证工具,而不是在产品生命周期的前面,在产品生命周期中,它旨在事先定义需求。这可能成为 UXR 的一个难以克服的障碍,特别是如果设计概念由利益相关者或决策者领导审查,他们喜欢它并认为它是“可行的”。这意味着研究的机会很可能已经丧失。

三、在营销团队

1. 优点

相似的技能组合:市场研究和 UX/产品特定研究的核心是相似的流程和研究方法。社会心理学、市场营销、人类学、人为因素、运营和设计等许多领域开展“人员研究”所使用的工具包非常相似。大样本调查和分析等定量方法有助于为定性方法提供信息,例如现场观察、焦点小组、主持访谈、日记研究等。每个领域的方法都需要研究设计、用户招募和研究分析。对于营销团队来说,这是一个非常熟悉的世界,而以 UXR 的身份加入该部门意味着领导者可能会彻底了解您的角色需求。

以了解用户为共同目标:营销团队也会成为您的拥护者。无论如何,针对产品和设计的用户研究得出的见解会为营销部门关注的许多计划带来直接价值。营销和用户体验有相似的目标(了解客户),只是视角略有不同。尽管如此,当团队集体分享信息并合作在以业务为中心和以用户为中心的计划之间取得平衡时,结果对每个人都有帮助。

2. 缺点

业务需求可能与用户需求相反:如果视角差异太大,可以将营销和用户体验结合起来的视角也可能将它们分开。如果业务需求与用户需求相矛盾,可能会产生摩擦。如果部门领导优先考虑当前业务而不是用户研究,那么通过整合到营销部门,工具和客户的访问可能会受到限制。归根结底,一个小组专注于创收,即使这对用户来说不是最好的体验(例如将广告放在可能会侵入网页的某个地方,以确保用户看到它);而另一个小组则专注于用户体验的最佳方式(例如将广告放在页面较低的位置,不会干扰用户的任务,冒着用户看不到和不参与的风险)。

UXR ≠ 市场研究:有时,将 UXR 归入营销部门意味着其他人将 UXR 视为市场研究的延伸。因此,一些项目会交到 UXR 的办公桌上,而这些项目实际上应该由营销专家而不是用户体验专家来处理。例如,营销计划的目标可能是“我们如何让客户使用这项促销活动”?另一方面,UXR 可能会关注用户的需求,例如“客户希望如何收到有关促销活动的通知”?这种问题框架的改变会立即将业务目标转向关注用户,而这可能并不总是在营销的议程上。

四、在产品管理团队

1. 优点

路线图中为研究预留的时间:通过将 UXR 嵌入到产品管理团队中,研究有机会通过在产品路线图中划出应有的空间和时间,充分发挥其潜力。通过让 UXR 和产品经理向同一领导层汇报,这意味着目标和优先事项是共享的,并同时一起审查。这可能是一件很有意义的事情,特别是当您与产品经理一起开展项目时,他们了解如何使他们的产品对用户群体最直观。UXR 进入产品管理创造了一种更无缝的方式来定义实际的产品需求。这意味着在路线图中留出时间,在积压工作确定之前出去获取用户见解。这可以告知需要开发的功能的优先级,并在设计之前塑造产品本身的功能。当 UXR 与产品经理的目标紧密相关时,可以更轻松地将用户见解注入产品生命周期的每个阶段(理想情况下应该是这样的!)。

更轻松地与决策者传递知识:将 PM 与 UXR 紧密结合还意味着他们可以更定期地了解用户对其体验的评价,并可以更轻松地共享对这些用户渠道的访问权限。UXR 经常审查定性趋势的反馈程序(例如 Qualtrics 或 Medallia 系统)意味着产品经理有更多机会了解这些趋势。PM 通常应该对他们的用户群体有深入的了解,但他们往往很难在倾听用户意见的同时保持冲刺、业务分析、KPI 和路线图的正常运转。这就是与 UXR 紧密联系对 PM 有益的地方,因为团队会议现在始终有指定的用户倡导者在场。参加这些会议使 UXR 有机会与最需要了解这些需求的人直接就用户的需求引发自发对话。在同一个团队中,沟通渠道更加畅通,PM能够更频繁地了解用户的需求。

2. 缺点

研究可能会被降级:不幸的是,产品管理团队的参与意味着有时研究会被降级。当利益相关者对产品交付施加压力时,这通常意味着产品需要尽快推出。然后,产品经理必须专注于发布路线图上的项目,并在快速的时间线和开发冲刺中实现业务目标。为了满足这些时间表,尽早交付*某些东西*成为更紧迫的目标,而不是交付*经过研究*和磨练的产品(这需要更多时间)。

更具评估性而非生成性的研究:让 UXR 进入这个部门可能意味着研究变得更具评估性(或测试验证、可用性和迭代),而不是生成性(或测试理解需求、价值和概念发现或开发),就像在设计团队下一样。这不是一件坏事,而只是需要牢记的事情,以便作为用户倡导者,UXR 的工作是更直言不讳地表示需要留出时间来做更深入的生成性工作,从长远来看,而不是只在短期内为产品提供信息。提前了解这个可能的障碍意味着 UXR 可以更好地掌握 ROI 影响,从而有理由抽出时间进行更深入的研究。

五、在单独一个部门

注意:我还没有在单独的指定 UX 研究部门担任 UX 研究员的经验。我只能推测加入单独的 UXR 团队会是什么样的,或者当 UXR 领导层成为大型组织中的独立分支时,其利弊是什么。

1. 优点

让 UXR 部门领导自己的部门可以让我们有机会更深入地关注研究需求。它将能够制定自己的路线图,与合作伙伴的路线图相辅相成。它可以让部门领导层能够深入支持研究人员的需求,而这些需求往往是障碍(例如招聘、用户安排、预算、批准、ResearchOps 的管理工作等)。能够拥有研究路线图并抽出时间进行发现和生成研究可能会极大地帮助从长远来看同时提供产品和客户体验。拥有一个独立的团队可以实现这些研究奢侈。当领导者致力于使研究取得成功时,希望这意味着研究可以产生更具战略性的影响。

正如我在上面快速提到的那样,“ResearchOps”或研究运营是一个流行的短语,类似于“DesignOps”或“DevOps”等。抛开流行不谈,拥有一个拥有独立领导的部门可能意味着在执行领导层中占有更大的席位,这反过来意味着在使体验研究产生影响方面投入更多。当有理由对研究进行更深入的投资时,运营方面就有机会得到战略性的思考和支持。一个独立的 UXR 部门反过来可以雇用人员来支持管理和职责,让研究人员专注于他们面前的工作和分析。在小型组织中,甚至是真正大型组织(比如我的!)中的小型 UXR 团队中,研究人员往往身兼数职,这也没关系!但是,通过让一个部门专注于这些研究人员的需求并扩大他们工作的影响力(无论团队规模如何),我相信将有更大的机会收集更好、更深入的见解,并且研究过程可以充分发挥其影响力。

2. 缺点

相反,单独作为一个 UXR 部门也可能难以获得高管领导层的支持。如果不加入具有直接创收影响的部门(至少在短期内,比如销售或营销部门),UXR 的工作可能更难获得支持。利益相关者之间的合作和协调对于 UX 研究人员成功完成工作至关重要。如果没有它,如果 UXR 需求不被视为直接以产品为中心,那么同样的席位可能会帮助 UXR,也可能会阻碍他们。当团队的领导层与其他更成熟(即风险较小)的角色分开时,进行生成性研究的时间可能会被视为“冒险”,并且可能很难获得合作伙伴和利益相关者的支持。

同样,总体而言,投资独立的用户体验研究团队可能存在风险。很难预测业务合作伙伴理解的有形投资回报率预测,也很难首先投入资金。这意味着高管可能会认为,除了其他研究需求外,为用户体验研究分配预算或增加员工数量存在风险。研发通常是组织中的一个棘手领域,而用户体验研究肯定会在这个预算之内。尽管有证据表明,投资研发能够改变企业的底线,并可以通过创新保持公司的相关性,但紧迫的业务需求可能比独立用户体验研究团队的需求更受关注。

翻译:蒋昌盛

原作者:Danae Paparis

原文链接:https://uxdesign.cc/where-should-ux-research-live-7d0e7f86e2db

本文由 @蒋昌盛 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

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