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

推荐订阅源

人人都是产品经理
人人都是产品经理
Google DeepMind News
Google DeepMind News
博客园 - 【当耐特】
量子位
博客园 - 司徒正美
爱范儿
爱范儿
Hugging Face - Blog
Hugging Face - Blog
博客园 - 聂微东
Jina AI
Jina AI
J
Java Code Geeks
腾讯CDC
大猫的无限游戏
大猫的无限游戏
V
Visual Studio Blog
I
InfoQ
D
Docker
Recent Announcements
Recent Announcements
MongoDB | Blog
MongoDB | Blog
博客园 - Franky
宝玉的分享
宝玉的分享
G
Google Developers Blog
GbyAI
GbyAI
Y
Y Combinator Blog
有赞技术团队
有赞技术团队
H
Help Net Security

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
跟UI设计吵了一架
晨阳产品笔记 · 2025-10-24 · via 人人都是产品经理

在职场中,团队成员之间的沟通与协作是至关重要的,但难免会因为意见不合而产生冲突。本文的作者,一位产品经理,就亲身经历了一次与 UI 设计师的激烈争吵。这次争吵不仅涉及了设计问题,还反映了产品与设计团队之间在工作流程和职责理解上的差异。

说实话,我本身并不是喜欢吵架的性格,特别是做了产品经理之后,脾气慢慢被磨得平和了很多。再加上现在有了家庭和孩子,更觉得很多事没必要较真。

但昨天因为一个设计问题,我还是和 UI 同事争执了起来,甚至惊动了总监。最后两人都被教育了一通,事情才算收场。

对于总监的说法,我当时虽然有些不同想法,但临场反应没那么快,没能很好地为自己辩解。下班后我仔细复盘了整件事,觉得有些道理还是得说清楚。

不知道大家是不是也这样——吵完架之后,脑子里还会反复重播当时的场景,想着“如果当时这么说就好了”,懊恼自己为什么没发挥好……

1.事情的背景

最近有个大屏需要 UI 设计,她发来设计稿后,我审核时发现几处不太合理的地方,主要是对业务和需求背景理解有偏差,甚至还有明显的字段错误。我就逐一标注好修改建议发回给她。

没过多久,UI 同事来问我大屏中某个按钮是什么意思——其实需求文档里已经写得很清楚。这说明她设计前并没有仔细看文档,于是我就回了一句:

“XX,设计之前可以先看一下需求文档,把需求背景了解清楚再动手哈”

为了语气缓和些,我还特意加了个“哈”字。不知道是我平时脾气太好,还是她比较敏感,这句提醒却意外点燃了她的情绪。她直接把我叫过去,语气很冲地问我:“你这话是什么意思?”

于是辩论开始了……

我的观点:

  1. 设计之前应该先理解业务和需求,有疑问提前沟通清楚,而不是对着原型就直接开始设计。
  2. 交付设计稿前,最好自己先对照原型检查一遍,避免出现明显的字段错误。
  3. 有问题早沟通,而不是设计完了再说“需求表达不清”,这有点事后甩锅的嫌疑。

UI设计的观点:

  1. 设计有问题她可以改,但我不该说那句话”。
  2. 她还提到我平时需求写得也有不清晰的地方,认为我不该单方面指责她。

其实我说那话还有个背景,因为这种事情不是出现一次两次了,每次交给我的设计图,我都需要一个个元素一个个字段对照检查,有很多设计不加思考,不管丑与美就直接设计交付了。

每次改设计稿改的心累,并且每次我表达我对这个设计觉得不合理的时候,也表达了我的理由和想法,设计不是下去再思考,而是直接问:

你觉得怎么设计好?

到后来基本变成了我给设计方案,她照着我的设计方案直接设计。

多次之后,才有了一开始我说的那句话,才有了这次的争吵。

2.我的思考

对于产品

我承认自己在需求描述上确实还有优化空间,表达可以更严谨。但产品需求再细致,也难免有遗漏,不可能做到 100% 无歧义。这就需要团队在前期充分沟通,及时澄清疑问。所以每次评审会后,我都会强调:“有任何问题随时提出来,我们及时同步。

对于设计

我认为分为高低两个层级:

  1. 基础层级,完全按产品原型的布局来,只做视觉美化。
  2. 高级层级,基于业务逻辑和用户需求,自主进行信息架构和界面设计,不只停留在“画图”。

目前大多数 UI 可能处于第一层。但我始终觉得,UI 不是美工,要想走得远,必须懂业务、有想法、有主张,否则很容易被工具替代。

有时候我也会想:我们做的是 G 端产品,用户量不大,我为什么还要这么较真?

仔细一想,我觉得可能每个人对自己的工作或者对自己负责的产品追求不一样吧,我是觉得干一行爱一行,要为自己的工作和自己的产品负责,只要自己对自己有更高的要求,才能有所收获或成长。

好了,就嘚啵嘚到这里,工作中的小插曲,分享出来大家也看个热闹,发出来也是想和大家交流一下,相信很多人也有类似经历。

总之,做好自己份内的事,问心无愧就好。

本文由人人都是产品经理作者【晨阳产品笔记】,微信公众号:【晨阳产品笔记】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

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