学习打卡表为什么不做成日历：一次按考试倒数的设计记录

最近在做学习产品 Yozi 的打卡表，遇到一个看似小、实际决定产品形态的问题：打卡表做成什么样？最常见的答案是日历——一个月一张格子，每天打个勾。这个方案我们最后没有用，改成了拼豆模式，记录一下当时的判断过程。

先看用户真正的使用场景

主流场景不是“随便记一记今天学没学”，而是用户有一个明确的考试时间，在按考试时间倒数。备考的每一天都有一个明确的终点，学习进度是向着那个日期推进的。日历的问题在于它只记录“哪天打了卡”，不表达“离目标还有多远、已经拼出了多少”。格子打满一个月就翻页，进度感在翻页那一刻就断了。

拼豆模式换了一个表达：画稿提前做好，用户自己选一幅，打卡一天得一颗豆，一天一天把画拼出来。进度不再是格子里的勾，而是画面一点点成形。考试日期就是拼完的截止日，倒数天数和拼图进度是同一回事。

缺卡的那天怎么处理

日历模式下缺卡就是一个空格，补不补全凭自觉，补了也只是在格子里补一个勾。拼豆模式下缺卡的那天就缺一颗豆，画面上会留一个看得见的空洞。这个空洞不是惩罚，而是让缺失本身可见。

处理方式也跟着变了：缺了的豆子可以通过增加学习次数获得豆子补上。也就是说，补救不是把空格涂掉，而是多做一次学习、挣回一颗豆。规则很简单：学习行为本身就是补救的手段，不用另外设一套补卡流程。

为什么这个选择值得记下来

第一，形态要跟着场景走。日历是通用记录工具，拼豆是面向“有明确截止日期的备考”这个具体场景的表达。场景越明确，越不该用通用形态去套。

第二，进度要让人看得见。格子里的勾只有自己翻回去才看得到，拼出来的画面每天打开都在眼前。学习产品里，进度可见本身就是一种动力。

第三，缺失要看得见、补救要靠行动。缺一颗豆画面就缺一块，这个缺口每天都在提醒；补救的办法不是点一下补卡按钮，而是多学一次。设计把“补救”绑在了学习行为上，而不是绑在界面操作上。

这次的结论很简单：打卡表不是记录工具，是进度表达。选日历还是拼豆，取决于你想让用户每天看到什么——一张翻过去就忘的格子，还是一幅一天天拼出来的画。