声明：本文章由本人的口述转文本后经由AI总结和人工修改编写而成。仅代表本人一些非常浅薄的思考，欢迎大家在评论区指正。
引言：为什么“逻辑清晰”这么重要？
最近经历了毕业设计的中期答辩后，看到同学们的汇报以及老师们的评价，我想到有次组织会议，mentor夸我组织的会议“逻辑清楚，条理清晰”。结合最近的经历，我突然感觉这句话不仅是开会技巧，更是设计和解决问题的基础。无论是做毕业设计还是工作项目，缺乏逻辑的设计就像空中楼阁，经不起推敲。以下从毕设反思、方法总结、实际案例三个角度，分享我的思考，也作为我这一个月实习的阶段性总结。
一、毕设教训：设计不能想当然，一定要有客观的东西支撑。
最近经历的毕设中期答辩中，很多同学的选题因脱离实际被老师否定，比如：
“宠物社会化”案例
-
- 问题 ：作者认为宠物需要像人类一样“社会化”，但未说明为什么需要这样做。
- 设计缺陷 ：方案略显随意，未经推敲，没有展示其能够让宠物再度社会化的能力，即如何让宠物接触户外环境，反而显得把宠物关在封闭的笼子里。
- 老师质疑 ：宠物的社会化是伪命题吗？作者是否以人类视角强行赋予宠物需求？产品是否真实有效。
“适老化设计”案例
-
- 老师评价 ：适老化设计应聚焦“如何让老人用有限能力完成事情”，而不是不切实际地追求“康复”——对本科生来说，康复方案太复杂，缺乏足够的资源去做一个长期的实验确认康复是否有效。
二、设计方法：从发现问题到解决问题的逻辑
立项前的三个关键问题
-
- 问题真实存在吗？
用数据或调研确认。例如我的毕设中，60%骑行者存在运动疼痛，且疼痛是受伤前兆，这确保了我的这个缓解骑行过度使用损伤这一个需求是真实存在的。 - 问题严重到需要解决吗？
即需求的强度。比如疼痛可能导致肌肉损伤，这会导致用户骑行体验下降，甚至因为伤病无法继续骑行。 - 问题影响多少人？
即需求的频次。例如“60%用户”“每周发生3次”，数据越具体，方案越可信。
- 问题真实存在吗？
通过确定需求的强度和频次，我们能够分析出哪些需求是值得被处理的。哪些需求应该是优先去做的？哪些需求可以往后放放等等。
方案需要经过验证再释放
核心原则 ：任何方案在确认前，必须通过实测或数据验证其可行性。
案例：自行车疲劳监测项目
-
- 验证需求 ：
我设计了一个装有压力传感器的座包原型，通过采集骑行者肩部压力数据，验证“压力波动”是否能反映运动不协调程度。 - 结果 ：
用户在一段时间骑行后，认为自己疲劳时，发现压力传感器数据的标准差存在明显的增加。进而做出推断，用户在疲劳时，压力传感器的数值的波动性会增加，反应在标准差的增加上。 - 启示 ：
方案必须通过实际测试，而非仅凭假设推导。这样才能够给出一个明确可以解决问题的方案。因为在汇报或者演示时，很多创新性很强的方案都会显得非常的不切实际，只有实际给出来实测的数据，所有人都才能够表示认同，才能够获得到相应的支持或者利益。
- 验证需求 ：
三、行事方法论：明确目标与计划
核心原则 ：在调研或实验前，必须明确：
-
- 要收集哪些数据
如阴天下太阳能板的发电效率、用户疲劳时的压力传感器读数； - 如何处理数据
如用数学公式计算电池容量，用标准差分析数据的波动程度； - 数据如何影响决策
如阴天发电量决定电池冗余大小和太阳能板峰值功率大小，疲劳时波动程度是否增加对应着方案是否可行。
- 要收集哪些数据
在调研过程中如果发现了任何的模糊，也不能够忽略，而是应该立刻去思考如何获得相关的数据来澄清这一些模糊。同时需要尽可能的采取一些相对工程的手段或者数学的手段来处理我们现在的这些数据，以获得一个客观的结果。
案例：太阳能电池项目
-
- 数据需求 ：
德国地区每个月会频繁经历长期的（14天到20天）阴天，导致太阳能板无法以峰值功率发电，这时必须知道德国的气候条件下阴天时太阳能板的发电效率（如“阴天发电量为最大发电量的10%”），进而留出冗余，让我们的产品能够达成用户的需求，保障在阴天时负载也可以与正常运作。
同时面向的目标市场中也包括美国。美国的气候条件和德国不一样。进而会导致用户希望负载需要再阴天运行的天数的不同。需要明确两地的气候的区别并给出一个合理的解决方案。 - 数据处理 ：
通过公式计算电池最大容量和太阳能板的最大功率：
阴天中运行所需要的总能量 = 电池能够给出的所有的能量 + 阴天天数 × 太阳能板在当地气候条件下的发电功率 - 决策影响 ：若数据不准确，可能导致电池容量过大（成本高）或过小（设备无法运转，无法满足用户需求），也可能导致太阳能板的峰值功率过高或过小。
- 启示 ：数据收集需精准，处理逻辑需清晰，否则方案会因基础错误而导致产品开发的困难和问题，如导致成本过高等。
- 数据需求 ：
四、职场实践：逻辑思维的延伸
团队协作的核心：设置时限，明确沟通
-
- 别让需求反复改
例如说明书设计，需和有关方面，如供应商，其他产品经理，上级等确认细节后一次性同步，并设置deadline，明确告知我们是最后一次修改需求，避免后续频繁调整耽误工期。 - 案例：包装设计延误
美国供应商拖延回复时，邮件里直接写：“请于X月X日前提供【具体信息】，否则我们无法制作包装。”，通过设置deadline能确保我们的项目有序的开展。
- 别让需求反复改
对用户旅程，利益相关者的全面的思考
案例：官网工具的链接
-
- 对链接位置的思考
- 该工具已经开发完毕，需要将该工具在官网的某个部位进行露出，让用户使用我们的工具。
- 从用户旅程出发，用户会在购买产品之前使用该工具来确定自己需要购买多少个这样的产品，进而将该链接置于产品的购买页面上。
- 用户会在疑惑自己需要购买多少个工具的时候使用该工具，因此将该链接布置于确定数量的复选框周围形成一个联想暗示用户这个工具可以帮助你确定数量，从而将该工具的链接放置在确定购买数量的复选框的上方，在用户疑惑自己需要多少个该设备时进行一个露出。
- 同时，文案需要与用户共情，通过设置某种反问句。来让用户发现自己确实并没有想到或者自己确实正在困惑“我到底应该买几个”，进而让用户更多的点进去使用该工具来确定自己需要购买几个。
- 开发需要对接的人员
- 该工具并非我们内部的开发，而是交给公司内部其他团队进行开发。在此过程中，需要明确我们到底需要和谁去对接。在本例中，我们需要给官网产品经理，官网程序员以及APP程序员进行对接。来保障我们的这个需求有能力被落实，并且能够切实地被落实到所有需要该入口出现的地方。
- 对链接位置的思考
积极交流，发现盲点
核心原则 ：主动与他人交流，用外部视角发现自身忽略的问题 。
案例：毕设中的“疲劳定义”争议
-
- 问题发现 ：答辩时老师指出，我未明确“疲劳”的定义，也未考虑用户“故意晃动身体”导致数据波动的情况。
- 交流价值 ：
- 客观视角 ：老师虽无产品经验，但能从用户场景出发，指出一些边界问题和逻辑漏洞（如“疲劳的具体生理表现，用户的随意行为是否会对当前疲劳的判断方法的结果产生影响”）。
- 启示 ：
- 设计全流程需与导师、同事反复沟通需求，避免“想当然”；
- 项目进展中定期汇报，利用旁观者视角及时发现被忽略的细节。
四、总结：逻辑思维的核心原则与实践
从问题到方案的闭环逻辑
核心原则 ：用数据支撑需求真实性和方案可行性。
-
- 问题验证 ：通过调研或实验确认问题存在（如60%骑行者存在疼痛问题）。
- 方案验证 ：通过实测验证解决方案的假设（如压力传感器数据波动与疲劳相关）。
从规划到决策的系统思维
核心原则 ：提前规划数据需求、处理方式及决策逻辑。
-
- 数据需求 ：明确关键参数（如阴天发电效率、用户疲劳阈值）。
- 数据处理 ：用数学公式或统计方法处理数据并分析（如通过标准差反映用户运动的不协调成都，进而判断疲劳程度、通过数学公式计算电池容量）。
- 案例 ：
- 太阳能项目 ：通过公式 阴天总能量需求 = 电池容量 + 阴天天数 × 阴天发电功率，确定重要的参数，以指导选型，进而平衡成本与性能。
外部视角：通过交流填补盲区
核心原则 ：主动沟通，用他人视角发现自身忽略的问题。
-
- 设计阶段 ：与导师/同事核对需求，寻找不够明确的地方（如“疲劳定义是否明确”）。
- 执行阶段 ：定期向同僚，上级等有关方面交流进展，避免忽略边界问题（如用户晃动背包导致数据误判）。
团队协作：明确沟通与责任边界
核心原则 ：设定清晰的规则与截止时间，减少反复修改。
-
- 需求确认 ：与多方（供应商、开发团队）同步细节后，一次性释放需求并设截止时间。
- 责任划分 ：明确对接人（如官网产品经理、程序员），确保需求落地。
- 案例 ：
- 包装设计 ：邮件明确告知供应商“X月X日前提供信息，否则无法制作包装”。
- 官网工具开发 ：与同部门和开发团队确认需求可行且合理后不再调整，一次性释放需求，避免后续反复调整。
用户视角：从共情到落地的细节设计
核心原则 ：通过用户旅程分析与用户共鸣，进而设计产品满足用户需求
-
- 案例：官网工具入口
- 通过用户旅程分析，将工具链接置于购买页面复选框旁，利用“反问文案”引导用户点击。
- 案例：官网工具入口
