人机交互技术这门课的结课作业，很多同学看到“界面调研报告+快速原型设计”这个组合时，第一反应是“又要写文档又要做Demo，时间根本不够用”。我当时也有同样的焦虑，但真正做完一遍之后才发现，这门课的设计其实非常巧妙。它强行把你从“只会画界面”或“只会写文字”的单向思维里拽出来，逼着你在调研结论和设计方案之间来回穿梭。这篇博客，我不打算复述课程内容，而是想完整复盘一下我当时完成这套结课作业的全过程，包括怎么定调研命题、怎么拆竞品、怎么做可用性测试、怎么把结论转译成原型页面，以及中间踩过的那些坑。如果你也在做人机交互或者用户体验相关的课程项目、比赛作品，甚至只是工作中需要快速验证一个产品想法，这篇内容应该都能给你一些可以直接抄作业的思路。
先交代一下背景。我当时所在的某高校软件学院，这门课的结课作业分为两大块：第一块是界面调研报告，要求针对一个具体领域的产品界面进行系统性的调研和分析，产出结论性文档；第二块是快速原型设计，要求基于调研结论，用原型工具完成一套高保真或低保真的交互界面设计。两块的成绩占比相近，而且逻辑上是强关联的。这也就意味着，你不能随便找一个产品去调研，再随便做一个不相关的原型交差，你得让两份交付物像同一棵树上长出来的两个枝杈一样，彼此呼应。
我自己选的方向是“面向高校学生的在线学习平台”，调研对象包括几款主流的在线教育App和桌面端网站，原型设计则聚焦在“课程检索与选择”这条核心任务链上。这个选题比较稳妥，因为用户群体我太熟悉了，调研问卷和访谈招募都很方便，而且在原型阶段也更容易做出有说服力的细节。
1. 作业拆解：调研报告与快速原型并不是两件事
这门结课作业最容易犯的错误，是把调研报告和原型设计做成两个独立交付物。很多同学先花两周时间写报告，再花一周时间赶原型，结果原型与报告里的结论脱节，评审老师一问“为什么这里要这样设计”，答不上来。我后来复盘，正确的做法是先把它们当作一条完整的“调研—分析—设计—验证”链路来安排节奏。
1.1 课程作业真正考察的三个能力
表面上看，作业只要求一份报告和一个原型，但拆开来看，里面其实藏着三个层次的能力考察。
第一个是调研能力。你能不能把宽泛的研究方向收敛成一个明确可回答的问题，能不能设计出有效的调研维度，而不是把竞品的功能列表抄一遍。
第二个是分析与洞察能力。收集到的截图、访谈记录、问卷数据只是原料，你得从中提炼出真正有价值的规律，比如用户卡在哪个环节、哪些设计模式已经不符合当下的用户预期，这就要求你会看数据、会归纳。
第三个是设计表达能力。快速原型设计不是让你画高精度的视觉稿，而是让界面具备可点击的交互路径，让用户可以被测试，让方案可以被验证。所以原型不追求“好看”，它追求的是“信息结构清楚、交互逻辑成立”。
1.2 调研与原型如何串联推进
我当时的推进方式是这样的，先花3到4天做桌面调研和竞品初步拆解，把行业背景和产品现状摸清楚。紧接着立刻开始做用户访谈和问卷，把真实需求沉淀成几个关键设计机会点。然后再带着这些机会点去画低保真原型，借助纸面原型快速验证信息架构的方向。定了架构之后，再回头补全报告里的深度分析，让报告与原型互相咬合。最后才上工具去做高保真原型，并安排两轮快速可用性测试。
这样一个顺序的好处是，调研报告里的每一个结论都长在原型的基座上，而原型里的每一次设计取舍都能在报告里找到依据。我的报告里就专门有一个小节叫“设计机会点”，每一条都对应着原型里的一个具体页面或组件，老师和助教看到这种呼应关系，第一印象就会加分很多。
1.3 交付物清单与时间预估
在动手之前，我建议你先列一个交付物清单，别信“边做边想”。我们当时最终提交的东西包括三件：一份完整的界面调研报告（包含背景、竞品分析、用户研究、设计机会点、结论），一套可以在浏览器或客户端里点开的高保真原型，以及一次现场演示汇报用的原型演示脚本。
时间分配上，如果整个任务的周期是两周，我个人体验下来的比例大约是：选题与命题界定占10%，桌面调研与竞品拆解占20%，用户访谈与问卷占15%，数据分析与洞察提炼占20%，低保真原型与架构测试占15%，高保真原型实现占15%，汇报准备占5%。这个比例不一定适合所有人，但它能帮你避免陷入一个很常见的误区：在原型阶段反复抠视觉细节，导致调研部分的深度不足。
2. 界面调研报告：从命题选定到竞品拆解
调研报告的质量，七成取决于你一开始怎么定义问题。选题太大，比如“调研在线教育行业”，那你的报告只能变成一个泛泛的行业综述；选题太小，比如“调研某个App的某个Button”，又会让后续的原型设计没有腾挪空间。最好的命题是一个“中颗粒度”的任务：比如“高校学生在在线学习平台中查找并选择课程时遇到的交互问题”。
2.1 先锁定调研命题，别一上来就“全网对比”
我见过很多同学的做法是打开应用商店，下载十几个App，然后挨个截图、挨个写介绍，最后报告里堆了几十张截图，但没有任何结论。这就是典型的命题不清晰导致的失控。
命题锁定的作用是给你一条筛子。我当时确定的方向是“课程筛选与信息呈现”，之后的每一个动作都在为回答“现有平台在这条任务链上哪里做得好、哪里做得不好、为什么用户会产生认知负担”服务。竞品分析不用多，三到五个产品足够。我再补充一句，选定命题时最好顺便想清楚“我的原型最终要对标解决什么问题”，这样后续做原型时就不会迷失方向。
2.2 竞品选择的原则和数量控制
竞品不是越多越好，而是越有代表性越好。我当时选了五类产品：头部综合类在线学习平台、垂直领域的技能学习平台、以视频内容为主的公开课平台、一款知识社区型产品，以及一款在交互上口碑不错但规模不大的新锐产品。这五个产品的覆盖维度足够宽：技术形态涵盖App和Web，内容形态涵盖长视频、短视频和图文课程，用户群体也略有差异。
选竞品时我给自己定了两条原则。第一，必须有至少一款是“行业标杆”，用来建立基线认知；第二，必须有一款是“非典型产品”，比如知识社区型产品，干扰项越大，越容易发现有价值的设计差异。数量控制在5个以内，每个竞品不需要事无巨细地拆，盯住你命题相关的功能模块深挖就够了。
2.3 调研维度怎么设计才有信息量
调研维度是我认为整个报告里最体现功力的部分。建议不要只围绕“界面长什么样”来写，而要分层拆。我当时用了四个维度：
- 信息架构与导航模式：课程分类层级多深？底部导航有几个Tab？搜索入口是否容易被找到？
- 课程详情页的信息呈现：课程标题、讲师、时长、销量、评价等信息是怎么排序的？哪些信息被优先呈现？
- 筛选与排序机制：筛选项是否支持组合？排序逻辑是否透明？筛选结果有没有即时反馈？
- 交互反馈与状态设计：加载状态、空状态、错误状态、成功状态分别怎么表达？用户操作后系统如何响应？
这四个维度其实对应着用户在完成任务时的完整心理链路：先找入口，再理解页面，然后执行操作，最后获得反馈。用这套维度去拆每个竞品，你得到的就不再是一堆截图，而是可以横向对比的数据。
我当时还做了一个很笨但很有效的动作：把每个竞品的核心操作路径录屏，然后逐帧去抠时延和点击层级。举个具体的例子，在某个头部App里，从首页到“找到一门Java课程并查看详情页”，用户需要经过五个层级；另一个新锐产品只需要三个层级。这种量化对比写进报告里，说服力远大于“我觉得这个App层级太深”。
3. 把调研结果讲清楚：报告结构与洞察提炼
有了素材之后，下一个难题是组织。一份好的界面调研报告，结构上一定有一条清晰的叙事线。我的建议是采用“背景与问题→竞品桌面调研→用户深访与问卷→设计机会点→设计建议”的五段式结构。这条线的逻辑是递进的，每一章都在回答上一章留下的疑问。
3.1 报告叙事线：问题→现象→原因→机会
我当时是这么贯穿报告主线的：先讲清楚为什么选在线学习平台这个领域，然后抛出核心问题——高校用户在选择课程时，普遍存在“信息过载”和“决策困难”。接下来，用竞品分析和用户研究去论证这个问题到底出在界面信息的哪些环节。最后，把问题收敛成3至5条设计机会点，全部引导到原型阶段。
这条线的价值在于，它让读者（老师、助教、甚至你自己）始终知道“我为什么要读这一章”。报告最怕的就是每一章都自成一体，章与章之间没有承接关系。我当时把“用户访谈的典型语录”直接嵌在分析文字旁边，比如有一位受访者说“我翻了五分钟都找不到适合零基础的Python课”，这句话出现在调研发现里，和出现在分析结论里，效果完全不同。
3.2 用对比表和截图说话，而不是贴满屏截图
我见过很多调研报告，里面全是密密麻麻的截图，甚至一个页面截了四五张状态图，看得人头晕。正确的做法是每个竞品只留一张最能说明问题的页面截图，剩下的信息交给对比表格。
举个例子，我当时做了一张“筛选功能支持能力”的对比表，横向是五个竞品，纵向是“按难度筛选、按时长筛选、按更新时间筛选、多条件组合、筛选结果显示数量”这几个项，用对勾和叉来标记。这张表的信息密度极高，读者一眼就能看出谁做得好、谁做得差。类似的表我还做了“导航层级深度对比”“课程卡片信息要素对比”，都成了报告里最核心的视觉锚点。
另外，截图的排版也有讲究，所有图片保持一致性，不要一会儿全屏截图一会儿局部截图；截图中涉及用户个人信息的部分要打码，这是最基本的职业素养。
3.3 从“描述现象”升级到“给出洞察”
优秀调研报告和平庸调研报告最大的分界线，就在这里。描述现象是“某App的筛选器有6个筛选项”，而给出洞察是“该App虽然提供了大量筛选项，但用户反馈‘不知道筛选后的结果靠不靠谱’，这表明系统缺少筛选结果的可信度提示”。你看，一句话的差别，前者是信息，后者是洞察。
为了产出洞察，我每次分析完一个调研维度后，都会强迫自己写一张“发现—影响—建议”的小卡片。发现是客观描述，影响是它给用户带来的正负向效果，建议是面向原型设计的改动方向。这三栏填完，报告里的设计机会点自然就出来了。这个方法你也可以直接用，我强烈推荐。
4. 快速原型设计：工具选型与流程推进
快速原型设计这块，很多同学最大的纠结是“用什么工具、做多细”。我的态度很明确：先想清楚你要用原型验证什么，再决定工具和保真度。工具永远是服务于验证目标的。
4.1 工具选型：不同选择背后的理由
市面上常见的快速原型工具，大致可分为几类。浏览器端在线工具适合多人协作和频繁改稿，桌面端专业工具适合复杂的交互动效，中文语境下的轻量工具则在组件库和模板方面对国内设计范式更友好。
我当时的选择是先用纸笔和卡片做低保真测试，然后使用一款在线协作设计工具完成高保真原型。选择它有几个原因：一是浏览器打开就能用，老师演示的时候不用装任何环境；二是组件库丰富，课程卡片、标签、按钮这些高频组件不需要从零画；三是它的原型连线功能足够直观，我可以快速定义跳转关系。如果你做的是偏B端或者数据密集型界面，桌面端工具会更顺手；如果你聚焦的是移动端App界面，在线协作工具配合内置的移动设备模板，效率也相当可观。
4.2 从低保真原型到高保真原型的路径
不要一上来就打开设计工具画高保真。我的习惯是先用纸面原型，把每个页面的信息区块用方框占位画出来，然后自己扮演用户，沿着核心任务走一遍流程。这一步看似费时间，其实能省你后面大量返工时间。因为信息架构的问题在纸面上发现和修改的成本极低，但到了高保真阶段，改一个导航逻辑可能意味着重新排三个页面。
我在低保真阶段做过一个小实验，把课程搜索结果的排序逻辑画成两个版本：版本A按默认的“综合推荐”排序，版本B允许用户一眼看到“筛选条件已生效”的提示。拿给周围同学看，十个人里有七个会困惑于版本A的排序逻辑。这就是低保真测试带来的信息。如果直接闷头做高保真，这种问题要到可用性测试阶段才会暴露。
低保真测试通过之后，再进入高保真阶段。高保真原型不是“把界面画好看”，而是要涵盖完整的正向流程和部分异常流程。拿我的例子来说，正向流程包括首页→搜索/分类→课程列表→筛选操作→课程详情→加入学习计划；异常流程至少包括“无搜索结果”“筛选结果为空”“网络加载失败”这三个状态。很多新手原型的致命伤就是只有“happy path”，老师一点到一个死路，立刻露怯。
4.3 原型设计中的组件与规范意识
做高保真原型，哪怕是课程作业，也应该有一点设计规范的意识。我不要求你输出一整套设计系统，但至少要统一字体层级、主色、间距和圆角规则。比如我规定主色为品牌蓝、功能色为成功绿和警告橙、页面左右边距统一为16px、卡片圆角统一为12px。这些基础约束能让原型看起来像一个团队的产品，而不是七拼八凑的散装页面。
组件复用是另一个效率杠杆。在在线协作设计工具里，我把“课程卡片”“标签组件”“底部导航栏”“搜索框”都做成了可复用组件。后面搭建二十多个页面时，拖拽即可，不用每个页面重新画。我帮同学改原型时发现，他们之所以在高保真阶段熬夜，不是因为画不快，而是因为同样的卡片画了十几遍，每遍还都不一样。组件化一次性解决这个问题。
注意：组件里任何一处修改都会自动同步到所有引用它的页面，所以组件命名一定要规范。我当时吃过亏，把“课程卡片”和“课程卡片_带折扣”建成了两个组件，后面改样式时要改两遍，纯属自找麻烦。
5. 需求转译：把调研结论变成界面方案
这是从报告到原型的临门一脚，也是最难的一步。调研报告里写的是“问题”，原型里呈现的必须是“方案”。许多人卡在“我知道问题在哪，但不知道改成什么样”。
5.1 需求转译的三层工作
我自己的拆解是，需求转译至少包含三个层面。
第一个层面是任务流程的转译。报告里说“用户找课路径太长”，那原型里就要明确“新用户首选路径要不要从四个Tab精简为三个Tab”“首页是否应该直接展示课程分类入口”。
第二个层面是信息架构的转译。报告里说“课程卡片信息层级混乱”，那原型里就要决定课程卡片上哪条信息要加粗变大、哪条信息要弱化甚至隐藏、哪些信息需要在封面图上直接标注。
第三个层面是交互表达的转译。报告里说“筛选后缺乏反馈”，那原型里就要在筛选栏上方增加一个“已选条件”胶囊区域，并且允许用户一键清空。每一个调研问题，都应该能在原型里找到一个对应的设计回应。
5.2 一个案例：在线学习平台的信息架构调整
举一个我当时具体落到原型里的案例。调研发现，五个竞品中，有四款把“课程分类”放进了第一层级，但用户访谈里却有近半数受访者表示“我其实更想知道今天有哪些热门课程”“我想看看大家都在学什么”。这个矛盾说明用户的核心动机是“发现好课”，而不是“按分类找课”。
所以我在原型的信息架构里做了调整：首页顶部保留搜索框，中部的金刚区放“热门课程”和“限时优惠”，而不是把分类铺满首屏。分类入口被降级为第二层级的Tab。这个调整直接来自报告中的“发现—影响—建议”卡片，让我在汇报时能有理有据地讲清楚每一个设计决定，而不是凭感觉拍脑袋。
5.3 原型评审时的检查清单
高保真原型做完之后，先别急着提交或测试，自己先走一遍检查清单：
- 核心任务是否能三步以内从首页到达？
- 每个按钮是否都有对应的页面或交互反馈？
- 筛选、搜索、排序这三个高频操作是否都被完整实现？
- 页面是否包含了加载、空、错误三种状态？
- 返回路径是否清晰？用户误触后能否及时恢复？
- 不同页面之间的信息层级是否一致？组件样式是否统一？
这份清单我每次做完原型都会打印出来逐条过一遍。别嫌琐碎，评审时最容易翻车的点，全都藏在这六条里。
6. 用户测试与快速迭代：让原型真正“可验证”
快速原型的生命力在于“可以被测试”。我强烈建议，你在结课作业阶段至少安排一次快速可用性测试，这个过程本身就是加分项，因为你可以在报告里写“我们对原型进行了一轮可用性测试，发现并解决了若干问题”，这是实打实的闭环。
6.1 5人测试法与任务脚本设计
不需要大样本。尼尔森的实验早就说过，5个用户就能发现大约85%的可用性问题。我当时找了5名同学作为测试者，尽量找不同专业背景的人，避免都是“懂设计”的人自嗨。
测试的核心是任务脚本设计。任务不能太宽泛，比如“随便看看首页”，这测不出问题；任务也不能是操作步骤的复述，比如“点击搜索框输入Python”，这是侮辱用户智商。我当时设计了三个任务：分别是“找一门零基础可学的摄影课程并加入学习计划”“筛选出价格低于100元且时长在1小时内的课程”“收藏一门课并在个人中心找到它”。每个任务后面我都让用户口述他们的预期操作，这比直接看他们点击行为更能反映心智模型。
6.2 观察什么、记录什么
测试时别急着解释设计意图，让用户“先说再做”。我观察的重点有这几个：用户在哪个页面停留时间超过5秒（信息不理解）、用户在哪个位置反复点击无效区域（交互预期错位）、用户操作到第几步开始犹豫（流程中断）、以及用户完成任务后能否准确说出自己刚刚的操作路径（心智模型是否清晰）。
我习惯用一张简单的表格记录：任务编号、用户行为描述、问题严重程度（高/中/低）、对应页面位置。每轮测试结束后，把所有问题汇总成一张便利贴或表格，再去做优先级排序。
6.3 迭代优先级：不要所有问题都改
可用性测试之后，问题清单可能很长，但你要学会取舍。高频且让用户完全卡住的问题，必须立刻改；低频但能明显提升体验的问题，可以改；纯视觉偏好类的问题，记录下来但别被ta带偏。
我那次测试中暴露的典型问题有两个：一个是筛选面板中的“综合排序”选项表述含糊，两个测试用户都以为它是“好评优先”；另一个是课程卡片的“加入学习计划”按钮太小，连续三个测试者都误点了卡片本身。这两个问题都属于高优先级，我在高保真原型里立刻调整了文案和按钮热区。剩下的一些字体大小、颜色偏好类的问题，我选择保留自己的设计方案。
注意：可用性测试最怕听到用户说“我觉得这里不太好看”，这没有价值。一定要引导用户说出“我认为这个按钮点了应该做什么”，任务导向才能暴露真实的交互问题。
7. 常见问题与避坑经验
做这套结课作业的过程中，我自己踩过不少坑，也帮同学救过火。下面这些经验，属于常规课程指导里不会写的部分。
7.1 调研报告写成“功能说明书”怎么办
这是最普遍的问题。我见过一份报告，把五个竞品的功能列表分别写了一遍，不仅长，而且无趣。如果你发现自己写着写着变成了“这个App有直播功能、有讨论区、有作业系统”，赶紧停下来。
急救方法只有一个：强制自己把每一段“功能描述”改写成“用户场景描述”。比如“该App有直播功能”改成“用户进入直播间后，可以看到讲师的操作窗口实时变化，但评论区与视频区的联动较弱，刷屏时容易错过关键提示”。功能本身没有意义，用户在这个功能里的体验才有意义。
7.2 原型太“死”、交互不连续怎么办
有些同学的原型做得像PPT，页面之间没有任何连接，评审点起来毫无反应。这通常是两个原因造成的：一是只画了状态页面，没有画中间跳转逻辑；二是按钮没有建立交互连线。
解决方法是先划定“核心流程闭环”，比如“首页→列表→详情→加入课程→查看个人计划→返回首页”，只维护这一条闭环里的所有交互连线。其他不重要的页面可以暂时不连线，保证评委走到哪都能点回主赛道。同时，给所有按钮加上悬停或按压的微交互，视觉上就会有“这是个活体”的感觉。
7.3 时间失控、团队协作出问题怎么办
如果你是一个人完成这份作业，最大的风险是前期调研投入过多，导致后期原型时间不够。我的经验是给每个阶段设一个“硬截止点”，比如第4天必须开始写“设计机会点”，第7天必须完成低保真原型，时间一到，无论当前内容是否完美，都要推到下一个阶段。
如果是团队协作，更要注意在线协作工具里的版本管理。我见过一个小组，两个人同时修改同一个文件，最后互相覆盖，白白浪费了两天。建议分工时按“调研维度”或“原型页面模块”切分，而不是按“设计”“写文档”切分，保持每个成员独立交付。同时约定，每天结束前合并一次版本，命名规范清晰。
7.4 汇报前的备份与演示检查
汇报当天最崩溃的情况，是登录不上在线工具、原型链接失效、字体在你电脑里正常但在教室电脑里乱掉。我一般会做三手准备：在线原型链接存一份，导出的离线文件存一份，核心页面截图存一份放PPT里。三份至少能支撑两种不同的演示路径。
还有一个容易被忽视的细节：汇报现场的浏览器缩放比例。很多原型工具在小比例下会挤压变形，提前到教室打开原型，把浏览器缩放到适合演示的比例，不要等到老师走到屏幕面前了才发现界面挤成一团。
8. 结课汇报时怎么讲才不白做
原型和报告做完只是第一步，汇报才是把两个月（或两周）的工作量浓缩呈现的关键。很多同学汇报时只会念PPT，把报告里的定义念一遍，把原型页面过一遍，老师听完完全没有记忆点。会讲的人，会把一次汇报讲成一个“发现问题、分析问题、解决问题”的故事。
8.1 讲决策过程，而不是念PPT
我汇报时有一条主线：我们调研发现用户在选择课程时会经历“信息过载”，然后我说清楚哪些证据支撑了这个判断（竞品对比表、用户语录、问卷数据），接着讲我基于这个判断给出的设计回应是什么。你不应该让评委自己从原型里去寻找你的思考，而是直接告诉他“我为什么这样做”。
准备稿子的时候可以用“因为…所以…”来检查每一页PPT，比如“因为竞品A的课程卡片信息层级平均超过5项，所以我在设计时把卡片信息收敛为3项核心信息+2项可展开信息”。完整的“因为所以”结构，会让整个汇报拥有清晰的逻辑链条。
8.2 用测试数据支撑设计
如果时间允许，至少在汇报里放一张“可用性测试前后对比”的数据表。我当时记录的是：第一轮测试中，5位用户平均完成任务用时为2分30秒，且有一位用户无法完成“筛选并加入课程”的任务；迭代后第二轮测试，平均用时缩短到1分40秒，所有用户都能完成任务。不需要复杂的统计，这些数字足以让评委看到“你的设计被验证过”。
汇报时要把测试的局限性也说清楚：样本量小、测试环境不严格、被试者主要是本校学生。主动承认局限性，比等评委来质疑要体面得多。
8.3 应对提问的几个常见思路
这个改到原型里的具体方案是：首页第一屏改为信息流卡片，同时保留顶部的分类入口作为次级导航。所谓的新用户引导成本高，但我们也可以通过首次打开时的偏好选择来兼顾两类人群。这里的问题并非技术瓶颈，而是需要权衡引导成本与长期信息匹配效率的取舍，所以我同时保留了一种快速的分类筛选路径，保证找特定课的用户不会绕路。课程卡片信息确实较多，但我们区分了"核心信息"与"扩展信息"。我需要明确这里的边界条件——价格、时长、难度系数属于决策必需的核心信息，直接展示；而评价数量、授课人简介出现在了二级页面里，不占据主信息位。方案复杂度部分是刻意为之：因为要完整覆盖从"首次访问、浏览热搜话题、进入讨论区、发帖、取关"这条由深访高活跃用户的完整路径，页面数量自然多一些。我也强调最初的低保真原型只申请了7个页面，后来逐步展开到31个High-fi页面主要为了完整演示。控时技巧很简单：每个环节只讲一个亮点案例，剩下用一句"其余设计请见报告第X章"带过。
提示：汇报被问住了，不要慌。最专业的回应是"这个问题我们在测试中也注意到了，我的判断是……，后续可以从……方向继续验证"。你不需要在每个问题上都给出完美答案，但你要让评委看到你具备对设计决策进行思考和迭代的能力。
写在最后：我对这门课的几点体会
整个结课作业做下来，我最深的感受是，人机交互技术这门课真正有价值的不是让你背出几个可用性准则或尼尔森原则，而是逼着你完整走了一遍"从观察用户到验证方案"的闭环。
在动手之前，我以为界面调研报告是用来应付评审的文档，快速原型设计是为了展示界面设计能力的Demo，它们之间没有太多关系。做完之后我才明白，调研报告的作用是为原型提供上游决策的依据，而原型则是调研报告里那些抽象洞察的实体化和可执行化。当你能够指着原型里的一个交互细节，说出"这是基于调研中某某用户的反馈而调整的"，你就已经跳出了"画界面"的层次，开始真正理解"做设计"的含义。
如果让我重新做一次，有两点我会做得更好：一是在用户访谈阶段多追问"为什么"，不要停留在用户表面的行为描述；二是低保真阶段的测试多邀几个人参与，早期多发现问题，后期压力会小很多。最后再分享一个小技巧：在报告封面上写一句话概括整个项目的核心论点，比如我当时写的是"从信息过载到高效决策：面向高校用户的课程选择交互优化研究"，这句话既是报告的题眼，也是汇报的开场白，亲测能让你收尾时更聚焦。
