月理 - Case Study

1. 背景与问题发现

毕业后，我在整理自己的日常生活时，发现一个现象：市面上的个人管理工具，从 Notion 到 TickTick，几乎都围绕着效率和生产力构建。它们以天为单位，强调截止日期、完成率，带着一种“你必须完成任务”的紧迫感。

但我的生活里，大量快乐来自阅读、玩游戏、看剧、学一些感兴趣的知识——这些活动不是“任务”，它们是生活的趣味所在。我试过用效率工具来记录这些，但每次打开都感到压力：红色的未完成标记、每天的通知提醒，让我觉得在被管理，而不是在享受记录的过程。

这让我开始思考：为什么记录个人兴趣生活，就一定要像工作一样严肃？

我和 8 位有类似记录习惯的朋友聊了聊，发现：

很多人会用碎片化工具记录——备忘录、Excel、豆瓣的“想看/看过”功能，但这些工具彼此割裂，无法形成整体回顾。
“月”是自然的思考单位——月初大家会想“这个月打算玩什么”，月末会感叹“这个月看了好多剧”。没有人以天来规划休闲活动。
对年度回顾有需求，但没工具满足——大家期待年底能看到一个热力图或统计卡片，但现有工具要么没有，要么藏在复杂功能里。

产品的机会就藏在这个空白地带：介于“什么都不记”和“用生产力工具严格管理”之间，一款为兴趣生活设计的轻量记录与回顾工具。

2. 从“不做什么”开始定义产品

在动手设计之前，我做的第一件事不是画原型，而是明确产品的边界。我写下了几条核心设计原则：

产品应该帮助用户享受生活，而不是制造压力。 这意味着：不对过去未完成的计划弹窗催促、不根据完成率给用户“打分”、不强制每日打卡。

数据属于用户。 这意味着：不注册账号、不收集个人信息、用户可以随时导出全部数据。

功能保持克制。 只做一条时间线，不做“项目/文件夹”式的多层级管理，避免把轻量工具变复杂。

与典型生产力工具的边界，我做了清晰的对比：

方面	生产力工具	Monthley
驱动力	外部要求、责任感	内在兴趣、好奇心
时间感	截止日期、线性推进	月份节奏、循环回顾
成功标准	完成率、产出量	持续记录、生活满足感
情感基调	紧张、严肃	轻松、愉悦

这个边界定义成了后续所有设计决策的“锚点”。每当犹豫一个新功能要不要做，我都会回来看它是否违背了这些原则。比如，有人建议加入“每日提醒”，但因为这违背了“不制造压力”的原则，我决定不做。

3. 从用户故事到关键设计

我用几个核心用户故事来定义功能范围，确保每个功能都能回答“它解决了谁在什么场景下的什么问题”：

“月初，我想快速记下这个月打算读的书、玩的游戏。”

“月中，我可能想把一个计划移到下个月，因为发现时间不够。”

“月末，我想看看这个月完成了多少。”

“年底，我想要一个漂亮的总结卡片，能看到这一年我都在做什么。”

“大多数时候我会在手机上用，但有时候我也想在其他设备上编辑我的计划。”

围绕这些故事，我做出了几个关键设计决策：

决策一：以“月份卡片”为交互核心

用户对生活的思考是以“月”为单位的，所以我把月份设计成一张张可以展开收起的卡片。当前月份始终展开——这是用户最关心的；过去已完成的月份可以折叠——减少视觉负担；而过去有未完成计划的月份，卡片上会出现一个温和的视觉提醒，但不弹窗、不强求处理，尊重用户的选择。

决策二：用四种类型覆盖兴趣生活

调研发现，大家的兴趣活动主要集中在四个类别：学（技能、知识）、玩（游戏）、看（影视剧）、读（书籍）。四类足以覆盖 90% 的场景，再增加会让选择变得困难。每种类型有对应的图标和颜色，用视觉区分而非文字堆砌。

决策三：跨月拖拽来解决“计划调整”

传统工具调整计划需要“点编辑、修改日期、保存”三步。但我的目标用户经常会“这个月来不及，移到下个月”，这应该是一个更直觉的动作。所以我设计为条目可以直接拖拽到其他月份卡片上，一次操作完成转移，符合移动端的触摸习惯。

决策四：用“同步密钥”代替账号系统

跨设备同步是真实需求——用户往往想要在不同设备编辑同一条时间线。但做账号系统意味着注册、登录、密码找回、隐私政策，对一个轻量工具来说太重了。

我设计的方案是：用户生成一个 8-32 位的密钥，自己保管。数据用这个密钥加密后上传到云端。密钥即身份，密钥即密码。关键是要在引导流程中反复提醒用户保存好密钥，降低丢失风险。

4. 交互中的克制表达

产品经理的很多判断体现在细节的“度”上。我在几个地方的取舍，体现了对“轻松记录”这个核心承诺的贯彻：

对“未完成”的态度。 过去月份如果有计划没完成，我不会弹窗、不做红点标记、不强制用户“处理”。只是在该月份卡片的右上角安静地标注“未完成计划”。对应条目旁边有一条细彩线。用户可以看见，也可以忽略。因为生活不是绩效，有些计划没完成，不代表失败。

筛选状态下的自动展开。 当用户使用筛选器查找“所有在读的书”时，所有包含匹配条目的月份会自动展开。这避免了用户需要手动逐个翻看月份的繁琐，让查找体验变得顺畅。

搜索结果的上下文呈现。 不仅展示条目名称，还附带类型图标和所属月份。用户点击后不只是“看到结果”，而是直接跳转到时间线上对应的位置并高亮——从找到到定位，一步完成。

5. 验证现状与待探索问题

Monthley 目前已经完成第一版开发并上线使用，包含：

按月份展开收合的时间线，支持无限滚动加载
条目的添加编辑、状态推进、跨月拖拽
按类型和状态筛选、按名称搜索
统计页面（完成率、类型分布、年度热力图）
年度回顾弹窗，可生成分享卡片
中英文切换、深色模式
云端加密同步，含首次引导流程

但它作为一个个人项目，还没有经过大规模用户验证。有几个假设是我接下来特别想探索的：

用户真的会满足于以“月”为单位思考和使用吗？ 还是会期待出现“本周”视图？
“不打扰”式的未完成提醒，在真实使用中是否足够？ 还是用户在某种程度上反而希望有更主动的轻提醒？
同步密钥方案的真实体验如何？ 没有密码重置机制，用户忘记密钥的场景和比例到底有多大？
交互是否符合直觉？ 在没有引导的情况下，用户是否能自然学会使用所有功能？

6. 复盘：这个 Case 体现了什么

作为独立完成的产品项目，Monthley 展示了我在几个维度的能力：

用户洞察 —— 不是凭空想象需求，而是通过定性访谈发现“兴趣记录”这个被忽视的场景，以及“月”这个被忽视的时间粒度。

产品定义 —— 通过明确的“不做什么”来划定产品边界，让每个功能决策都有据可依，避免了范围膨胀。

设计决策 —— 从用户故事出发推导交互方案，在多个关键节点做出了有意识的取舍（不做弹窗提醒、不做多层级分类、不做账号系统）。

优先级判断 —— 在 PRD 里明确标注了“不做”和“暂不做”的功能清单，体现了对资源与范围的把控能力。

独立落地 —— 从调研、需求到设计和实现的完整流程，能够独立把一个想法变成一个可用的产品。