51 lines
3.8 KiB
Markdown
51 lines
3.8 KiB
Markdown
|
# 整理已有页面
|
||
|
|
|
||
|
|
用户对一页或一块区域不满意，但没说要改成什么样：“别扭”“不好看”“优化一下”“别改太多”。这时不出三个风格，在现有的视觉语言里修。要用户判断的是问题找得对不对：Agent 看得到页面，看不到页面背后的业务。一段看似多余的说明可能是法务要求，一个看似次要的按钮可能是每天都在用的。
|
||
|
|
|
||
|
|
范围是整个产品，或者是落地页这类不用和别的页面保持一致的独立页面时，先按 [存量项目](existing-project.md) 的“推翻程度”判断要不要出三档。
|
||
|
|
|
||
|
|
## 第一轮：诊断，不改文件
|
||
|
|
|
||
|
|
1. 找项目根目录和 docs 里的 `DESIGN.md` 或同类设计文档，有就以它为准，它已经回答的前提不再问。
|
||
|
|
2. 用 [截图工具](tools.md) 在桌面和手机宽度各截一张整页，存进任务目录做基线。
|
||
|
|
3. 写一句这页是干什么的、用户来了第一眼该看到什么。看不出来就放进要确认的问题里。
|
||
|
|
4. 对着截图和样式代码逐项看下面几处，每项都看，不要只挑最显眼的：
|
||
|
|
- 窄屏下有没有文字挤出容器、被截断或折得难看；
|
||
|
|
- 同一列的左边缘、同一行的文字是否对齐；
|
||
|
|
- 同一种按钮、标签、输入框是不是长得一样；
|
||
|
|
- 有没有重复标题意思的说明，或者解释界面怎么用的话；
|
||
|
|
- 一屏里有几个实心主按钮，最该先看到的东西是不是最醒目；
|
||
|
|
- 键盘焦点看不看得见，悬停和按下有没有反馈；
|
||
|
|
- 长名字、空数据、出错时是什么样。
|
||
|
|
|
||
|
|
挑出最影响使用和观感的 3–5 个问题，按影响排序。用户说了哪里不舒服，第一条先说清是什么造成的。
|
||
|
|
5. 每个问题归到一类：
|
||
|
|
- **直接修**：文字溢出、没对齐、焦点看不见、同一种组件两种样子这类客观缺陷。
|
||
|
|
- **请确认**：要靠业务和用户情况才能判断的，例如某段文字能不能删、某个按钮用得多不多、这么密算不算挤。把背后的猜测写出来，例如“我猜这个按钮很少用”。
|
||
|
|
6. 问题的位置用文字说不清时，例如对齐、间距、某一块区域，诊断定稿后用截图工具的 `--mark "1=选择器; 2=选择器" --full` 标出来，核对图上的编号和诊断一致。
|
||
|
|
|
||
|
|
把诊断发给用户，**这一轮到此结束，不改任何文件**，“直接修”的条目也等到下一轮再改。消息照这个样子写：
|
||
|
|
|
||
|
|
```text
|
||
|
|
这页是……，用户来了先要看到……
|
||
|
|
1.【直接修】看到……，因为……，打算……
|
||
|
|
2.【请确认】看到……，我猜……，所以打算……
|
||
|
|
标注截图：<路径>（标了才写）
|
||
|
|
请按编号回复对不对，不对的说一下原因。
|
||
|
|
```
|
||
|
|
|
||
|
|
只有用户说了直接改，或者无人值守时，才不等回复，直接进入第二轮，把“请确认”的条目写进交付说明，标为假设。
|
||
|
|
|
||
|
|
## 第二轮：改
|
||
|
|
|
||
|
|
- 改“直接修”的条目和用户确认过的条目，按 [存量项目](existing-project.md) 的“从源头修改”落到现有变量和组件上。不换字体、颜色和组件的样子。
|
||
|
|
- 用户否定的条目和理由，项目有设计规范文件时写进去，标用户确认。
|
||
|
|
- 纯口味的选择不按 SKILL.md 步骤 1 用文字问，在那一处做两个局部版本放进对比页。
|
||
|
|
|
||
|
|
## 交付
|
||
|
|
|
||
|
|
- 现状和整理后的版本，用同样的视口和数据放进 [对比页](style-explorer.md)。
|
||
|
|
- 编号的改动清单，每条一句“问题 → 改法”，用户可以按编号撤回。
|
||
|
|
- 一到三条看到了但没改的，需要升级或重塑才能解决的也放这里，问用户要不要看看。
|
||
|
|
- 设计说明只写诊断、确认结果和改动清单。
|
||
|
|
- 评审按 [存量项目](existing-project.md) 的“各类改动怎样评审”。
|