连续迭代后的三个具体问题
原稿记录在 29 个版本积累之后,出现信息堆叠、B / C 端体验不一致和适配不足。改版需要同时处理创作、发布与管理,而不是只给首页更换视觉。
这些问题可以沿一次任务追踪:进入账号、输入内容、预览发布、再管理状态。下面保留这条主线,再展开支撑它的视觉与响应式规则。
统一账号入口减少路径断点
百度不同创作产品之间的账号与登录入口,会影响创作者能否自然进入同一身份下的工作。原稿讨论统一 B 端身份、扫码入口,以及信息前置说明。
图中看的是入口与身份关系,不从孤立数字推导转化率。信息前置的目的在于减少表单不确定性;真实结果需要完整基线、时间窗与用户样本。
沿着创作任务看体验,而不是按页面分工。
创作者会经历进入编辑、组织内容、设置封面、预览与发布。不同入口和客户端如果使用不同操作语言,切换成本就会累积到同一项创作任务里。
编辑器能力一致,表达方式可以不同。
文本与表达
固定高频编辑操作的位置与方式,让文本样式、表情和图片插入更容易预期。
推荐与工具
在一致的操作结构里突出当前任务需要的推荐内容,不让能力扩展打断写作。
发布完成,不应该是一个信息断点。
发布链路不仅包含提交按钮,也包含封面确认、完成反馈和后续动作。跨端一致性需要覆盖这些状态,使创作者知道内容到了哪里、接下来还可以做什么。
内容状态决定下一步可以做什么
创作没有在点击发布后结束。草稿、已发布、审核未通过与已撤回对应不同的下一步:继续编辑、查看数据、理解原因、反馈或重新处理。状态必须改变动作,而不只是增加一个标签。
原图是一组状态样例,不是改版前后对照。可以逐行检查状态文案、原因反馈与右侧操作是否一致,再对长标题、多标签和不同内容类型做压力测试。
| 状态 | 用户需要理解 |
|---|---|
| 草稿 | 内容是否保存,如何继续编辑或删除 |
| 已发布 | 发布到哪里,怎样查看反馈与数据 |
| 审核未通过 | 具体原因与可采取的修正或反馈动作 |
信息分组与尺度成为共同规则
卡片归组、标题层级和更清楚的留白共同处理信息噪声。原稿采用 8 / 13 / 21 的圆角尺度,并使用 Bebas 强调数据和收益数字。它们是这次项目的视觉选择,不是对所有产品都成立的数学证明。
间距规范使这些选择进入可实现的布局。应对照内容归属和控件关系检查规则,而不是只评价规范页是否整齐。
窄屏下,导航与内容怎样让位
原稿有 1024 与 1920 两组实际适配图,并给出不同内容宽度策略。窄屏需要重新组织导航占用和核心内容,不能只把大屏画板等比缩小。
这里按原图展示两个端点,不自行补齐未明确的中间断点。评审关注导航收起后用户能否找到当前位置,以及内容操作是否仍然可达。
大屏下保留工作关系
1920 画板展示导航展开与更宽内容的组织。宽屏不是无限拉伸文本,而是将工具、内容与辅助信息放在稳定关系中。
原稿还保留 PC 代码组件库的实现交付说明,能够说明设计向实现推进过;但不据此宣称今天仍有可访问的公开仓库。
创作体验的交付与复盘
能够逐项阅读的成果是账号入口、编辑发布、内容管理、适配与规范材料。两份资料中的软阴影 / 新拟态页面另属于明确的概念研究,不用它们冒充正式 5.0 上线界面。
创作工具的克制不是少提供功能,而是把功能放在正确的时间和位置。设计需要让用户感到自己在创作,而不是在操作一个复杂系统。

