先把问题想清楚，
再用界面回答。

我的习惯是先弄明白一个东西在系统里怎么运转，再去决定它在界面上应该长什么样。顺序反过来的话，界面再好看也只是猜。

写过代码的经历也让我知道，一个交互落到实现时会撞上什么——哪些动效有性能预算，哪些状态必须提前穷举，哪些「看起来简洁」的做法会在真机上变成一片空白。 所以我做的稿子通常不太需要来回解释：间距是 4 的倍数、状态有没有列完、切图在真机上是什么样，这些在交付的时候就已经确认过了。

我判断一份界面好不好，主要看非常态：空的时候、错的时候、绕路的时候。 所以做每个项目我都会先把空态、无结果、识别失败这类路径定完，再回头看主流程——这些地方最能看出一个人有没有真的用过自己设计的东西。

作品集里的两个案例，都是我自己从问题定义一路做到可交互原型的：一个是微信小程序，一个是 Windows 桌面工具，现在都能在站内直接点开试。 如果只用一句话介绍自己：把复杂的部分收进界面后面，把清楚的留给用户。