产品方法 · 产品方法
用户画像Persona
把目标用户写成可讨论的具体人，并用目标与痛点把需求便签移进纳入或暂缓。
用画像把需求分进纳入或暂缓
切换画像看侧栏证据变；点「按当前画像自动落位」看便签如何跨列；也能单条手动移动。遮住底部说明，纳入/暂缓两列的便签与理由仍能讲清决策。
场景：作品集产品要砍范围。左侧是画像证据，右侧是需求便签墙——切换画像看证据变，点「按当前画像自动落位」看看板怎么改写；也能单条手动移动试探。看板本身就是决策结果。
复杂后台权限角色矩阵、审批流 一键公开链接生成可分享 URL 批量导出项目一次导出多个作品 手机预览移动端实时预览
- 把便签移到这里
- 把便签移到这里
当前画像：高三学生小林（目标：一键公开作品集，痛点：不懂部署与域名）。点「按当前画像自动落位」看目标与痛点怎样改写看板。
看板刚证明的四件事
上面每次移动便签，都在用目标与痛点当证据。画像的价值是改写看板，不是装饰。
- 画像要能移动便签：目标与痛点决定需求进纳入还是暂缓，否则只是姓名牌。
- 理由要引用字段：每条便签写明「因为目标/痛点是…」，而不是「用户都想要」。
- 换画像，落点变：同一需求对不同画像有不同取舍——后台对阿杰是纳入，对小林是暂缓。
- 画像是假设：没有访谈或行为证据时，要标成待验证，不代表全部用户。
什么时候该用画像
需要在多个需求间做取舍时用；问题已极清楚或没有证据时，不必先造完整画像。
功能清单膨胀、团队各说各的「用户」——用一个具体人约束范围，把「都想要」变成「小林要不要」。
没有访谈或行为证据时，画像只是假设；问题本身已经清楚时，也不必先造完整画像再开工。
怎么把画像写成能取舍的证据
拿到一堆功能清单时，按四步把画像从姓名牌变成能改写看板的依据。
- 锁一个具体人：给名字、角色和一句话场景（小林、高三、手机优先），不要写「所有用户」。
- 写目标与痛点：目标写可观察行为（一键公开链接），痛点写具体摩擦（不懂部署），而不是人口统计标签。
- 按字段取舍需求：把每条需求移进纳入或暂缓，并写「因为目标/痛点是…」的理由，让看板落点可追溯。
- 标待验证：没访谈或数据支撑的字段标「假设」，下一步去找证据，而不是直接当成结论开工。
同一作品集产品：正例与反例
目标都是决定做不做复杂后台。差异只在画像能否改写看板落点。
小林的目标「一键公开」、痛点「不懂部署」写在侧栏；「一键公开链接」「手机预览」便签进纳入，「复杂后台权限」「批量导出」进暂缓，每条便签都引用了目标或痛点。
差异：看板落点被画像改写，评审不再凭感觉。侧栏只有姓名和头像，没有目标与痛点；评审时便签仍堆在「待评估」，讨论继续说「用户都想要后台」。
差异：只差一处——画像没有任何字段能移动便签。快速自测
用户画像什么时候真正帮助了产品决策？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。