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

推荐订阅源

让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
WordPress大学
WordPress大学
人人都是产品经理
人人都是产品经理
Engineering at Meta
Engineering at Meta
小众软件
小众软件
I
InfoQ
有赞技术团队
有赞技术团队
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Martin Fowler
Martin Fowler
月光博客
月光博客
雷峰网
雷峰网
aimingoo的专栏
aimingoo的专栏
云风的 BLOG
云风的 BLOG
Last Week in AI
Last Week in AI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
S
SegmentFault 最新的问题
The GitHub Blog
The GitHub Blog
Y
Y Combinator Blog
V
Visual Studio Blog
博客园 - 叶小钗
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
GbyAI
GbyAI
P
Proofpoint News Feed
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-06-04 · via 人人都是产品经理

在一个团队里面,有点小事就吵架可太正常了。但我们需要吸取教训,争取下次不再犯同样的错误;同时,也需要注意一下沟通技巧和方式才行。

设计师在工作中经常会遇到与前端开发的合作问题,举几个常见的例子:

😭 开发做出的页面设计还原度很差,一些明显的细节问题他都视而不见…

😠 我给开发提意见,但他不爱听,工作态度很差,不好好配合!

😡 我明明就是对事不对人,开发却各种找理由和借口地反驳我的建议…

我之前给大家介绍过一些在规章制度上约束开发工作质量的方法:经验|开发的设计稿还原度低,该怎么办?。不过今天想跟大家聊的是在沟通上的注意事项:怎样做才是真正的“对事不对人”,避免无效沟通?

一、问题到底出在哪?

我们在情绪激动时会认为自己仍是在理性地、客观地描述事实,也总会习惯性地说一句:“哎,你不要介意,我这样说是对事不对人啊!”。

但是,对“事”,不仅指针对这件事情本身,更是指“客观事实”。而这就涉及到一个重要问题:

你所认为、所描述的“事实”,真的也是别人眼中的“事实”么?

举个例子,你可能也遇到过这种场景:

你看到开发在还原你的设计稿时,一些细节出了问题,可能就会脱口而出:

“你开发的还原度也太粗糙了吧!你看好多地方都没对齐,字号的大小也不一样,间距也不统一!”

你对面的开发大概率会立即反驳你:

哪里粗糙了?这还是我昨天熬夜开发出来的呢!这个页面哪有你说的这么多问题啊?我没看到!”

再这样聊下去,双方都带上了情绪,这场沟通就会变得很艰难。

其实这里的问题就是出在你们双方对于“事实”的认知上

你认为自己是在描述的都是“事实”:
第一,我说得是设计稿的还原度粗糙,不是说你干活干得粗糙,我并没有针对你这个人。

第二,我给你指出来的这几点问题,真的都是白底黑字显示在页面上的。

但开发可不这么认为。因为他接收到信息很有可能是这样:

第一,你说是稿子的还原度粗糙,但稿子就是我开发出来的,那你不就是说我活儿干得粗糙么,就是在对我个人工作成果和状态的质疑。

第二,我怎么没有看到页面上有没对齐的地方?我看这些字号的大小也就是一样的啊,我又不像设计师一样都是“像素眼”。

你看,你以为的“事实”,在对方的认知里,根本就不是“事实”,这就不算是“对事不对人”,也就很容易在沟通的过程中产生问题。

我们与别人的沟通中也常常会包含两层信息,即客观信息主观信息。客观信息是对于事物中立的、准确的描述;主观信息是你基于自身经验和认知对于事物做出的评价。

主观信息有时只是说话人自然地流露,甚至连你自己都没有意识到,但说者无意,听者却可能有心,这就会对沟通产生阻碍。

二、我们应该怎么做?

了解了问题的所在,你需要做的就是:正确地定义“事实”,并使用恰当的表述方法来做表达。

所谓的“事实”,应该是沟通双方都已经达成一致的“共识性内容”或“客观内容”。也即当你想要描述事实时,不应是基于个人视角,而是基于双方共有的认知

然后,你可以尝试这样的表达方式:

1. 在提建议前,肯定对方的付出

比如:“我知道你昨天熬夜很辛苦,不过我还是看到了这几个小问题,从设计师的角度来看,我觉得还是需要改改的。辛苦你再做做调整。”

2. 在提建议时,更加客观地描述

不要说:“你开发后的稿子里好多地方都没有对齐。”

而要说:“我发现左边第二张卡片和第三张卡片没有做到左对齐,差了 2px;右边第一段文字和第二段的文字,一个是14px,一个是16px,这两个字号大小不一样。”

这样做沟通,相信对方的态度也会缓和很多。

要知道,你永远也叫不醒一个装睡的人:只要对方不想被说服,你就永远不可能说服他

而很多时候,对方并不是不认可你的道理,只是反感你表达的方式,产生了抵触情绪。所以不论是在工作还是在生活的交谈中,哪怕你有再多的理由,也都应该学会客观表达。

专栏作家

元尧,微信公众号:长弓小子,人人都是产品经理专栏作家。一线互联网大厂B端体验设计师,清华大学美术学院本硕连读。曾负责国内最大开源组件库Ant Design组件的设计和运营工作,目前负责国际业务线B端产品体验设计和组件库的搭建工作。

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

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

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