这个校园短视频项目，是我四月份求职时做的笔试题。当时要求设计一款面向校园的短视频软件，面试通知迟迟没来，状态一直停留在“用人部门复筛”。虽然后来拿到了另一家互联网公司的产品实习offer，但我始终对这个项目念念不忘。几个月后重新审视，发现当时犯了不少低级错误，记录下来希望能给大家一些参考。

先简单介绍一下项目的基本架构。我设计了一款校园短视频软件，包含五个一级tab：直播、发现、主页、消息和个人中心。功能模块该有的都有——直播、短视频信息流、拍摄发布、社交互动。页面截图就不放了，感兴趣的朋友可以自己想象。



接下来详细说说当时的问题。

第一个问题是功能堆砌。设计产品时，我参考了抖音、微博、微信，把这些平台的核心功能都想搬进产品里。直播、信息流、话题、社交、拍摄……一个不落。表面上功能齐全，实际上毫无特色，产品做得臃肿不堪。开发周期被拉得很长，很可能错过上线最佳窗口。这完全违背了MVP原则——只保留核心功能，追求小而精而非大而全。

第二个问题是脱离用户需求。设计之初我根本没有从用户需求出发，而是凭直觉判断“校园短视频应该有什么功能”。作为大学生，我自认为很了解校园用户，但这种盲目自信害了我。没有深入研究目标用户的真实使用场景，没有挖掘核心痛点，做出来的功能只能是自嗨。实际上，对于校园短视频，用户最根本的需求是通过平台了解校园动态、获取相关信息，这个核心点没抓住，附加再多功能也是白搭。



第三个问题是忽视场景匹配。有些需求看起来合理，但实际使用场景中很少触发。比如直播功能，我把它做成了独立模块，但校园里需要直播的场景非常有限——偶尔的课程分享、晚会转播，仅此而已。大多数时候用户只是刷短视频，单独做个直播tab没有必要，完全可以整合进短视频模块里。判断需求真假，要看用户是否真的会在特定场景下触发。

第四个问题是导航结构混乱。主页tab有没有必要？各个tab之间的关系是什么？顺序怎么排列？这些基础问题我当时完全没有思考。现在回头看，导航逻辑确实混乱。用户是非常懒的，tab的名称和位置必须直观易懂，不同tab之间应该保持独立无交集。我后来反思，主页tab确实多余，完全可以简化为一个拍摄入口。



第五个问题是使用流程不友好。关键功能的操作路径必须简单再简单。但在我的产品里，拍摄视频这个核心功能，路径设计得相当隐蔽，二次查看时我自己都找不到入口。产品设计完成后，找真实用户做可用性测试非常重要，自己想当然很容易出问题。

最后一个问题是产品调性模糊。设计产品时要明确产品的定位和气质——是内敛还是开放，是陌生人社交还是熟人关系，是校园专属还是泛娱乐平台。这些问题在设计初期就要想清楚，不然功能架构就是无根之木。功能列表列出来很简单，但每个功能是否有存在的意义，是否符合产品调性，才是关键。

这几个月的沉淀让我意识到，产品设计能力确实提升了不少，但更重要的是思维方式发生了变化——从“我想做什么”变成了“用户需要什么”。这可能是这次复盘最大的收获。