अभी लॉगिन करें 最近在做的一个后台体验优化项目，完整走下来七个阶段，坑踩了不少，感受也挺深的。趁着记忆还热乎，想把整件事复盘一下，重点说两点：一是面对后台产品那种琐碎又复杂的用户场景，怎么才能更系统地去思考设计；二是接到需求之后，怎么跟业务方沟通，怎么推动方案真正落地，而不是设计师自己关起门来“自嗨”。
先说说这次要改的东西。做的是酷家乐“到店购”业务里的报表管理后台。可以把报表理解成商机线索的集合——品牌方需要一条条审核，再把它们分配到对应的线下门店去跟进，成交之后还要结算佣金。整个链条很长，牵扯的角色和操作节点都不少，而系统一开始搭建的时候基本是功能优先，交互上没怎么细磨。结果就是，功能都齐全，但用起来确实累，页面信息密度高，操作路径也绕，新人上手的成本尤其高。
这类后台产品有个挺典型的特点：用户场景从来不是单一的，任务经常是碎片化的，多线并行的，很多操作背后还连着审批、流转、财务这些现实流程。所以改版的时候，特别容易陷入“头痛医头”的状态。如果只盯着某一个页面或某一个功能去优化，改完再看，整体体验可能并没有实质提升，反而拆东墙补西墙。
项目初期，我们花了不少时间把不同角色在不同阶段要完成的核心任务梳理出来，再对照现有后台，看哪些地方卡住了、哪些信息缺失、哪些操作其实可以合并。这个过程虽然有点笨，但确实能帮我们跳出“界面好不好看”这个层面，重新回到“用户到底要完成什么事”这个原点上来。
至于怎么让业务方接受方案，也有一些小技巧。很多时候，设计师直接拿一套交互稿去讲，对方很容易揪着视觉细节，或者自己习惯的使用方式不放。后来我们换了一种方式，先用流程图和服务蓝图把用户的使用场景和痛点讲清楚，让对方先认可“问题确实存在”，再引出设计方案。这样一来，讨论的焦点就从“你觉得这个按钮放哪好”变成了“我们怎么一起解决这个问题”，沟通成本明显低了不少。
当然，这还只是整个项目的第一阶段——把业务目标定清楚，把问题摊开来，让团队对“为什么要改”达成共识。接下来，才是真正开始拆解问题、打磨方案的过程。
