UI设计师如何表达项目思考过程

思考过程要回答什么问题

作品集里放最终效果图是最容易的事，难的是让看的人理解你为什么要这样做。项目思考过程的价值在于，它能展示你在信息不完整、约束存在的情况下如何做判断。招聘方看作品，想知道的不是你会不会用某个软件，而是给你一个真实任务时，你会从哪里入手、遇到冲突怎么取舍、交付后如何验证。

表达思考过程，本质上是在回答几个具体问题：这个界面要解决谁在什么场景下的什么问题？信息层级依据什么来定？状态不完整时界面如何表现？窄屏、长文本、空数据这些真实条件有没有考虑过？如果只回答“我做了个好看的页面”，那等于没有回答。

把问题说清楚再谈方案

一个设计结果背后通常有需求理解、信息结构、视觉取舍和落地约束。写案例时，先交代问题范围，再讲处理顺序。问题范围包括：现有资料有哪些、最终用途是什么、哪些部分不能改动。把这些写清楚，看的人才能判断你的方案是在什么条件下做出的，而不是拿一个理想环境中的方案来对比。

描述问题时，区分“现象”和“原因”很重要。比如“按钮不明显”是现象，原因可能是层级关系没拉开、对比度不足、或者它在页面中出现的场景本身就不需要强调。写案例时把现象和原因分开说，能体现你做过拆解，而不是直接跳到改样式。

按任务层级组织你的叙述

界面设计不是一张图，而是一组任务流程。表达思考过程时，可以按任务层级来组织：用户进入页面先看到什么、核心操作在哪里、次要信息如何收纳、异常状态如何反馈。这样叙述自然会把视觉决策和功能目的绑在一起，而不是孤立地谈配色和圆角。

组件状态是另一个容易被忽略但很能说明问题的角度。一个按钮至少要考虑默认、悬停、按下、加载中、禁用、错误反馈等状态。你在案例里写清楚哪些状态做了、哪些没做、为什么没做，比放十张同一状态的效果图更有说服力。空数据、加载失败、网络慢这些边界情况，恰恰是体现设计师思考深度的位置。

长文本和窄屏也是真实项目中绕不开的条件。标题只有几个字时版面很好看，换成真实文案后可能完全不是那么回事。案例里如果能说明你如何处理标题截断、换行规则、字号层级在窄屏上的变化，看的人会相信你做过实际项目，而不是只做过概念稿。

过程记录比工具重要

工具名称只说明你采用了什么手段，真正需要保留的是参数、文件结构、修改原因和检查结果。没有这些信息，过一段时间再维护时仍然要重新摸索。写案例时，工具部分一笔带过即可，重点写你依据什么判断选择了某种方案。

具体检查时，先写问题，再写解决方式。展示工具只是辅助，重点是判断依据。复盘要说明哪里还能改进。检查时不只看是否能够运行或导出，也要换一个使用环境重新查看。例如页面要检查电脑和手机，设计稿要检查尺寸与可读性。问题记录下来以后，下一次处理同类任务会更快。

容易写偏的地方

一种常见问题是只强调“高级感”“科技感”，却没有说明信息为什么这样排。视觉形容词不能替代判断依据。另一种是把页面做得很炫，但按钮、标题、列表和正文阅读体验不稳定——单张截图看不出问题，连续操作几个页面就能感觉到。

还有一种情况是作品只放最终图，不写背景、目标、过程和复盘。这样看的人只能猜测你的意图，猜对了算运气，猜错了你的设计就白做了。写过程时不需要长篇大论，每个阶段写短、写清楚，避免把案例写成纯宣传稿。

复盘部分容易写成自我批评，其实更有效的写法是指出“如果重新做，会在哪个环节采用不同的方式，原因是什么”。这比笼统地说“还有提升空间”有用得多。

放到实际项目中验证

思考过程写得再好，最终要经得起真实项目检验。假设页面需要展示一长串用户协议文本，你要考虑的不是字体大小统一就行，而是阅读行宽、段落间距、是否需要折叠、默认展开还是收起、用户是否真的会读。这些判断写进案例，比单独说“我注重用户体验”可信得多。

能公开的设置、过程和结果可以补进对应文章，不能公开的部分说明边界即可，这本身就是一种职业判断的体现。

最后留一个检查方法：把你的案例文字遮住，只看图，能不能还原出你的思考路径？如果能，说明图和文是匹配的；如果不能，说明图只是装饰，文字才是主体。好的案例应该是图与文互相支撑，而不是各说各话。