1. 给“ui-ux-pro-max技能”定个调它不是画图是一套决策方法1.1 我理解的UI/UX界面是结果体验是路径先说结论被人夸“UI/UX Pro Max”的设计师通常不是软件操作最花哨的那个而是能在每个环节给出“为什么这么做”的人。我之前在一家做企业服务的公司带过一个改版项目。两个设计师各自出了一版首页方案A的视觉明显更好看图标精致、插画到位、动效炫目B的方案看起来“普通”很多没有花哨的装饰但把导航重新梳理后最常用的查询任务从原来的点5次变成点2次。我们找用户实测B方案的任务完成率提升了将近40%。A同学问我为什么不用他那版我说“因为你的界面是好看的结果B的界面是用户走完全流程之后的产物。”UI和UX经常被放在一起说但实际是两件事。UI是界面本身是按钮放在哪、颜色用什么、卡片间距多少UX是从用户产生一个需求到在界面里找到入口、完成任务、得到反馈的整个路径。UI是“可见的部分”UX是“不可见的部分”。两者不能互相替代UI丑会让用户不愿用UX乱会让用户用不明白。所以“Pro Max”的本质不是技能点堆满而是具备一种设计决策能力知道每个像素背后对应哪个用户场景知道每次改版到底在改什么。这篇小记就是把我这些年攒下来的UI/UX实操方法、踩坑经验、交付流程中那些能直接用的东西整理一遍给正在做界面设计的、准备转行做产品设计的、以及和设计师配合的开发/产品同学一个可以对照参考的手册。1.2 这套技能要解决的四类真实问题这些年我带过的设计师大多会遇到四类问题。第一类是视觉基本功不扎实排版靠感觉、配色靠运气做出来的稿子“看着还行说不清哪里好”评审会上被问一句“为什么这儿用蓝色”就答不上来。第二类是不会拆需求。产品经理丢过来一句话“用户需要一个报表功能”很多设计师就直接打开设计软件开始画图。画了两天做出来发现根本不是产品要的东西又推翻重来。问题出在“没有从需求推导出设计方向”这一步。第三类是交付环节断裂。设计稿做得漂亮但开发做出来完全不是那么回事间距不对、状态缺失、字体大小全变。很多设计师把这个问题归结为“开发不用心”真相往往是设计交付物本身不完整没有标注、缺状态、没有说明交互规则。第四类是没有验证手段。方案上线前全靠“我觉得好看”“我们开会讨论了”结果用户根本不买账。做得好的团队会用可用性测试、数据分析来支撑设计决定而不是拿“审美”当挡箭牌。这四个问题正好对应这篇小记的后四个章节视觉基本功、UX方法论、全流程工作流、避坑手册。每一项都是我实际做项目时反复打磨过的不是教科书理论。2. 视觉设计基本功把“看起来还行”练成“有依据的好看”2.1 网格、间距与节奏为什么8的倍数能救命刚入行的时候我摆间距全靠肉眼。“感觉这里要大一点”“那里好像挤了”……这导致一个很尴尬的局面同一个页面做成三个版本间距各不相同和别人协作时每个人都按自己的习惯微调最后全页面对不齐。后来我强制自己用8点网格做间距简单说就是所有间距、留白、内边距、元素尺寸尽量用8的倍数比如8、16、24、32、48。这样做的第一个好处是节奏感强。人的视觉天然喜欢有规律的间隔当你把卡片间距固定为16、区块内边距固定为24、页面留白固定为32时整体会呈现出一种“看不见的秩序感”比凭感觉排出来的版本舒服得多。第二个好处是协作效率。团队几个设计师同时做一个项目约定好间距tokenspacing-18、spacing-216、spacing-324……谁出的稿子都能无缝对接开发还原时也不用反复问“这个距离是多少”。我常用的一套间距体系Token名称数值使用场景space-14图标与文字之间、紧凑表格space-28组件内部紧凑间距space-316卡片内边距、控件之间space-424卡片间距、区块间距space-532页面左右留白space-648大模块之间的分隔注意8点网格不是盲目套用。有些场景需要更细腻的间距比如表格里文字和输入框之间的2px、4px这时候用4点网格更合适。我一般先定8点为主间距遇到紧凑场景再允许用4但绝不出现6、5、7这种没有规律的“孤独数字”。2.2 字体与层级字号阶梯不是随便拉出来的很多设计稿的问题不是“字太小”而是“没有层级”。我曾经接手过一个后台系统全局字号加起来有13种从10px到28px全部用了个遍。结果用户打开页面不知道该看哪因为全是重点就等于没有重点。后来我把整个系统的字号收敛成一套阶梯。以中文为主的后台界面我推荐这一组正文16px、次级文字14px、辅助说明12px、标题20px、页面标题24px、数据大屏或运营位再用32px甚至更大。正文字号不建议低于14px最小辅助字号不建议低于12px中文在12px以下的可读性会急剧下降。字号一旦确定行高也要跟着规范。正文行高一般是字号的1.5到1.6倍标题可以紧凑一些1.2到1.3。为什么中文正文如果行高太小多行文字会“粘”在一起行高太大又会让段落显得松散。强调层级的时候优先用字重而不是字号。想突出一个重点用medium或bold的16px而不是把14px正文放到18px。同一段内容如果字号变太多会让页面显得杂乱但字重变化不会破坏结构。还有一个很容易被忽视的细节数字和英文字体要用等宽数字。如果一个列表里显示“12个”和“1234个”普通数字字体的宽度不同会导致数字上下不对齐一眼看去全是“锯齿感”。打开字体设置里的tabular-nums这个问题就解决了。这个小细节开发很少会自动处理设计师需要在组件规范里明确出来。2.3 色彩不是越多越好对比度与语义色的使用色彩是UI设计里最容易被滥用也最容易被挑战的部分。我见过不少设计稿一个页面里用了七八种颜色主色、辅助色、渐变色、强调色全堆上去用户根本分不清哪里可以点、哪里只是装饰。我建议项目启动前先建一套克制的色彩系统而不是边画边想。核心色板只需要三类主色通常是品牌色用在主要按钮、当前导航、链接等可交互元素、功能色成功/警告/错误/信息各有固定语义不能混用、中性色文字和背景的灰阶。主色不要超过一个主色和一个辅助色辅助色只承担“点缀”职责。色彩最重要的是对比度不是好不好看。正文与背景的对比度建议达到4.5:1以上大号文字和UI组件可以放宽到3:1。很多浅色按钮看着高级但白字放在浅蓝底上对比度只有2.8:1用户尤其是手机亮度低的时候根本看不清。Figma里可以用对比度插件直接检测选中两个图层就能看到数值。使用对比度工具检查每一个按钮、链接、输入框提示文字。如果对比度不达标优先调深文字色而不是调亮背景色或者改用有色彩的同时加上图标、下划线等非颜色提示。不要只靠颜色表达状态——比如一个“已取消”的订单如果只用灰色和“已完成”的绿色区分色弱用户就直接分不出来了。2.4 组件状态与一致性一个按钮的7种状态设计师最容易偷懒的地方是只画组件“理想的样子”。一个按钮只给一个默认态到了开发手里就麻烦了鼠标放上去有没有变化点击时怎么反馈加载中显示什么不可用时是置灰还是变样式开发被逼无奈只能自己发挥发挥出来的风格大概率和你整个设计系统不符。我在项目里要求每个按钮至少定义7种状态默认、悬停、按下、加载中、禁用、聚焦、完成/失败反馈。悬停是背景或阴影的细微变化让用户感觉“这个东西可以点”按下是轻微下沉或背景加深加载中转成spinner并让按钮内容不可重复点击禁用要保留一定对比度不能完全看不清聚焦状态是为了键盘用户和辅助功能不能设计成“根本没有框”。组件状态不只是按钮。输入框要有默认、聚焦、输入中、错误、禁用、成功状态下拉菜单要有空态、加载态、无结果态列表要有正常、悬停、选中、禁用。每次画组件前先列出这个组件的状态清单再动手画一遍能过齐开发和测试也不用反复问。组件库的价值不止是省时间更是治理标准。两个设计师做同一个模块按钮形态不一样、圆角不一样、阴影不一样用户打开会觉得“这是两个产品”。有了状态完整的组件库任何人调用出来都长一个样这个产品才谈得上“设计质量”。3. UX方法论实战从“我觉得”到“用户觉得”3.1 用户调研别只做问卷访谈提纲怎么列很多团队做用户调研习惯性发一份问卷。问卷能拿到数据分布比如“80%用户觉得首页导航不好用”但它拿不到原因。为什么不按这个导航走他们在界面里卡在哪一步有什么替代路径解决了问题这些信息只能靠访谈拿到。访谈提纲我一般分三段。第一段是背景了解问用户的角色、使用软件的频率、最近一次打开产品的目的。这一段重点是让用户放松建立对话而不是审讯的氛围。第二段是实际任务回放这是访谈里最有价值的部分“请你打开后台我看看你平时是怎么创建一份新的审批单的。你现在想怎么点就怎么点不用在意对错。”让用户真实操作观察他鼠标停顿的位置、犹豫的瞬间、骂出声的地方。第三段是痛点与期望在任务完成后追问“刚才哪一步你觉得最麻烦如果让你重新设计一个入口你会放在哪里”访谈中最容易犯的错是问引导性问题。“这个界面方便吗”属于送分题用户大概率说“还行”。要换成“你能给我演示一下上次你双击文件之后做了什么吗”让用户讲具体事例而不是让他评价设计。访谈不需要大样本每个核心用户角色找5到8个用户就够。别追求数量追求质量记录用户的原话特别是带有情绪的用词比如“每次都要找半天”“烦死了”“我是这样绕过去的”。这些原话是最好的设计依据写方案时直接引用说服力比任何理论都强。3.2 信息架构与任务流让最常用的事不超过3步信息架构是UX里最容易被低估的部分。很多产品功能堆了一大堆但导航混乱用户找不到入口再好看的设计都白搭。我梳理信息架构时通常用两步。第一步是卡片分类把产品里所有的功能和页面名称写到卡片上让目标用户自己归类看看他们的心智模型是怎么理解这些功能的。比如在企业后台里权限管理和角色管理产品经理可能觉得是两个词但用户会下意识把它们放到同一个分组里如果设计和用户分组不一致用户就会“找不到”。第二步是画任务流把最高频的3个任务从头到尾走一遍看看每一步操作是什么、中间有几道跳转、是否打断了用户的心流。我自己定过一个不成立的标准最高频任务的主路径鼠标点击或手指点击不超过3次超过3次就得找理由——是因为信息必须分级还是因为流程没理顺。有个实际案例某办公系统里“提交报销单”这个任务原来的流程是进入首页→找到“流程中心”→找到“报销”→选模板→填单→提交一共5步。用户经常在第二步就迷路。我们做了一次改版把“最近使用的流程”和“常用申请”直接放到首页首屏高频任务变成两步。查询量涨了30%后台留言里“找不到报销入口”的工单几乎消失。减步不是把三页塞进一页而是理解用户的行动意图把流程中“可预测”的部分前置。这个思路比单纯“减少点击次数”更接近UX的本质。3.3 可用性测试找5个人比自己猜100次强可用性测试听起来很专业实际上这件事的门槛比想象中低得多。不需要专业的实验室、眼动仪一个小会议室、一台电脑、5个用户就够了。为什么5个人足够这是有依据的。绝大多数可用性问题的出现率是相对集中的第1个用户就能发现约三分之一的问题第5个用户之后能发现的新问题就越来越少。与其花大成本招20个人不如分两轮每轮5人第一轮改完第二轮再验证效果远好于一次性找15个人。测试的任务设计特别关键。不要告诉用户操作步骤只给一个场景。“你刚收到一张8月12日的发票想查一下这笔报销到哪一步了请试一试。”接下来就闭嘴让用户自己走。用户卡住的时候不要提醒不要帮忙记录他卡在哪、自言自语了什么、试图点了什么。很多问题就藏在这些“试错”里设计者以为很明显的入口用户根本看不见。测试结果按严重程度分级级别说明处理优先级致命任务无法完成/数据丢失上线前必须修复严重用户能完成但走了很远弯路尽快修复一般用户能够完成但会抱怨“别扭”安排版本修复轻微用户可以克服但体验不顺收集后优化你可以用一张简单的表格记录任务编号、用户编号、操作路径、卡点位置、用户原话、严重级别。一轮测试下来问题列表会让整个团队看清“我们以为的”和“用户实际经历的”之间的鸿沟。4. 全流程工作流从需求到交付的完整闭环4.1 需求梳理与设计拆解先画框再画皮我见过太多设计师接到需求的第一个动作是打开设计软件新建画板这是最危险的开始。需求还没明白就急着画图等于电影还没剧本就先拍海报。拿到需求后先回答四个问题这个功能给谁用用户要完成什么任务现在的流程哪里让人不舒服怎么判断这个功能成了这四个问题不一定都有现成答案需要和产品经理聊有时还要去看用户反馈数据。我习惯用一张A4纸把答案写下来贴在显示器旁边画图时走偏了就抬头看一眼。答案清楚了先画线框不碰颜色和字体。线框只解决信息布局页面上有哪些模块、从上到下的优先级是什么、哪个操作最重要。比如一个数据报表需求首先需要想清楚用户进来第一眼应该看到什么——“总览数字还是明细表格”而不是先想表头用什么颜色。线框阶段改成本极低拖动几个方块就行等到上完色再改结构成本就高了。我常对团队说线框是骨架视觉稿是衣服需求是身体。身体歪了衣服再漂亮也穿不体面。先花半天把需求和结构讲透后面能省出好几天改稿时间。4.2 原型与设计软件实操设计tokens怎么落地现在做界面设计firm的标配已经是变量和组件库了。设计tokens设计变量是让“设计与开发同步”的核心。所谓设计tokens简单说就是把颜色、间距、圆角、字体大小、阴影这些基础参数抽出来起一个好理解的变量名设计稿和代码共用一套命名语言。我在建立项目样式系统时会先建这几组变量。颜色color-primary、color-success、color-warning、color-error、color-text-primary、color-text-secondary、color-bg-default。间距space-1到space-6对应4、8、16、24、32、48。圆角radius-sm4、radius-md8、radius-lg16。字号font-size-xs12、font-size-sm14、font-size-md16、font-size-lg20、font-size-xl24。这样定义的好处是设计稿里的每一个数值都有名字开发不用猜“这个蓝是这个蓝吗”直接引用color-primary就能和设计稿保持一致。设计软件里实现变量的操作比很多人想的简单。创建颜色样式和文本样式把所有用到的基础值替换成变量引用组件库中的按钮、输入框、弹窗全部用变量来搭。这样改主色时只需要改一个变量全局自动更新。我接手过那种“每个按钮都是独立颜色”的旧项目改一次主题要一个一个按钮手动调调到半夜还剩二十处之后我就再也不建“孤立值”了。版本管理也是设计协作里常被忽略的环节。我的习惯是每个关键节点导出快照v1.0-初始方案、v1.1-评审修改、v1.2-用户测试修改。命名里带上日期和修改说明比如“app-v1.3-表单区间距调整”。这样过了一个月想追溯当时为什么这么改不用靠聊天记录看版本名就能找到。4.3 设计评审与迭代如何接住“灵魂拷问”设计评审是新人最容易崩溃的环节。一群人围着你的设计稿提出各种方向完全相反的意见“这个颜色太跳了”和“这个颜色太素了”同时出现“标题再大一点”“信息密度再高一点”“再简洁一点”同时出现。如果你只会点头说“好的我改一下”最后会把自己改成一个四不像。我的应对方式是评审前先写“设计说明”一页纸就行包含这个方案服务的用户和场景、做了什么关键决策、每个决策的依据是什么、有没有备选方案。评审时说清楚这些“为什么”大多数质疑可以被前置化解。有人问“为什么这里用卡片而不用表格”你可以回答“因为这个页面的使用场景是移动端用户在碎片时间快速查看信息卡片能承载更多状态信息且误触率更低。我们测试过表格版点击准确率低了12%。”遇到“把Logo放大一点”“能不能换个更高级的颜色”这类直觉式反馈别急着执行先追问背后的业务诉求。“放大Logo”是希望品牌感更强还是觉得当前页面头部太空“高级的颜色”是希望看起来更专业还是想更年轻化。把模糊诉求翻译成具体设计目标再决定动哪里。评审后一定要产出一份修改清单把意见分类为“必须改”“建议改”“可不改”。必须改是功能障碍或违背用户核心路径建议改是视觉细节优化可不改是纯个人偏好。分类后和团队快速对齐一次避免所有人把自己的偏好当成必须项。4.4 交付给开发标注、切图、走查一个不能少交付环节直接决定还原度。很多“开发做得不像设计稿”的问题源头是设计交付物本身不完整。这里有一个我最常用的交付清单你可以直接抄第一标注。设计稿里的尺寸、间距、颜色、字号、圆角、边框一个都不能少。现在的设计软件都有开发者模式开发点图层就能取到数值但前提是你用了样式变量和规范的图层命名。我特别说一下布局约束开发需要知道每个元素在不同宽度下怎么自适应固定宽度、弹性伸缩、还是自动换行。你不在标注里写清楚开发就会按固定值写换一屏尺寸就崩。第二状态与边界。静态设计稿只画了理想状态但实际产品会有大量边界场景列表为空时显示什么加载中显示什么网络错误显示什么内容超长截断还是换行按钮文案太长怎么处理这些都要在交付时单独给一屏“状态图”。开发最怕的不是你画多了而是你没画——你不画他就自己定义然后和你心中的产品完全不一样。第三切图。能使用矢量格式的优先使用矢量格式比如图标和插画文件小且不模糊无法矢量的位图图片分密度导出覆盖不同分辨率的设备。现在很多资源可以一键导出但注意导出前把图层命名改成有语义的名字除了“icon1”这种垃圾命名。第四走查。开发完成之后设计师一定要逐屏走查对照设计稿检查每个元素的间距、字号、颜色和状态。边距差2px、hover态没有、文案折行这些问题肉眼一遍就能看出来。走查时使用一条硬规矩还原度达到95%以上才算合格不是“差不多就行”。我在项目里把走查结果放进测试报告开发在高优问题处理完后再次确认几轮下来还原度通常能从70%涨到90%以上。5. 常见翻车现场与避坑手册5.1 开发还原度低问题出在交接而不是手活“开发还原度低”这个锅经常被扣在开发头上但我的经验是一半以上的问题出在设计交接方式上。我统计过一个项目交付前设计稿里没有标注的间距开发全部采用了他自己的默认值设计稿里缺少的hover状态开发直接没做字体没有指定字重开发用了系统默认。这不是开发不负责而是交付物的信息不完整。设计稿里画了“一个按钮”开发看到的是一个静态样式他不知道悬停、点击、加载、禁用时的变化。设计师觉得“这些状态不是常识吗”但对开发来说没有人告诉他他就只能决定“默认做最简单的那版”。所以提高还原度的第一优先级是把设计规范变成开发能直接调用的变量。设计侧的color-primary、spacing-3、font-size-md在前端代码里对应成主题变量开发不用猜、不需要每次去设计稿里量。其次是走查机制化定一个还原度检查清单逐项打勾状态缺失、间距不符、样式不对的条目直接回退。我实测过做好这两步一个项目还原度从70%提到92%不需要任何额外的人力成本。还有一个建议设计评审时请开发一起参加不要产品、设计自己关起门来定方案。开发在场能及时提出实现成本和约束“这个状态做不了”在评审阶段说话总比开发到一半再说“做不了”强得多。5.2 暗黑模式与适配方前期不做后面全是窟窿很多团队把暗黑模式当专项需求项目上线后才开始做。如果你没有提前用语义色来组织设计系统那这几乎等于重画一遍整个产品。我用一个很简单的方案规避这个问题所有颜色从一开始就用语义token而不是直接写“背景是#F5F5F5”。比如定义color-bg-primary、color-bg-secondary、color-text-primary、color-border这样暗黑模式不是“换一套颜色”而只是换一套变量的值。同一套组件只需替换变量定义光标切过来就自动适配。前期多花半天把颜色整理成变量后期省下的是几星期的适配时间。暗黑模式不是把背景变黑就完了。对比度在暗色背景下更敏感深色背景上如果还用文字纯白会刺眼暗色模式的字色一般不用纯白而是“接近白的浅灰”比如#E6E6E6。暗色下的阴影几乎看不见要改用“边缘光”或提高层级差异组件之间的分隔更多依赖背景色变化而不是投影。移动端适配上最常见的坑是点击区域太小。用手机触屏的误触率远高于鼠标精确点击Apple和Android官方都建议可点击区域不小于44x44pt/48dp。如果你设计稿里一个文字链接只有16px高用户会点不准误触旁边的按钮体验很差。做法是把可视区域做小热区做大比如视觉上是一个文字链接但外层包裹一个最小高度为44的透明点击区域。多端适配时还要定义断点。我常用的断点体系是手机端768px、平板768px-1024px、桌面端1024px。设计稿至少要出这三档中的关键页面并明确每一档的布局规则导航是折叠还是展开、卡片是单列还是多列、表格是横向滚动还是降级显示。5.3 无障碍不是加分项是底线无障碍可访问性在国内设计圈经常被当成“加分项”有时间才做。我的经验是它应该是默认动作。很多无障碍设计做起来并不难但一旦漏了后期补救成本极高。第一是颜色对比度。前面提到正文对比度4.5:1、大字号3:1。我每次设计方案都会用对比度检查工具过一遍不合格的颜色组合直接改。有些好看的浅色组合过不了那就不应该出现在界面里这不是妥协是质量门槛。第二是不要只依赖颜色传信息。表单校验不通过如果只把输入框边框变红红绿色觉异常用户就无法感知。加上一个错误图标、一句错误文案提示既清楚又不费力。第三是键盘可达性。检查你设计的页面能不能用键盘完成所有操作。Tab键能不能按顺序选中所有交互元素聚焦状态明不明显如果用户只能靠鼠标点击那使用键盘导航的用户包括很多临时鼠标故障的人全都会被卡在门外。我在走查时专门会加一条“Tab顺序检查”按下Tab键看焦点框是否按照视觉顺序移动这个动作30秒就能发现问题。第四是屏幕阅读器支持。图标按钮不能只有一个形状需要有aria-label之类的替代文本图片不能没有描述结构化标签要使用正确的语义元素。一个简单的方法把页面截图去色看看所有状态信息是否还能识别。再把所有可点击元素的文字提示念出来看看是否自解释。做这两步之后你会发现无障碍并没有那么复杂它只是“信息不丢”原则的延伸。最后分享一个我自己受益很久的习惯。每次设计方案做完不管多满意先放一个晚上第二天早上用“用户视角”重新打开把觉得“有问题”的地方逐个标注出来。这个动作帮我拦截过至少一半我自以为酷炫但实际反人类的设计。另外把完成的页面截图调成黑白稿看一眼对比度再把所有交互元素列一个清单勾选状态这两个十分钟就能完成的小动作能抵得上半天的评审会。设计做到后面比拼的不是某个炫技输出而是稳定靠谱地交付每一个决策。这套技能练到最后其实是一种“每个设计都能解释得清楚、每个交付都能被顺利实现”的能力。