<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>Empathy · 仁才德</title>
    <link>https://jared.lynskey.co.nz/zh-cn/tags/empathy/</link>
    <description>关于软件工程与研发团队领导力的短文——绩效评估、招聘与团队扩张、CI/CD、DevOps 监控、智能体 AI。写于首尔。</description>
    <generator>Hugo</generator>
    <language>zh-CN</language>
    <copyright>© 2026 仁才德</copyright>
    <lastBuildDate>Wed, 28 Oct 2026 00:00:00 +1300</lastBuildDate>
    <atom:link href="https://jared.lynskey.co.nz/zh-cn/tags/empathy/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>用户画像（Persona）是什么？为和你不一样的用户做设计（附示例）</title>
      <link>https://jared.lynskey.co.nz/zh-cn/posts/2023/2023-10-03-following-personas/</link>
      <guid isPermaLink="true">https://jared.lynskey.co.nz/zh-cn/posts/2023/2023-10-03-following-personas/</guid>
      <pubDate>Tue, 03 Oct 2023 00:30:03 +0000</pubDate>
      <dc:creator>Jared Lynskey</dc:creator>
      <category>persona</category>
      <category>global marketplace</category>
      <category>personal biases</category>
      <category>user research</category>
      <category>empathy</category>
      <category>product design</category>
      <description>用户画像（Persona）是什么，一个社区应用的用户画像示例，怎么从画像写出用户故事，以及当用户和我完全是两种人时，我靠什么来弥补自己直觉上的偏差。</description>
      <content:encoded><![CDATA[<p>用户画像（Persona）是一份基于调研写成的简短档案，描述一类典型用户：他们是谁、在什么场景下用你的产品、想完成什么事、被什么困扰、平时怎么行动。团队写上几份，“用户”这个词就不再等于“刚好坐在会议室里的人”。不过，用户画像的好坏完全取决于背后的调研。在会议上拍脑袋编出来的画像，不过是你自己的假设配了一张图库照片；用户和你越不像，这个问题就越要命。</p>
<p>我是一个在首尔工作的新西兰开发者，做的产品是一个护肤和化妆品爱好者社区。我本人完全不是那种人——我的护肤流程，状态好的时候能涂个防晒。这就意味着，我对&quot;用户想要什么&quot;的直觉，错得足够频繁，频繁到我已经学会不去相信它。</p>
<p>如果你在为需求、背景、偏好都和自己不同的人做东西，你的直觉就是失准的。下面是我的应对办法。</p>

<h3 class="relative group">调研赢过直觉
    <div id="调研赢过直觉" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e8%b0%83%e7%a0%94%e8%b5%a2%e8%bf%87%e7%9b%b4%e8%a7%89" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>直觉是照着错误的用户校准的，唯一的修正办法就是去接触真实的用户。问卷和访谈提供原材料——只要你问开放式的问题、然后闭嘴，人们会把自己的痛处讲得明明白白。去用户已经聚集的论坛和社区里潜水，成本更低，那里每天的抱怨和热情，比任何研讨会都更有信息量。已有的报告和研究用来兜底，主要用途是验证你发现的规律是真规律，还是只是嗓门最大的那三个人的意见。</p>

<h3 class="relative group">用户画像示例
    <div id="用户画像示例" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e7%94%a8%e6%88%b7%e7%94%bb%e5%83%8f%e7%a4%ba%e4%be%8b" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>像我上面说的这种社区应用，我会把调研结果浓缩成下面这个样子。敏智是为这篇文章编的虚构人物；真正的用户画像应该直接来自你的访谈和论坛观察。</p>
<table>
	<thead>
			<tr>
					<th>用户画像示例</th>
					<th>敏智，29 岁</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>场景</td>
					<td>在首尔上班，敏感的混合性皮肤。通勤路上刷社区，大概一个月发一篇测评。</td>
			</tr>
			<tr>
					<td>目标</td>
					<td>找到不会让皮肤过敏的产品；买新精华之前，先弄清楚它值不值这个价。</td>
			</tr>
			<tr>
					<td>痛点</td>
					<td>读完才发现是广告的测评；肤质和自己完全不同的测评者；有用的回答只有一条、还埋在长帖深处。</td>
			</tr>
			<tr>
					<td>对产品的需求</td>
					<td>能按肤质和皮肤问题筛选的测评，清楚标明的广告帖，以及能快速向肤质相近的人提问的方式。</td>
			</tr>
	</tbody>
</table>
<p>用户画像要真正派上用场，得落到 backlog 里。每个目标、每个痛点，都可以写成熟悉的“作为……，我想要……，以便……”格式的用户故事。比如：“作为一个敏感肌用户，我想按肤质筛选测评，以便只看皮肤反应和我相近的人写的产品体验。”如果某个用户故事追溯不到任何一个画像，就值得问一句：它到底是为谁做的？</p>

<h3 class="relative group">先进他们的脑子，再进他们的日常
    <div id="先进他们的脑子再进他们的日常" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e5%85%88%e8%bf%9b%e4%bb%96%e4%bb%ac%e7%9a%84%e8%84%91%e5%ad%90%e5%86%8d%e8%bf%9b%e4%bb%96%e4%bb%ac%e7%9a%84%e6%97%a5%e5%b8%b8" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>共情地图听起来像咨询公司的表演，但把一个用户画像在想什么、感受什么、说什么、做什么逐条写下来，会逼你发现自己一直在把个人偏好投射到用户身上。便利贴本身不重要，重要的是抓住那个&quot;正在想当然&quot;的自己。</p>
<p>更彻底的版本是沉浸：用他们用的产品，看他们看的内容，去他们去的地方。真正试过我们用户天天讨论的那些护肤流程之后，我对产品该讲清楚什么，比读任何需求文档都明白。</p>

<h3 class="relative group">原型、测试、倾听，再来一遍
    <div id="原型测试倾听再来一遍" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e5%8e%9f%e5%9e%8b%e6%b5%8b%e8%af%95%e5%80%be%e5%90%ac%e5%86%8d%e6%9d%a5%e4%b8%80%e9%81%8d" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>再多的调研，也扛不住和原型的第一次见面。所以先做出最小的可测试版本，摆到真实目标用户面前，把他们的困惑当成数据，而不是&quot;你用错了&quot;。上线之后也要保持真正畅通的反馈渠道，因为理解不是一次性完成的事——受众在变，潮流在动，去年的洞察会悄悄过期。这个循环没有终点。没关系。</p>

<h3 class="relative group">借几双校准更好的眼睛
    <div id="借几双校准更好的眼睛" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e5%80%9f%e5%87%a0%e5%8f%8c%e6%a0%a1%e5%87%86%e6%9b%b4%e5%a5%bd%e7%9a%84%e7%9c%bc%e7%9d%9b" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>有些差距靠自己是补不上的。真正属于目标群体的同事，能看见你一辈子都看不见的东西，我平时就靠他们靠得很勤。如果你和用户之间的差距不是裂缝而是峡谷，那就用招人来解决——实在不行请顾问，更好的办法是招一个本人就是用户的队友。</p>
<p>这一切的底层只有一条纪律：记住目标是做出打动他们的东西，而不是取悦你自己的东西。到现在我还是会时不时发现自己在为自己做设计。调研、测试、借来的眼睛，说到底都只是提早抓住这种时刻的手段。坚持下去，你就能做出对真正在用它的人有用的产品——这本来就是全部的意义。</p>
]]></content:encoded>
      <media:content url="https://jared.lynskey.co.nz/en/posts/2023/2023-10-03-following-personas/featured.jpeg" medium="image" type="image/jpeg" />
    </item>
    <item>
      <title>领导力中的同理心：多少算过头？（附正反例子）</title>
      <link>https://jared.lynskey.co.nz/zh-cn/posts/2023/2023-09-24-empathy-in-management/</link>
      <guid isPermaLink="true">https://jared.lynskey.co.nz/zh-cn/posts/2023/2023-09-24-empathy-in-management/</guid>
      <pubDate>Sun, 24 Sep 2023 00:30:03 +0000</pubDate>
      <dc:creator>Jared Lynskey</dc:creator>
      <category>Empathy</category>
      <category>Management</category>
      <category>Right Balance</category>
      <category>leadership</category>
      <category>team dynamics</category>
      <category>communication</category>
      <description>领导力中的同理心到底是什么意思？带团队时做得好和做过头的具体例子，同理心太多会给团队惹什么麻烦，以及一对一沟通里最管用的那个问题。</description>
      <content:encoded><![CDATA[<p>今年读过的管理文章，说的都是同一件事：要更有同理心。行，没问题。可是没有一篇告诉你，界线画在哪里。</p>
<p>这条线我是自己摸出来的。我不是科班出身的管理者，只是一个写着写着代码就开始带项目团队的开发者，所以下面这些，基本都是先犯过一点小错才学会的。</p>

<h3 class="relative group">领导力中的同理心是什么意思
    <div id="领导力中的同理心是什么意思" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e9%a2%86%e5%af%bc%e5%8a%9b%e4%b8%ad%e7%9a%84%e5%90%8c%e7%90%86%e5%bf%83%e6%98%af%e4%bb%80%e4%b9%88%e6%84%8f%e6%80%9d" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>领导力中的同理心，是弄清楚团队里每个人的真实状态，并在做决定、给反馈、定团队工作方式的时候，把它当作一个有分量的变量。它不是什么都点头，也不是在会议上表现得和气：你完全可以充分理解一个人的处境，同时对他说不。当人们发现自己的处境真的被考虑进去了，就会放松下来，更早开口说话，工作也明显更顺。这一点上，那些老生常谈的建议是对的。</p>

<h3 class="relative group">太少是病，太多也是病
    <div id="太少是病太多也是病" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e5%a4%aa%e5%b0%91%e6%98%af%e7%97%85%e5%a4%aa%e5%a4%9a%e4%b9%9f%e6%98%af%e7%97%85" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>所有人都在警告的失败，是那种把人当资源调度的冷面管理者。这种失败是真的：无视别人生活里正在发生的事，人就会沉默，士气会掉，问题要拖好几个月才浮出水面。</p>
<p>没有人警告你的，是反方向的失败。什么都迁就，边界就模糊了。截止日期变成参考意见。那些默默守着标准的人，开始为不被要求守标准的人兜底，怨气悄悄积累。我自己就干过这种事——当时觉得是体贴，多让了一步，可对团队里其他人来说，那一点都不体贴。</p>

<h3 class="relative group">同理心的正反例子：做得好与做过头
    <div id="同理心的正反例子做得好与做过头" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e5%90%8c%e7%90%86%e5%bf%83%e7%9a%84%e6%ad%a3%e5%8f%8d%e4%be%8b%e5%ad%90%e5%81%9a%e5%be%97%e5%a5%bd%e4%b8%8e%e5%81%9a%e8%bf%87%e5%a4%b4" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>放在一起对比，差别就清楚了。这些算不上规则，只是我努力想做到的样子：</p>
<table>
	<thead>
			<tr>
					<th>场景</th>
					<th>做得好</th>
					<th>做过头</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>和状态不好的同事一对一</td>
					<td>问一句&quot;最近最难的是什么？&quot;，然后定下一件我这边要改的事</td>
					<td>一小时全在安慰，最后什么也没定</td>
			</tr>
			<tr>
					<td>有人在工作之外正经历难关</td>
					<td>给他减几周的工作量，约好哪天再看；跟团队只说在重新分配任务，不说原因</td>
					<td>不设期限，悄悄把他的活接过来，让其他人默默消化</td>
			</tr>
			<tr>
					<td>截止日期一再延误</td>
					<td>问清楚是什么卡住了，同时说明截止日期依然重要</td>
					<td>一次次往后推，好躲开这场谈话</td>
			</tr>
			<tr>
					<td>对不理想的工作给反馈</td>
					<td>私下说、说具体、对事不对人，再给一个&quot;好是什么样&quot;的例子</td>
					<td>话说得太委婉，对方根本没意识到有问题</td>
			</tr>
			<tr>
					<td>答应不了的请求</td>
					<td>&ldquo;现在不行，原因是这样，我能做到的是这些，下个月我们再聊。&rdquo;</td>
					<td>&ldquo;再看看吧&rdquo;，然后再也没有下文</td>
			</tr>
	</tbody>
</table>
<p>做过头的那一栏有个共同点：当下感觉很体贴，实际上是把代价推给了以后，或者推给了别人。</p>

<h3 class="relative group">大部分活儿是一对一沟通干的
    <div id="大部分活儿是一对一沟通干的" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e5%a4%a7%e9%83%a8%e5%88%86%e6%b4%bb%e5%84%bf%e6%98%af%e4%b8%80%e5%af%b9%e4%b8%80%e6%b2%9f%e9%80%9a%e5%b9%b2%e7%9a%84" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>我能勉强保持在平衡点附近，靠的不是什么理念，是日历上的一个循环日程。有了固定的一对一，小问题就会在还小的时候冒出来，而不是某天以一封辞职信的形式集中送达。</p>
<p>我的一对一每次问的差不多是同几件事：现在卡在哪，最近什么事做得不错，团队配合怎么样，接下来想往哪个方向成长，以及我有什么该改的。</p>
<p>最管用的问题特别朴素：&ldquo;工作上有什么需要我或者团队帮忙的吗？&ldquo;听着平淡，其实不然。它传递的信号是：我打算参与解决，而不是只听你说。而且得到的回答几乎总是能实际落实的具体事——帮忙对接某个人、拍板一个悬着的决定、抽一小时结对。</p>

<h3 class="relative group">说&quot;不&quot;的时候更要坦诚
    <div id="说不的时候更要坦诚" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e8%af%b4%e4%b8%8d%e7%9a%84%e6%97%b6%e5%80%99%e6%9b%b4%e8%a6%81%e5%9d%a6%e8%af%9a" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>一对一聊多了，请求自然会攒起来，不可能都答应。怎么处理那些答应不了的，恰恰是信任建立或崩塌的地方。</p>
<p>我的做法是：认真对待请求，并且让对方知道我认真对待了；解释现在为什么办不到；有折中方案就给折中方案；说清楚什么时候再看这件事；然后真的回来再谈，哪怕结论没变。</p>
<p>这些做法不会让拒绝变得愉快。但一句有理由的、坦率的&quot;不行&rdquo;，远比一句再也没有下文的&quot;再看看&quot;更让人服气。</p>
<p>我能总结出的公式也就这么多：真心在意大家的状态，对工作的要求实话实说，然后保持足够频繁的沟通，好在自己偏向任何一边太远的时候，能及时发现。</p>
]]></content:encoded>
      <media:content url="https://jared.lynskey.co.nz/en/posts/2023/2023-09-24-empathy-in-management/featured.jpeg" medium="image" type="image/jpeg" />
    </item>
  </channel>
</rss>
