我所理解的 UI 设计最佳实践（1）：把界面反馈说清楚
- 把界面反馈说清楚（当前）
我做 Markdown 批注工具时，有几次打开界面，只想说一句「看着还是有点怪」。目录能用，批注能写回文件，按钮也都在。真用它审一篇长文，我才说得出几个具体问题。顶栏把好几个辅助操作做成了带框的按钮，切换文件时长文件名有机会突然折行，窄窗口里打开批注会把正在读的段落挤窄。这几件事当时给我的感觉很像，改法却各不相同。
敲代码的小虾米在知乎的《要不要学代码：Vibe Coding 真正该练的是什么》里提到，设计词汇能帮人描述界面，产品流程能帮人想清楚需求。我很认同。知道「视觉层级」「布局位移」这些词，可以让我指得更准。决定怎么改，还得先知道人在这个页面上要完成什么。
页面应该把什么放在第一位
长文阅读页里，我希望进来先看到标题和正文，随时能从目录换文章，需要的时候再找批注和查找。放到审批页上，优先级就不同了。申请内容、影响范围和审核结论都很重要，到了该提交决定的一步，主要按钮就需要容易找到。判断控件要多显眼，可以先想象用户进页面后的头几个动作，看看界面有没有把注意力分给这些动作。
我一开始觉得批注工具的深色主题太蓝，后来把大面积底色改成接近中性的深灰。颜色顺眼了，正文外面的卡片轮廓却还在。目录、顶栏和正文都各画一圈，视线经过了好几层边界才到文字。于是又把正文直接放到阅读区底色上，用一点明暗差区分侧栏和代码块，把选中文件和批注锚点的强调留在需要定位的地方。
边框适合交代归属，比如分隔两条挨着的审批记录，或标出一组一起生效的设置。正文从标题到段落本来就是连续的，行长、留白和标题已经能交代阅读顺序。按钮也是一样。IBM 的 Carbon Design System 按钮指南把低视觉权重的 Ghost 按钮用于辅助操作，也展示了以阅读内容为主的页面如何处理按钮。对照这种例子时，我会先看哪样东西应该最显眼，再决定要给它多少底色、边框和对比度。
从参考图里挑一个问题看
我在 Dribbble 上看到 Oleg Ladygin 为 Equal 设计的 Desktop Notes App，最想借用的是左栏。入口沿一条线排下来，文件树靠缩进、图标和选中底色表达层次。对需要扫一串文件名的人来说，这套做法让人容易认出当前项，也知道哪些文件夹还可以展开。至于这张图里的配色和笔记编辑布局，和我当时要处理的目录问题关系不大。
另一张是 Jeremy Blaze 为 Never Before Seen 设计的 Manage comments in doc editor。原文里有高亮，右侧有评论。两处分别解决「在说哪句话」和「说了什么」，读者可以先沿正文读，再展开意见。设计稿给了我一个摆放方式，接下来要看真实产品怎么处理开关和跳转。比如 Google Docs 的评论帮助里，选中文字后可以添加评论，评论面板也可以按需打开、关闭，正文旁的评论还可以最小化。
这两张图能帮我讨论区域怎么摆。长文件名能放几行、评论堆多了往哪里滚、关掉面板会回到哪里，还得实际打开页面看。以侧栏为例，VS Code 的工作台文档里，文件树在主侧栏，其他辅助视图可以移到次侧栏，主侧栏也可以随时隐藏。并排适合反复来回看的两个区域。偶尔才打开的工具，更值得为窄窗口单独想一种放法。
操作有多常用，入口就该有多好找
为了让顶栏少一个按钮，我把「复制文件路径」放进了「更多」。审文档时，我经常要把路径发给 Agent，让它定位原文件。每次都多点一下，很快就嫌麻烦。后来复制图标回到顶栏，悬停能看到「复制文件路径」，大纲、批注、查找和复制仍能在窄窗口排成一行。
这也是判断该用文字还是图标的一种办法。重复使用、图形容易认、空间确实有限的动作，可以用图标加提示。第一次使用就需要理解后果的动作，例如提交审批或覆盖文件，写清楚动作通常更省事。压缩界面时，我会优先看能不能减少重复的容器和装饰，再看哪些操作真的适合藏起来。
下面是左栏和顶栏做减法前后的截图。两版都已经把复制图标放回顶栏。两张图使用同一份样稿、窗口尺寸、主题和字体。上图的顶栏和打开文件入口各有一圈边框，左栏选中项也有额外的强调色。下图把左栏入口做成对齐的列表，选中项用底色标记，顶栏多数辅助按钮默认只显示文字或图标。
反馈要写到什么程度
「目录看着乱」可以先写到这种程度。左栏缩窄后，切换到一个接近栏宽的文件名，选中样式加粗了文字，原本一行的文件名变成两行，下面几项都被推下去。希望改用底色标记选中，文件名在默认、悬停和选中时占用同样的空间。验收时用一个卡在换行边缘的真实长度文件名，固定栏宽切换选中项，看当前行高度和下面一项的位置。
里面有四个信息，发生在什么场景，具体妨碍了什么，希望怎么表现，怎么检查。「选中时只用底色」是设计选择，「切换选中项时下面的行别移动」是可以直接检查的结果。有时候我只确定后者，也可以把方案交给 Agent，先看它对问题的理解，再决定要底色、侧边标记还是别的处理。
如果只有一张参考图，可以圈出要借鉴的地方，说明想要的是结构、视觉效果还是交互。例如「参考 Equal 的左栏入口和选中态，打开文件夹、打开文件、最近打开纵向对齐，文件树继续保留缩进和展开图标」。如果已经有一套需要跨页面维持的视觉约束，可以继续写进项目的 DESIGN.md。单次反馈可以只写本轮会涉及的区域和状态。
验收要复现当时的动作
两张截图适合判断顶栏的边框少了以后，注意力是不是更容易回到正文。它们证明不了打开批注的一瞬间会发生什么。为此，我在同一份样稿上把窗口缩窄，滚到文中，再开关批注面板。宽窗口让批注和正文并排，阅读区剩余空间不足时则在右侧临时盖一层。浮层会挡住右侧的一部分字，适合快速看意见。想一边通读全文一边对照意见，宽窗下的并排布局更方便。
我用两个 Windows 打包版做了同样的操作。窗口内容区宽 901 CSS 像素时，旧版打开批注把正文从约 541 像素压到 352 像素，首段从两行变成三行，虽然滚动偏移数值仍是 55 像素。新版开关面板时，正文宽度、首段的行位置和滚动偏移都一致。这里如果只检查滚动条的位置，旧版同样能通过，读者看到的那几行却已经变了。
换到别的页面，验收也可以沿着用户动作走。搜索栏想改得紧凑一点，可以实际输入一个长查询、用键盘选结果，再关闭结果面板看焦点落在哪。审批页想让结论更容易找到，可以用一份内容较长的申请，走到提交前，确认关键信息和操作在当时的窗口下都能看见。「更紧凑」和「更容易找到」仍要打开页面看，焦点位置、文字有没有被遮住，则可以各自检查。
有时我还是会先说「看着怪」。这句话能指出哪里值得停下来。再走一遍刚才的操作，指出哪一眼找不到东西、哪一步打断了阅读，就知道下一版该改哪儿，也知道拿到结果以后该怎么试。