1 先把研究问题写清

卡片分类最容易失败的时刻，往往不是执行时出错，而是还没开始，你就把它当成一剂万能药。团队觉得菜单乱，内容多，入口打架，于是说做一次卡片分类吧。听上去很合理，可一旦目标不清，后面每一步都会变得含糊。你会做出一堆分组结果，却不知道该用它来改什么，也不知道改完怎么证明更好。

1.1 你在探索还是验证

先区分两种心态。探索是我不知道用户怎么想，我想先看他们怎么分，怎么叫。验证是我已经有一套分类或导航，我想确认它是否符合用户的理解。

很多初阶设计师会在这一步混在一起。嘴上说要探索，实际上带着一套既定结构去做，卡片一开始就被塞进预设的盒子里。也有人反过来，明明只是想验证一个现有菜单，却用了完全开放的方式，最后得到的分组千姿百态，反而更难落地。

你可以用一个很简单的自检问题来分开它们。你现在最需要的，是发现新的组织方式，还是判断现有组织方式哪里不对。如果你需要前者，你偏向探索。如果你需要后者，你偏向验证。

1.2 你要结构还是命名

结构与命名看似在一起，实际上经常要分开处理。结构是在说这些内容应该聚合成哪些块，层级怎样分。命名是在说这些块用什么词更好懂，更像用户的语言。

有些项目结构并不差，差的是名字。比如同一堆内容大家都能找到，只是类目名像部门缩写，像内部术语，用户读到就发怵。这时你不一定需要重做结构，你更需要找到一套更自然的叫法。

也有些项目恰好相反。你把名字改得再温和，结构仍然混乱。因为本质问题是内容边界没划清，很多东西跨类目摆放，用户每次都要猜。

写研究问题时，要把这两件事分开写清楚。你想要的是一套新的聚合方式，还是一组更贴近用户的标签候选。两者都会从卡片分类里长出来，但你要知道自己更看重哪一个。

1.3 你要全站还是局部

初阶团队很常见的冲动是一次性做全站，仿佛规模越大越有价值。实际情况往往相反。内容越多，参与者越累，分组越随意，分析越困难，最后你反而更难解释结论。

更合理的做法是先明确范围。你要做的是顶层导航的重排，还是某个二级模块的整理。你要解决的是帮助中心的分类，还是后台某个复杂模块的菜单。范围越清晰，你越能写出明确的卡片，参与者也更容易给出高质量的分组理由。

如果你真的要做全站，也建议把它拆成两段。先做高层抽象，拿到大的聚合方向。再针对争议最大的区域做第二轮，专门解决边界与命名。把一次大工程拆成两次小决策，反而更可靠。