不会让你输了先从我自己的一段经历说起吧。几年前还在做UI设计的时候，有一段时间特别焦虑。界面做出来之后，能看得出好看，但说不清哪里好；改版被驳回之后，能改对，但说不清为什么要这样改。后来我把那些"说不清"的东西一个一个抠出来，才发现它们不是灵感问题，而是认知问题——你脑子里没有一个完整的设计知识框架，做界面的时候靠的是零散经验和临场状态，而不是一套稳定的判断系统。
这就是兰亭妙微在《术与道》里反复强调的事情。它把移动应用UI设计的全部知识拆成两个层面：术，是那些能直接上手用的方法、工具、规范、组件；道，是那些决定了你为什么会这样选择的原则、认知、心理学依据和场景判断力。两者不是上下级，而是支撑关系。很多设计师学了三年软件却做不出好作品，问题不在手，在脑。
这篇文章就是基于兰亭妙微《术与道》这套体系化知识框架做的一份原创解读，结合我自己做移动端项目时的实际经验，把那些平时散落在各篇文章、各个规范文档里的知识点捋成一个有结构的东西。不管你是刚入行的新人设计师，还是做了几年想突破瓶颈的进阶者，这篇文章应该能帮你把自己脑子里的设计知识重新归档一遍。
1. 先从"术道分裂"说起：UI设计师的瓶颈往往出在认知层
1.1 工作三五年后的困境：会做不会想，会想不会做
我见过一个特别普遍的现象：很多设计师做的界面，单看任何一个元素都挑不出大毛病，但整体放在一起就是"差点意思"。差在哪？差在判断。一个按钮放左边还是右边，说明文字用两行还是一行，弹窗用底部弹窗还是居中弹窗——这些决定不是靠审美拍脑袋想出来的，而是由你在那个瞬间调用到的知识层级决定的。如果你脑子里只有"别人怎么做的"，你就会抄；如果你脑子里有"为什么应该这样做"，你才能判断。
反过来，也有一类设计师，读过很多设计文章，懂很多原则，张口就是"格式塔原理""费茨定律""认知负荷"，但落到具体页面上不知道怎么取舍。这两种情况我分别管它叫"有术无道"和"有道无术"。都是病，病根都是知识不成体系。
还有个更隐蔽的问题：设计师的复盘能力不足。很多人做完一版界面，被产品经理打回来改了七八遍，最后也不知道到底哪一版是对的。因为每次修改都靠别人推着走，自己没有一套判断标准。这其实就是"道"层的缺失——你没有一个稳定的坐标系来告诉你，哪个方案更接近正确。
1.2 什么是"术"，什么是"道"：先给这两个字划清边界
先把概念理顺。兰亭妙微的解读里，术和道的边界不是按"技能"和"思想"来划的，而是按"是否依赖具体场景"来划的。
术，是任何一本设计教程里都能找到的东西。比如组件库的使用方法、8pt栅格规则、iOS和Material Design的规范差异、切图标注的流程、设计稿命名规则。这些东西的特点是：可复制、可学习、有标准答案。你不需要特别强的天赋，只要你投入时间，就能掌握。
道，则是当你面对一个没有标准答案的场景时，支撑你做判断的那套底层认知。比如一个金融App和一个社交App，同样的界面布局为什么结论不同？用户的注意力在什么场景下最脆弱？为什么这个页面信息已经很多了，我还是决定把最重要的操作放在底部而不是顶部？这些都是判断，不是知识检索。
一个核心的区别在于：术可以靠"背"，道只能靠"建立"。背下来的规则是死的，建立起来的认知是活的。比如你背下了"按钮文字用两号字或者三号字"这条术，但你不一定能判断"用户在这个表单页面里，最需要的是减少视觉噪音还是加强视觉引导"。后者需要你对用户场景、心理状态和任务目标做综合判断，这就是道。
1.3 兰亭妙微为什么要用"术与道"来框架化UI设计知识
我自己也做了很多年知识梳理，一直没找到一个特别好的归类方式。要么太细，细到像一份组件文档；要么太抽象，抽象到没法落地。兰亭妙微这套框架最打动我的地方，是它给了知识一个明确的归属地。
任何一个你遇到的UI设计问题，都可以先问自己：这是一个"术"的问题，还是一个"道"的问题？如果是术的问题，去查规范、查组件库、问开发同事，很快就能解决。如果是道的问题，需要回到用户场景里，重新理解一下这个界面的目标和约束。
这样分类的最大好处，是让你的学习变得有方向感。每次遇到一个设计决策，你都知道该调取哪一层知识，而不是什么都从头开始想。这也是这篇文章想做的事：把术和道的各个模块展开，铺成一份可以对照自己知识储备来看的清单。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 道之层：移动应用UI设计的底层认知体系
2.1 设计的第一性目标：帮用户完成任务，而不是美化界面
这是整套"道"的最底层。很多新人设计师对UI设计的理解是"把界面画好看"，但好看从来不是目的，而是一个副产品。你做一个移动应用界面，唯一的目标是让用户能高效、顺畅、无压力地完成他想要完成的任务。如果任务完成得顺畅，用户的感受就是"好用"；如果整个过程很体面、很连贯，用户的感受才上升到"好看"。
这带来一个很直接的实践转变：设计之前，先不要打开Figma、Sketch或者即时设计，先写清楚这个页面要解决什么任务。写不出来的页面，大概率是一个不该存在的页面。我在做需求评审的时候，遇到很多页面其实是从其他竞品身上"拆"过来的——别人有个人中心，我们也得有个个人中心；别人做了会员页，我们也做。但拆过来的东西没有结合自己产品的用户任务，做出来就是一堆无关元素堆在界面上。
兰亭妙微的框架里有一个很重要的说法：每一个页面都要有"一个核心任务+一个次要任务+零个或一个辅助任务"。超过这个数量，页面就会开始"失焦"。我在实际项目里验证过，这句话真是一针见血——很多老板"喜欢内容丰富"，但内容一旦超过用户能处理的量，用户就会直接退出。
2.2 移动场景的六大约束：屏幕、拇指、注意力、网络、系统差异、碎片时间
做移动应用UI设计，和做网页设计、做平面设计，最大的区别就是你要在一个充满约束的环境里做设计。这些约束是"道"层最重要的组成部分，因为每一条都直接影响设计决策。
第一，屏幕小。小到你不能像网页那样铺很多信息，你必须做取舍。取舍的依据不是"用户可能想看"，而是"用户此刻最需要什么"。手机屏幕一般就这么大，一屏里能稳定容纳的信息大概就是4到7个模块，你每多加一个模块，其他模块的注意力都会被稀释。
第二，拇指操作。大部分用户是单手拿手机的，拇指能够到的范围就是一个热区图。重要操作放中间偏下，而不是很多设计师习惯放的右上角。你在坐地铁的时候观察一下周围的人，绝大多数是单手握持、拇指滑动，这个姿势决定了你的主要操作不应该被放到屏幕最顶端。
第三，注意力碎片化。用户打开App的时候，脑子里往往还有其他事。你的界面必须能在2到3秒内让用户知道"这里是干什么的、下一步该做什么"。如果用户进来之后需要花时间去"理解"界面，他大概率会直接退出。
第四，网络不稳定。移动端请求接口可能失败、可能慢、可能弱网。你的界面要设计加载态、空态、失败态，且这些状态本身也要好看、好用。很多设计师只画了"理想状态"的界面，结果开发的时候遇到网络问题就只能自己随便拼一个原生弹窗，整个设计品质就从这里开始崩坏。
第五，系统差异。iOS和Android有不同的导航习惯、返回方式、手势体系和视觉语言。设计一套界面能同时适配两边的操作习惯，需要你在"道"的层面理解平台差异的本质，而不是机械地套两套规范。比如iOS的返回手势是从屏幕左缘右滑，Android的返回方式是底部手势或系统返回键，这个差异会影响你的页面层级设计——过度依赖左缘返回手势，在Android上就会让部分用户感觉"被困住了"。
第六，碎片时间。移动应用的大部分使用场景是"等电梯、排队、睡前"这种碎片时间。你的信息架构要让用户能在很短的时间内进来、完成操作、退出，不迷失。如果一个流程需要用户投入连续十分钟的专注，这个设计就需要重新考虑。
这六大约束不需要你每条都背下来，但你在做每一个设计决策的时候，都应该下意识地问一句：这个界面放到真实场景里，用户能顺利完成任务吗？如果能，你的设计就成功了一半。
2.3 信息架构与心智模型：用户凭什么知道这个按钮能点
很多UI设计问题，表面上是视觉问题，实际上是信息架构问题。用户在一个页面上找不到按钮、不知道怎么返回、不理解某个图标代表的含义——归根结底是他的心智模型和你的设计模型不一致。
心智模型这个词听起来玄，其实很好理解：用户在使用你的App之前，已经通过微信、淘宝、美团、支付宝这些高频应用建立了一套对移动应用应该如何工作的预期。他知道底部Tab一般有三到五个，知道设置通常放在个人页的右上角或者列表最下方，知道带有下划线的文字可以点击。你没必要重新发明这些交互范式，你要做的是遵循用户的已有预期，然后在需要差异化的地方做出差异化。
这里有一个常见的误区："我要设计出一个别人从没见过的交互方式，这样才能体现创意。"但实际上，移动应用UI设计领域，绝大多数情况下"不打扰"才是最好的创意。用户的注意力应该放在任务上，而不是放在"理解你的界面"上。
我之前做一个企业级应用的后台改版时，客户要求"把菜单做成一个创新的扇形手势交互"。我跟他们讲了一个很简单的逻辑：你的用户每天要在这个系统里处理几十条审批、查阅几十份报表，他要的是"快"，不是"炫"。扇形手势听起来酷，但用户每次使用都要停下来回忆"菜单在哪里、怎么呼出"。后来我们保留了传统的侧边栏加底部Tab布局，用户调研反馈满意度反而大幅提升。
还有一个跟信息架构强相关但经常被忽视的点：文字的层级。很多设计稿里，字号大小、字重变化都没什么问题，但信息之间的关系没有拉开。比如页面上同一个层级的信息，有的用主标题字号，有的用正文字号，有的用辅助字号，用户看的时候就会困惑"到底哪个是重点"。信息架构不只是页面的模块布局，还包括文字系统、色彩系统和图标系统的层级一致性。
3. 术之层：从组件到交付的移动端UI技能链
3.1 组件化思维：先学会搭积木，再学会造积木
到了"术"的层面，最核心的思维是组件化。移动应用界面，说穿了就是几种组件的排列组合：导航栏、列表、卡片、输入框、按钮、弹窗、标签、底部操作栏、图表……你先要熟练使用这些积木，才能谈得上设计。
组件化思维的第一个好处是效率。当你的团队沉淀了一套组件库之后，做新页面不是从零开始画，而是从组件库里调取、组合、调整。开发那边也同样用组件去还原，两边用同一套语言沟通，返工率会明显下降。我在一个做了三年的项目里，后期基本不需要再重复造轮子，新功能页面的设计时间可以压缩到原来的三分之一。
组件化思维的第二个好处是质量稳定。你可以把一套经过充分测试的设计模式沉淀为组件，每次使用的时候就不用重新设计、重新踩坑。比如弹窗的按钮排列、表单校验的样式、空态插图的风格，这些都是一次设计、反复使用的资产。
这里我特别想提醒一点：组件化不意味着设计同质化。组件库是地基，品牌调性是在这个地基上长出来的。同样的一个列表组件，你换一套间距体系、一套图标风格、一套色彩策略，出来的视觉感受完全不同。用组件库省下来的时间，应该花在打磨品牌差异和关键体验细节上，这才是一个成熟设计师该做的事。
3.2 设计规范落地的关键细节
说到组件，就绕不开设计规范。做移动应用设计，业界有两大参考体系，一个是Apple的Human Interface Guidelines（HIG），一个是Google的Material Design。这两个体系不只是给你一套颜色、字体、间距的建议，它其实是两位"站在更高视角的设计团队"替整个行业把很多道层的问题翻译成了具体的术层规则。
但我想强调一点：规范不是用来"照抄"的，而是用来"理解后批判性使用"的。比如HIG建议导航栏标题用大标题，但这个建议的使用场景是浏览型页面；如果你的页面是一个表单填写页，用户需要保持沉浸，大标题反而会分散注意力。你要能判断什么时候该守规范，什么时候该偏离规范。这个判断能力，恰恰就是你"道"层知识的体现。
落地的时候还有几个实际细节容易被忽略。
首先是字号适配。iOS上要支持动态字体（Dynamic Type），让用户根据自己的阅读习惯调整系统字号，你的界面要经得起"最大字号"和"最小字号"两种极端情况下的布局检验。Android上类似的是字体缩放（Font scale）。很多设计稿在小字号下看着没问题，一放大字号文字就溢出，这是典型的"没有考虑动态字体"的问题。
其次是触控目标尺寸。Apple官方建议的触控区域最小是44x44pt，Android是48x48dp。这个尺寸不是随便定的，它来自成年人的平均指腹面积和手指操作精确度的研究。很多设计师做界面时只关注视觉美观，把按钮做得很精致但很小，用户点起来非常吃力。尤其是那种"小图标"操作——编辑、删除、分享——实测中是最容易误触的地方。
再次是安全区适配。刘海屏、挖孔屏、圆角屏幕，每一块屏幕的安全区都不一样。设计稿里至少要标注出左右安全边距和底部Home Indicator区域的避让逻辑，而不是只画一个"理想矩形"。
最后是列表页的设计。不要小看列表页，它是移动应用里最常见的界面形态。Windows系统里那种传统的多列列表，在移动端你需要重新思考：一屏能显示多少行？行高多少最合适？左对齐还是右对齐？缩略图和文字的布局优先级是什么？这些都直接决定用户浏览和点击的效率。
3.3 交付环节：从设计稿到开发的沟通质量决定还原度
很多设计师觉得设计做完就完事了，其实从设计稿到真正上线，中间还有很长一段路。交付环节做好了，你的设计才能被完整地还原；做不好，再好的设计也会在开发过程中变形。
交付的第一步是准备设计稿。命名要规范，图层要整理清楚，关键交互要写清楚状态变化。我见过太多设计师的命名是"矩形 23""副本 5"，这种命名方式等于把自己设计的可维护性直接扔掉了。你交付的不只是几张图，而是一套"未来可能要迭代"的设计资产。建议命名的时候用"模块_组件_状态"这样的格式，比如"home_banner_default""profile_avatar_edit"，开发拿到之后也能快速对应到代码里的组件名。
交付的第二步是做设计走查。界面开发完成后，拿着设计稿逐屏对比。这里有一个我自己的习惯：我会按照用户在真实场景中的操作路径走一遍，而不是只对着静态稿看颜色、间距。因为很多对不齐、层级错乱的问题，只有交互起来才会暴露。比如点击按钮之后的反馈状态、加载中的转圈样式、网络异常时的提示文案，这些静态稿里容易忽略的部分，要在动态走查里逐一确认。
交付的第三步是建立反馈机制。不要等到上线前才去检查，最好在开发中期就约一次走查。这个阶段调整成本低，沟通成本也低。等开发全部做完了再提修改，所有改动都显得"伤筋动骨"，很多合理的问题反而会被用"时间来不及"劝退。
这里还想提一个很多团队容易忽略的事：设计稿的版本管理。项目迭代起来之后，设计稿的迭代速度非常快，如果没有统一的版本管理，很容易出现"你以为你改了，但开发拿到的还是旧版"。我现在的做法是每次修改都在文件名里标注日期和版本号，重要改动在聊天记录里留一条"以XX版为准"的说明。看起来多花了几秒钟，但能省掉后面大量的扯皮。
4. 道术合一：一个移动端界面从0到1的完整推演
4.1 需求阶段：用"道"重新定义问题
我把前面那些理论用实际例子串起来。假设产品经理提了一个需求：做一个"还款提醒"功能页面，用户登录后能看到自己的还款计划、每期金额、还款状态，并且能设置还款提醒方式。
大部分设计师拿到这个需求，会直接开始画界面。但如果按"道"来思考，你首先要做的是重新定义问题。
场景是什么？用户大概率是在"快到还款日"或者"心里有点不踏实"的时候打开这个页面。他的注意力是焦虑的、急切的，他第一眼想看的是这个月还多少钱、什么时候还、现在状态怎么样。
任务是什么？确认信息、按状态采取行动（设置提醒、立即还款）。这个页面不是用来浏览的，是用来确认和操作的。
情感诉求是什么？还款是用户不想面对但必须面对的事，好的设计要降低他的心理负担。你要让信息清晰直接，不要用复杂的视觉形式去制造额外压力。比如不要用大面积的警示色块去强调欠款，用中性的橙黄色提示"待还款"就够了。
这样推演下来，"道"层面的设计方向就很清晰了：核心信息前置、操作路径短、视觉表达冷静克制、状态区分明确。
这个阶段还有一个动作很重要：跟产品经理确认"用户最常用路径"。如果产品数据告诉你，70%的用户是来"确认还款金额"的，那这个页面就要以"金额+日期"为核心来设计；如果数据告诉你，50%的用户是来"设置自动还款"的，那设置入口就要前置。没有这个数据支撑，你的设计就只是猜。
4.2 设计阶段：用"术"把判断落到每一个界面元素上
需求方向定下来之后，就轮到"术"的落位了。模块怎么排？我建议按"核心信息-操作入口-辅助信息"三层来组织页面结构。
第一层，核心信息区。当前状态用一个大卡片放在页面顶部，卡片上用清晰的数字显示"本期应还金额"，旁边标注还款截止日。这个卡片是页面的视觉锚点，用户一进来就能看到自己最关心的东西。卡片背景可以用品牌色的浅色渐变，字体用最大的数字字号，前后留白要足够大，制造"一眼就能看到"的视觉重心。
第二层，操作入口。还款按钮和设置提醒按钮，这两个操作要放在拇指容易触达的区域。我的建议是还款按钮用主题色、高优先级展示；设置提醒用次要样式，因为提醒设置是一次性的低频操作。按钮的位置放在卡片下方，或者用底部固定操作栏的方式，保证用户在滚动页面后也能随时触发。
第三层，辅助信息。还款计划明细列表、历史还款记录、常见问题。这些从"确认"角度不是最关键的，但用户如果往下翻能看到，会感到安心。它们的存在提高了页面完整度，但一定不能抢占视觉重心。
组件层面也要对应调整：状态标签上，未还款用中性的灰色、已还清用绿色、逾期用警示橙。字重和色彩不能乱用——每个状态只有一种对应的视觉表达，用户才能形成条件反射。字体层级上，金额是最大的信息，要用大号数字字体，其他文本依次降级。列表中的每一项间距建议保持8pt的倍数关系，这样视觉节奏感才会稳定。
这里还涉及一个很细节的决策，关于列表页的呈现方式。还款计划明细如果条目数少（比如只有三五条），直接用卡片列表展示就好；如果条目数多（比如十二期、二十四期），用"年-月-金额"的折叠分组更合适。用户不一定要一次性看到全部条目，他只需要能快速找到自己目标的那一期。
我特别想提一个设计稿之外的细节：状态设计。工程师在开发接口时，会给出"加载中""接口异常""空数据"等状态场景，很多设计稿里没画。你的设计稿交出去，其实只交付了"理想状态"的界面，这远远不够。我自己的做法是，每个关键页面至少补上加载态、空态、失败态三个版本。加载态是骨架屏或者是轻量的加载动画，空态要说明"当前没有内容"并且给出用户下一步可以做什么，失败态要友好并且提供"重新加载"的入口。这个习惯会让你在开发阶段少很多沟通成本，也会让你的设计品质在所有场景下保持一致。
4.3 验证阶段：怎么判断方案到底行不行
设计完成后，怎么判断方案行不行？我的做法是回到"道"的层面，模拟用户视角问自己三个问题。
第一个问题，用户3秒内能不能明白这个页面怎么用？如果不能，说明信息层级的组织有问题。我之前做过一个测试，把一个设计稿拿给完全不了解项目背景的同事看3秒钟，然后问他"你觉得这个页面是干嘛的"。如果他说不清，就说明页面的第一视觉重心没有搭对。这个问题很好用，强烈推荐大家试试。
第二个问题，用户的核心任务能不能在两步以内完成？还款任务里，如果用户在首页不能直接进入还款流程，需要先点击"账单详情"再找"立即还款"，就多了一步。移动端每多一步，转化率都会掉一截。这个我需要再强调一遍：不要你觉得步骤清晰就够了，要模拟用户真实的使用状态——单手、赶时间、可能还在走路——在这种状态下步骤越少越好。
第三个问题，去掉所有装饰性元素，核心信息还在不在？如果不在，说明你依赖视觉装饰在传达信息，这不是好设计；如果在，说明你的信息结构是健康的。这是一个非常有效的"去装饰"测试，我曾经在一个改版方案里，把图标、插画、背景纹理全部去掉，只留下文字和按钮，结果发现页面的核心路径依然清晰，这就证明方案的骨架是成立的。
这三个问题都通过了，设计方案的"道"的部分就没有大问题。剩下的就是"术"层面的细节打磨：间距、对齐、颜色、动效节奏。细节打磨不靠灵光一现，靠的是你平时积累的组件库和规范。我自己的习惯是每次打磨前后各截一张图存起来，过一个月再看，就会发现自己当时的判断边界在哪里。这也是成长最快的方式之一。
5. 知识框架的自我进化：建立UI设计师的成长闭环
5.1 输入：怎样从日常工作中沉淀体系化知识
知识框架不是一次建成的，它需要你持续往里填充内容。填充的前提是，你要有一个明确的归档逻辑。我自己的做法很简单：手机里建了一个备忘录，名字叫"设计问题库"。每次在项目里遇到一个自己没把握的设计决策——比如弹窗到底用模态还是非模态、表单校验是输入完再提示还是失焦再提示——我都会记下来，并写上我当时的选择和理由。
过一两个星期再回头看，有些记录已经过时了，因为你已经找到了更好的解法；有些记录还在反复出现，说明那是一个真正值得深入研究的点。这样你就能把日常工作里的零散问题，逐渐沉淀成一个属于你个人的、有优先级的、不断更新的知识清单。这个过程不需要额外的时间成本，只需要你在每次做完一个设计决策后花30秒写一句话。
不能只从自己的工作里学。我也建议大家每个月固定花一点时间做"竞品拆解"。选一个你生活里常用的App，想办法找到历史版本的截图，看看它从一版到最新一版，界面为什么要这样调整。版本演进里藏着很多产品决策和设计决策，是学习"道"层判断力最好的素材。比如你现在去看主流App的底部导航设计，会发现很多产品从"五个Tab"缩减到"四个Tab"甚至"三个Tab"，因为他们发现Tab太多会导致用户注意力分散，核心功能的曝光率反而下降。这种观察，比读十篇文章都更有说服力。
还有一点很关键：要去看那些高端的、企业级的UI设计案例。很多人平时只看C端消费类App，一遇到政务、金融、企业服务这些项目就不知道怎么做了。其实这些项目更考验设计规范的严谨性。跟C端产品可以走"感性创意"不同，这类项目要求的是绝对的一致性和可用性，每一个组件、每一种颜色、每一个间距都要有明确的规则来约束。建议你日常也留意一下政府、企业级应用的设计案例，研究它们是怎么在"审慎"和"可用"之间找到平衡的。
5.2 输出：用复盘和沉淀反哺设计能力
知识框架的价值，不只在输入，更在输出。我自己的经验是，能把一个设计决策讲清楚，说明你真的想明白了。讲不清楚的，大概率只是运气好做对了。
所以我特别建议大家养成"设计复盘"的习惯。复盘不需要长，一个项目做完之后，写三五句都行，核心是回答三个问题：这个设计里我做的哪一个决策是真正有效的？哪一个决策如果重做我会改变？我从这个项目里学到的可迁移经验是什么？
这三句话写下来，比你看十篇文章都有用。因为它逼着你去审视自己的设计过程，而不是停留在"做完了""上线了"的结果里。很多时候你会发现自己当时的某个决策其实是"跟着感觉走"的，并没有足够的依据。这种复盘一次两次没有感觉，坚持做一年，你对设计的掌控感会明显不一样。
如果你有精力，可以把复盘整理成文章发出来。写作会让你不得不把模糊的判断翻译成语言，翻译的过程就是再一次梳理知识框架的过程。我自己很多原本模模糊糊的设计认知，就是在写作的过程中变得清晰的。这也是为什么兰亭妙微的《术与道》是一篇"解读"而不是一份"笔记"——解读意味着你用自己的话重新组织了知识，而笔记只是被动地搬运了知识。
5.3 一些坚持做下来的个人习惯
最后分享几个我个人认为特别值得坚持的习惯。
第一，每周固定时间看规范更新。HIG和Material Design都会不定期更新，每次都带着"为什么这样改"的问题去读，不要停留在"规范变了"的表层。你可以留意到它在推动整个行业往哪个方向走——比如系统级深色模式的普及、动态字体和辅助功能的强化、跨设备连续互动的推进——这比单纯看规范本身更有价值。
第二，练习"无网设计"。拿到一个设计需求时，先不打开任何参考网站，先凭自己的知识框架把方案做出来。做得不顺的地方，恰恰就是你知识框架里的空白点。记录下来，做完之后再去看参考，你会对自己的判断边界有非常清晰的认知。这个方法很折磨人，但是真的有效。
第三，多跟开发聊。很多UI设计问题，其实是你不知道前端实现的方式。你理解了开发那边的约束之后，你设计出来的界面不仅还原度高，而且能被开发主动地维护。比如你知道了某个弹窗在Android上需要处理返回键逻辑，你就会在设计阶段就考虑好"用户按返回时应该关闭弹窗还是返回上一页"，而不是等到开发阶段再临时定义。
第四，保持"看界面"的习惯。看到任何一个界面——不管是手机App、电脑软件还是街边的自助取款机——脑子里都问一句：它为什么这样设计？如果是我会怎么做？这个习惯一旦养成，你的知识输入效率会翻倍。有时候在咖啡厅等人的功夫，翻几个App的界面，就能收集到三五个可以放进自己"设计问题库"里的案例。
也有人问我，怎么看待移动应用引擎、跨端框架、AI设计工具这些"新东西"？我的看法是：工具永远是"术"层面的东西，一个再新的工具，学一下也就会了；反而是"道"层面的用户理解、场景判断和设计原则，这些不会因为工具变化而失效。所以与其焦虑自己的工具被淘汰，不如把更多的精力放在"道"的积累上——做一个能从底层认知出发判断设计好坏的人，比做一个只会操作软件的人，在任何时代都更稀缺。