1.1-产品设计

Create by fall on 10 May 2022
Recently revised in 29 Aug 2025

产品构建

• 首先定义价值主张，然后围绕着价值来设计商业模式画布。
• 用户画像：完成画布以后，我们把画布里的「客户细分」部分拿出来，做成「用户画像」。这是一个将细分客户具体化、变得有血有肉的工具。
• 应用场景：有了画像，再据此还原用户使用产品的各个场景，他们是用电脑还是用手机、是在家里还是在车上使用等等。
• 功能列表：想象为了在上述场景下向用户传递价值，我们需要什么样的功能，这样就会得到一个功能列表。
• 优先级：功能列表会很长，不同功能的优先级也不同。所以我们会对功能进行分期，其中最重要也是最靠前的一个功能分期，就是用来开发「最小可行产品」的分期。
• 可行性分析：当「最小可行产品」开发完成后，进行「产品市场契合」的验证，如果达不到设定的验证目标，就需要调整功能，甚至重新设计价值主张。
• 市场验证：当通过「产品市场契合」后，我们就可以按照分期迭代开发产品的其他功能了。
• 应用迭代：在迭代过程中，我们会持续对新上线的部分功能进行增长优化，保证每一部分功能达到预定的目标。

设计准则

完美不在于无以复加，而在于无可删减。

产品设计

设计价值

• 交互设计，有用，贴心

  • 关心用户喜好：记住我们的习惯和偏好
  • 具有常识：将相似的功能分类，将经常使用的控件放在一起
  • 判断力：在陌生的电脑或地址登录时，及时告知用户。
  • 预见需求：在用户复制某个网址后，会弹出是否直接打开网址的选项。
  • 尽责：当用户重复命名文件时给予提醒，出现问题告知用户解决方案。

• 目的明确（帮助用户）

  • 不问过多的问题
  • 即使出现失误，也能帮用户解决：知乎会自动保存你输入的内容，即使由于软件崩溃意外退出，也不用担心。
  • 帮助用户避免犯低级错误（误操作，删除所有内容）

• 技术可行，顺应用户的思路

  • 不要用对话框（交互）来报告常态内容。
  • 提供选择，而不是提出问题（让用户选择，而不是询问）。

响应时间

0.1 秒以内完成，用户认为系统的响应是即刻的；

1 秒左右完成，用户认为系统是有响应的；

10 秒以内，用户很清楚地注意到系统变慢了，这时提供一个进程条很关键；

10 秒以后，用户的注意力不再集中于程序，这时进程最好在线下或后台执行，要向用户明确交待状态和进度，向用户提供剩余时间，取消机制。

语言的表述

更简洁

• 错误示范：为了让你了解关于我们的更多内容，我们提供了更多链接可以点击。
• 正确示范：点击链接，了解更多内容。

使用用户熟悉的语言

错误示范：资金流出成功

正确示范：支付成功

表述一致

修改次数；更改次数；用户修改次数；用户编辑次数；数据改编次数，这些用语需要进行统一

重要信息的位置突出

第一眼就要把用户最需要的数据展现出来。

完整直接地提供用户信息

我们希望用户进行操作时，要给出对应的理由，考虑到用户的感受，引导用户完成操作

错误示范：请设置您的密码

正确示范：为了账号安全，请设置密码

错误示范：抱歉，无法响应

正确示范：抱歉，无法响应，请刷新重试

用词不要有歧义

错误示范：卡号

正确示范：银行卡号

不要使用绝对的词语

错误示范：我们绝对不会透露你任何信息

正确示范：我们会保障您的信息

产品场景

可视化场景

时间类：折线图，折线区域图

展现随时间变化

比较类：柱状图，气泡图，比较数据之间的差异

占比类：饼图，环形图，百分比堆叠图

低代码

对于大多数低代码来说，痛点都是一样的，一遍降低代码的编写，一边要实现某些联动的功能，导致生成一堆代码，然而直接写这些代码可能更快。低代码本身还需要约束固定的场景才能使用。 或者说，低下来的代码本身就不需要更改什么内容。 而最比较成功的低代码方式，就是基于工具的低代码化，工具化。例如：将 git 工具图形化的工具，这些工具都有一个特点可以穷举，虽然有很多可以输入不同的内容，但是输入的属性可以穷举。

因此低代码不是银弹（可以解决一切问题的事物）

Only a shit solve absolute.