个人成长 / 产品设计能力
从全栈工程师到产品架构师
你已经具备了优秀的交互设计敏感度——能捕捉飞书点赞排序、豆包长按语音这类 micro-level 设计。 你缺的不是"审美"，而是从用户痛点到功能优先级再到界面布局的 macro-level 决策链路。 本文给出诊断、四项刻意练习和推荐资源。
诊断：两种不同的能力
你已经有的
交互设计敏感度（Micro）
"给定一个功能，如何把它做到优雅。"
- 飞书点赞排序
- 豆包长按语音
- 动效、微交互、状态反馈
你需要补的
产品架构能力（Macro）
"面对用户群体和问题集，决定界面上放什么、不放什么、以什么优先级放。"
- 信息架构与导航层级
- 功能取舍与优先级
- 用户旅程与核心路径
无力感的根因
产品架构本质上是决策能力，不是设计能力。做决策需要一个用户模型来帮你裁决—— 用户是谁、他们今天怎么干活、什么让他们痛苦、什么是他们根本不在乎的。
当你设计软件工厂界面感到无力时，不是因为你不懂布局，而是因为你缺少一条完整的决策链路：
没有前两步，第三步就只能凭感觉堆功能。这不是能力问题，是信息输入不足。
四项刻意练习
逆向拆解成熟 B 端产品
频率：每周 1 个 / 每次 1 小时
做法
挑一个你觉得"布局很对"的 B 端产品（Linear、Notion、Figma、飞书项目），花 1 小时回答下面 4 个问题：
- 它的主页面放了什么、没放什么？
- 导航结构是怎样的？为什么这样分层？
- 哪些功能藏在二级入口？为什么不放一级？
- 如果去掉其中一个模块，用户会不会发现？
输出：一张信息架构图 + 你的判断理由。重点不是画图，是写出你认为它为什么这么做的理由， 然后用官方博客 / changelog 验证你的假设。
推荐拆解对象
写"不做清单"
频率：每次设计新功能面时
做法
- 先列出你能想到的所有功能（20-30 个）
- 砍到 5 个
- 对被砍掉的每一个，写一句话："不做它，因为 ___"
为什么有效：决定"不做什么"比决定"做什么"难得多，也重要得多。 这就是产品经理的核心动作——砍功能的过程会逼你思考优先级背后的逻辑。
示例：软件工厂的"不做清单"
不做实时协同编辑 — 因为用户是非技术人员，不会直接写代码
不做代码 diff 视图 — 因为用户看不懂 diff，只需要知道"改了什么功能"
不做 Git 分支可视化 — 因为用户不需要理解 Git 模型
30 分钟用户访谈
频率：每 2 周 1 次
做法
找一个目标用户（财务、法务、市场、产品经理），问 3 个问题：
- 现在怎么做？ —— 你现在怎么给技术团队提需求？流程是什么？
- 什么最烦？ —— 这个过程中什么最让你沮丧或浪费时间？
- 最怕什么？ —— 如果有个 AI 帮你做，你最怕它做错什么？
为什么有效：一次 30 分钟的真实访谈给你的决策依据，超过你自己想一周。 用户不会告诉你"该怎么设计"，但会告诉你"什么让他们痛苦"——痛苦就是你的优先级来源。
用户故事地图替代功能清单
频率：每次做信息架构时
做法
不要列"功能列表"，而是画一条用户旅程的时间线：
然后对每个阶段问自己两个问题：
- 这一步用户最需要看到什么？（决定主区域放什么）
- 这一步用户最怕看到什么？（决定要防止什么）
为什么有效：用户旅程会自然地告诉你界面上该放什么。每个阶段的"最需要"就是主区域内容， "最怕"就是你要通过设计来消除的焦虑。功能布局从用户旅程长出来，而不是从功能清单堆出来。
需要发生的心智模型转变
工程师视角
"这个功能能实现吗？怎么实现？"
产品经理视角
"这个功能该做吗？用户会用吗？"
工程师视角
"功能做完了就是好的"
产品经理视角
"用户用起来且不困惑才是好的"
工程师视角
"多一个功能 = 多一份价值"
产品经理视角
"多一个功能 = 多一份认知负担"
推荐资源（按优先级）
《Inspired》— Marty Cagan
B 端产品经理的圣经。重点看"产品发现"部分——如何通过用户研究找到该做什么。
Linear 博客 & Changelog
他们每篇更新都解释"为什么这么做"。是产品决策的活教材，特别适合 B 端工具类产品。
《Shape Up》— Basecamp（免费在线）
教你如何把模糊需求变成有边界的产品方案。特别是"Appetite"概念——先决定投入多少，再决定做多少。
《用户故事地图》— Jeff Patton
练习 4 的方法论来源。帮你从"用户旅程"视角组织功能，而不是从"技术模块"视角。
一句话总结
你的微观审美已经很好了。
缺的是"用户的痛 → 功能优先级 → 布局决策"这条链路的刻意训练。
多拆别人的产品、多砍自己的功能、多问真实用户，
比多看设计规范有用得多。