企业官网建设流程全解析

做UI这些年，电脑里一直躺着一个叫“参考”的文件夹，每隔一阵子就会翻一遍，把过时的删掉，把新看到的补进去。这次挑出来的5款app界面UI设计实例，是我最近半年反复打开、也反复推荐给同行看的作品。它们不在同一条赛道，有运动记录、视频剪辑、金融工具、阅读器，还有一款做桌面小组件的工具类产品，但共同点是：屏幕上几乎找不到一个纯粹“为了好看”而存在的元素。每一个圆角、每一层灰阶、每一次点击后的反馈，都能倒推出设计者在解决什么问题。我把它们逐一拆开，讲讲这些界面背后的思路、可以直接复用的参数，以及我自己在照着做的时候踩过哪些坑。不管你是刚入行的新人，还是已经带过几个项目的老手，应该都能从中捞到点能立刻用上的东西。

1. 这5款App是怎么选出来的

1.1 筛选标准：三个“不”

我挑案例有一条很土的规矩——先看缺点，再看优点。一个界面如果只靠酷炫的动效和大图撑场面，点进去两层就露馅，那它进不了这个名单。具体来说，我用三个“不”来卡：

第一，不靠插画和摄影图撑门面。把首页那些精美的插画全撤掉，换成纯色块和文字，如果信息结构依然清晰，说明它的骨架是硬的。很多所谓的“高质量UI”一旦去掉装饰就原形毕露，说明设计师实际上是在做海报，不是在做界面。

第二，不靠“首创交互”来博眼球。喜欢搞些反直觉手势、隐藏入口的产品，短期看很新鲜，长期看用户留存会掉。真正高质量的设计往往是把行业里已经验证过的模式执行到位，而不是标新立异。所以这5款里没有一个需要看教程才能用的。

第三，不牺牲极端场景。把系统字体调到最大、把语言换成德语、把网络断掉，界面还能不能用？这是我很看重的一条。有些作品在主流程上漂亮得不行，但一遇到长文本、弱网、大字号就崩。愿意为这些边角场景花心思的团队，通常整体水准都不会差。

另外一个现实原因是，这5款产品背后的团队规模都不大，实现方式对个人开发者和小团队有参考价值。你不太可能去复刻一个大厂几千万预算的视觉系统，但把这5个界面里的成熟做法照搬过来，是完全可以落地的。

1.2 拆解一款界面时我通常看什么

很多人看优秀作品是“整体扫一眼，觉得舒服，收藏”。这样其实学不到东西。我的习惯是分四层去看，顺序固定：

• 结构层：先看首屏有几个信息区块，哪些是主，哪些是次，用户第一眼必须拿到什么结论。
• 布局层：看栅格和间距。左右安全边距是多少，卡片之间的间距是不是同一个倍数，标题到正文的距离是不是稳定。
• 视觉层：看色彩系统、字阶、圆角、阴影。这里我会把颜色值直接吸出来，记在笔记里。
• 反馈层：点一下按钮、下拉一次、滑一个卡片，看有没有状态变化，变化持续多久，有没有“跟手”。

这四层里，最容易被忽略的是第四层，但它恰恰是用户“觉得这个App高级”的主要来源。视觉再好，点击后延迟半秒才有反应，用户潜意识就会判定它粗糙。而反馈层的东西，在静态截图里完全看不出来，这也是为什么很多人照着一张图临摹，做出来的东西总是差一口气。

下面进入正题，一个个来。

2. 案例一：运动记录App——把满屏数据压成一条主线

2.1 首屏信息架构：先给结论，再给细节

运动类App的通病是数据太多：步数、距离、配速、心率、卡路里、爬升、训练负荷、周目标、月度趋势……设计师一激动就会全部铺在首页，结果用户打开App的第一感受是“累”。

这款产品的做法很克制：首屏只留一个核心数字，就是当天的主目标完成度，比如“已完成 82%”，用超大字重呈现，占掉屏幕上半部分的视觉重心。下面紧跟一条横向进度条，再下面是三个次级数据块，其他所有指标都收进“详情”页。用户打开App，三秒内能得到一个结论——“我今天练得够不够”，这就够了。

这个思路叫结论前置。用户打开一个数据类App，绝大多数时候不是来做分析的，是来确认状态的。你要在最短时间内回答他心里那个问题，而不是把数据库倒给他。实际做的时候，判断“哪个数字是结论”很简单：问自己，如果用户只能看到一个数字，他会选哪个？那个就是首屏的主视觉。

次级信息我一般按“今天—本周—趋势”三段式排布，这是个很稳的模板。今天的数据解决即时焦虑，本周的数据给一个小目标感，趋势图满足长期成就感，三块信息对应三种心理需求，顺序不要乱。

2.2 数据可视化：图表不是越花越好

运动App里的图表主要有三种：环形进度、柱状对比、折线趋势。这款产品在图表上的克制值得单独说。

环形进度只用单色，不搞渐变叠加，因为渐变色在细环上很难读出准确进度。柱状图统一高度上限，避免某一根柱子特别高把其他都压扁——这点很关键，很多团队的周数据图因为有一天暴走了，导致其他六天看起来都是零，这属于图表在说谎。折线趋势图默认不显示网格线，只在纵轴放三个刻度值，减少视觉噪音。

配色上，运动数据通常需要一个高饱和主色做强调，比如橙红或亮青，其余全部用中性灰阶。这里有个容易犯的错：把“心率区间”“配速区间”做成五颜六色的分段色带，看起来专业，实际上大部分用户根本记不住哪段对应哪个颜色。更实用的做法是只用两种颜色区分“达标”和“未达标”，把复杂度交给详情页。

2.3 可直接抄的参数清单

我自己照着做的版本，参数如下，实测在1080宽的安卓机上效果稳定：

这里有两个点值得展开。第一，主数字用48sp，但在系统字体放大到1.3倍时，它会挤掉下面的进度条，所以必须给主数字容器留出足够的高度，或者用自动缩放。我试过给主数字设固定高度然后用autoSizeTextType之类的方案，效果比直接截断好得多。

第二，卡片间距12dp小于内边距16dp，这是故意的。卡片内部的元素属于同一组，间距自然要小于卡片与卡片之间的距离，这样分组关系一目了然。如果反过来，卡片内边距10dp、卡片间距10dp，整个界面就会糊成一片，用户分不清哪里是分界。这个“组内间距小于组间间距”的原则，看着像废话，但我review过的稿子里至少三成犯了这个问题。

3. 案例二：视频剪辑App——把专业工具塞进手机屏幕

3.1 时间轴与预览区的比例之争

手机屏幕就那么大，视频剪辑又必须同时展示预览画面、时间轴、工具面板三块内容，这是硬约束。这款App的解法是把屏幕按“预览 45% / 时间轴 30% / 工具面板 25%”切分，预览区始终固定，时间轴可以纵向拉伸一点，工具面板做成可横向滚动的一排图标。

为什么预览是最大的？因为剪辑的时候，用户 80% 的注意力在画面上，时间轴是辅助定位的。有些产品为了显示更多轨道，把预览区压到30%以下，结果用户看不清自己剪的是什么，只能反复放大，体验很糟。

时间轴这块有个细节值得学：它的轨道高度是固定的，但缩放比例是动态的。捏合手势改变的是“每秒占多少像素”，而不是轨道本身的高度。这样做的原因是，轨道高度一变，视频缩略图的宽高比就乱了，用户会失去空间感。保持高度、改变密度，是视频时间轴交互里比较稳妥的方案。

3.2 工具面板的渐进式披露

剪辑工具太多了：分割、变速、倒放、滤镜、转场、字幕、贴纸、音频、调色、画中画……如果全部平铺，就是一堵图标墙。这款产品的处理是分三层披露：

第一层是常驻的四个高频操作，固定在屏幕底部，任何时候都能点到，包括分割、撤销、播放、导出。第二层是横向滚动的一级工具图标，大概十二个，按使用频率排序。第三层是点击某个工具后弹出的参数面板，比如点了变速，才出现0.25x到4x的滑块。

这个设计的关键在于，用户永远只需要在一屏里做一次选择。先在“用哪个功能”上做决定，再在“参数调多少”上做决定，两个决策分开，认知负担就降下来了。反过来，如果把功能图标和参数滑块放在同一屏，用户要同时处理“选什么”和“调多少”，操作会变得手忙脚乱。

参数面板的弹出方式也讲究：它不是全屏覆盖，而是从底部升起一块高度约 40% 的抽屉，上面依然能看到预览画面。这样用户调参数的时候，眼睛不用离开预览区，实时看到效果。这是剪辑类App和普通表单类App在设计逻辑上最大的差别——反馈必须即时可见。

3.3 动效与手感：为什么拖动要“跟手”

剪辑App的“高级感”一半来自跟随手感。所谓跟手，就是手指移动多少像素，内容就移动多少像素，中间不能有插值动画，不能有延迟。这个在实现上要求拖动过程不触发动画，只有松手后才用缓动归位。

我自己测量过，从手指按下到画面开始跟动，超过 100ms 用户就能明显感知到“迟钝”。安卓上常见的问题是拖动事件里做了复杂计算，导致掉帧；iOS 上则是手势和 scrollView 冲突，需要额外处理。

参数方面，松手后的归位动画用 250ms，缓动曲线cubic-bezier(0.4, 0, 0.2, 1)。页面之间的转场用 320ms，进场用cubic-bezier(0, 0, 0.2, 1)（先快后慢），退场用cubic-bezier(0.4, 0, 1, 1)（先慢后快）。这套组合我在多个项目里用下来，观感比较自然，不飘也不拖。

还有一个细节：拖动时间轴上的播放头时，播放头本身要有一个放大效果，从 14dp 的圆点变成 20dp 的圆点，同时预览画面同步跳帧。这个放大动作看着不起眼，但它给了用户“我抓住了它”的确认感。几十毫秒的视觉反馈，换来的就是操作确定性的提升。

4. 案例三：金融工具App——界面如何传递“可信”

4.1 数字排版是金融App的门面

金融类界面里，数字的排版权重远高于文字。这里面有几个硬性要求：数字必须等宽，小数点必须对齐，千分位必须有分隔，正负号必须有颜色区分且不能只靠颜色。

等宽字体这件事，很多团队会忽略。如果用的是普通比例字体，那么“1”占的宽度比“8”窄，一列金额排下来就会参差不齐，滚动的时候数字会左右跳动，观感极其廉价。解决方式要么用等宽字体（如 Roboto Mono、SF Mono），要么用支持font-variant-numeric: tabular-nums的字体特性，后者更省事。

小数点对齐，靠的是把整数部分和小数部分分开渲染，小数部分用更小的字号和更浅的颜色。比如“1,234.56”，整数部分 28sp、深色，小数部分 18sp、次级灰。这样用户扫一眼就能主要读整数位，同时又不会丢掉精度信息。这是我从这款产品里学到的最实用的一个技巧，后来在好几个项目里都用了。

颜色使用上，涨幅用暖色、跌幅用冷色是常见的行业惯例，但必须配箭头图标或正负号，因为有色觉障碍的用户占比并不低。只靠红绿区分涨跌，属于把一部分用户直接排除在外。

4.2 安全感的来源：确定性反馈

金融类App的用户心理很微妙，他们对“不确定”极其敏感。所以这类界面的设计目标不是炫技，而是让用户每一步都知道“发生了什么、接下来会怎样”。

这款产品做了三件小事：

• 任何提交按钮点击后，立刻进入 loading 状态，按钮文字变成“处理中”，并且禁止重复点击。这不是为了防止重复提交，主要是让用户知道系统收到了。
• 金额输入时，输入框旁边实时显示大写金额，减少输错位数的概率。
• 关键操作完成后，不是弹一个 toast 就完事，而是进入一个独立的结果页，明确写清楚操作时间、金额、状态，并给出“查看详情”的入口。

第三点尤其重要。toast 的问题在于它会消失，用户想再确认一次就得重新翻账单。而结果页是一份“凭证”，它的存在本身就是一种安全感。做金融类界面的人常说，界面上每一个“确定”的确认，都在积累信任；每一次含糊，都在消耗信任。

4.3 一个细节：金额输入框的实现思路

金额输入框看起来简单，坑却不少。我在实现的时候总结了几个要求：

输入框只允许数字和一个小数点 小数点后最多两位 整数位最多支持若干位，超出时禁止继续输入而不是截断 删除时先删小数位，再删整数位 输入过程中不自动补零 失焦时才做格式化（加千分位）

顺序很重要。如果输入时就实时补千分位，光标位置会乱跳，用户删一位之后光标跑到末尾，体验很糟。正确做法是聚焦状态下显示原始数字，失焦后再格式化。这个细节在开源社区里有不少现成的实现可以抄，没必要自己从零造。

另外键盘类型也很关键：金额输入必须唤起带数字和小数点的键盘，而不是普通九宫格。这类小地方看似无关紧要，但它决定了用户输入三笔账之后愿不愿意继续用。

5. 案例四：阅读类App——排版本身就是产品

5.1 字号、行高与字距的黄金组合

阅读类App的设计几乎全部押在排版上，别的都可以省，排版不能省。这款产品的正文字号是 17sp，行高 1.65 倍（约 28sp），段间距等于行高的一半（14sp）。这个组合我实测过，在6.7英寸屏幕上，一行大约容纳 20 到 22 个中文字，是比较舒服的阅读密度。

行高这里有个经验值：中文正文行高在 1.6 到 1.8 之间，低于 1.5 会显得压抑，高于 2.0 又会让人跳行。西文正文则稍紧一些，1.4 到 1.6 比较常见。中文字形方正、笔画密度高，所以需要更宽松的行距，这个差异不要照搬国外的规范。

字距则要看字体。系统默认字体一般不需要额外调整字距，但如果用了某些偏紧凑的字体，加 0.02em 左右的字距会让文字呼吸感更好。反过来，如果字体本身偏松，再调大就散了。

5.2 夜间模式的正确做法

夜间模式最常见的错误是“把白底换黑底，把黑字换白字”。这样出来的效果往往是刺眼的纯黑配纯白，对比度过高，长时间阅读眼睛更累。

正确的做法分三层：

• 背景不用纯黑，用 #121212 到 #1A1A1A 之间的深灰。纯黑在OLED屏幕上会有拖影感，而且在深灰背景上才能体现出层次。
• 正文文字不用纯白，用 #E0E0E0 左右。纯白在深色底上对比度达到 21:1，属于过曝级别。
• 主色要降饱和。白天用的高饱和蓝，在深色背景上会非常刺眼，需要把亮度提高、饱和度降低，换成更柔和的版本。

顺便说个对比度的计算，公式是(L1 + 0.05) / (L2 + 0.05)，L 是相对亮度。白底上常见的中灰 #999999，算出来对比度大约 2.85:1，远低于正文要求的 4.5:1，所以这种灰只能用在装饰性文字上。而 #333333 在白色上算出来大约 12.6:1，用作正文完全没问题。我遇到不少稿子用 #999 当正文色，然后在用户反馈里被抱怨“看着累”，根子就在这里。

5.3 字体设置与系统大字的兼容

阅读类App一定要给用户字号调节的入口，但更重要的，是要兼容系统级别的字体缩放。用户把系统字体调到最大，说明他视力可能确实有障碍，这时候App里的小字不能还是原来的大小。

我踩过的坑是：所有字号都写死了，结果用户在系统里放大字体后，界面里只有少数几个用了系统缩放单位的地方变大，其他全是原样，整个布局变得乱七八糟。后来改成了全部用可缩放的尺寸单位（安卓用 sp，iOS 用 Dynamic Type），并且给关键容器设置了最小高度和可换行。

但也不能全盘交给系统。App 自己的字号调节和系统字号缩放如果叠加，会放得过大。我的处理是：App 内调节作为主控制，系统缩放作为辅助，最终字号取两者中的较大值，但设一个上限（比如正文不超过 30sp），超过就切到“超大字号布局”模式，减少每行字数、增加行距。

6. 案例五：桌面工具App——小组件与全屏适配

6.1 桌面小组件的尺寸约束

这款工具类产品除了主应用外，还提供了桌面小组件，实用度很高。做小组件的第一条规矩是：它只负责一秒能看完的信息。任何需要滚动、需要点击两次才能看到内容的方案，都不适合放在桌面上。

安卓的组件常见尺寸是 2x2、4x2、4x4 三档；iOS 那边则是小、中、大三种。设计的时候不要为每个尺寸单独画一套内容，而应该画一套“可伸缩”的内容结构。我通常的做法是分层：尺寸从大到小依次砍掉第三重要的信息、次要装饰、辅助文字，最后只剩一个核心数字和一个图标。

圆角也要注意。桌面小组件的圆角是由系统统一裁切的，你自己画的圆角如果和系统不一致，会出现“双重圆角”的难看效果。安全做法是内容四周留出足够的 padding，内部元素不要贴边，让系统的裁切去决定外形。

6.2 全屏模式的适配要点

工具类产品经常会遇到“全屏显示”的需求，比如演示、展示、看板场景。这里可以顺带说下 PC 端工具的界面设计，因为这类产品常常是用 Qt Designer 这类可视化工具搭的。

用 Qt Designer 做全屏，思路是：把主容器（centralwidget）的布局设置为铺满，内部的控件用 stretch 因子分配空间，并在代码里调用showFullScreen()或者设置窗口标志。有几个容易忘的地方：

// 主窗口全屏 MainWindow w; w.showFullScreen(); // 布局中让某个控件占据剩余空间 ui->horizontalLayout->setStretch(0, 1); // 左侧固定 ui->horizontalLayout->setStretch(1, 3); // 右侧占3份

第一，全屏后所有固定像素尺寸都要重新考虑，因为屏幕可能是 1080p 也可能是 4K。第二，去掉标题栏后，用户失去拖拽窗口的能力，所以界面里必须有一个明确的“退出全屏”入口，通常放在右上角，用图标而不是文字。第三，全屏状态下鼠标指针可能不常移动，所以悬停态（hover）要给足，让用户知道哪些元素是可点的。

移动端全屏还要处理刘海和手势条。安全的做法是用系统提供的安全区域变量（iOS 是 safeAreaInsets，安卓是 WindowInsets），给内容留出上下边距，别让重要信息被遮住。

6.3 代码化设计：用代码快速出原型

这几年我越来越倾向于“先用代码出原型，再回头补设计稿”。尤其在工具类产品里，交互复杂、状态多，用画图工具画的稿子根本表达不清楚中间状态，不如直接写一个能跑的原型。

具体做法是用一套声明式的 UI 框架，把界面拆成组件，数据用假数据塞进去，先把布局和动效跑通。这个过程的产物，本身就是一份可以交付的界面代码。对小团队来说，这比“设计稿 + 口头描述 + 开发猜”高效得多，因为所有参数都是确定的。

当然这也有前提：组件化要做得足够干净，样式要抽成可复用的变量，而不是把颜色值散落在各处。我见过不少团队拿页面当画布，一个界面写几百行样式，结果改一个主色要全项目搜索替换，那还不如老老实实画稿。工具本身没有高下，关键是产出物要能被维护。

7. 从5个案例里抽出的通用规范

7.1 8pt栅格与间距阶梯

这5款产品的界面，如果去量它们的间距，会发现基本都落在 4、8、12、16、20、24、32、48 这几个数上。也就是所谓的 8pt 栅格体系（允许 4pt 作为半个单位）。

为什么是 8？因为在大多数屏幕密度下，8 能被整数倍缩放，不会出现半像素模糊。更重要的是，它给团队提供了一套共同语言——设计师说“这里间距用 16”，开发不用问是哪两个元素之间，直接就知道是标准的中等间距。

我的建议是把间距阶梯限制在 6 档以内，太多了反而没有约束力。我常用的是 4 / 8 / 12 / 16 / 24 / 32，超过 32 的间距直接用屏幕百分比或者 flex 布局撑开，避免在大屏上出现诡异的留白。

7.2 色彩系统与对比度计算

色彩系统的搭建顺序是：先定一个主色，再由主色推导出一个强调色和一个深色变体；然后单独定义一套语义色（成功、警告、错误、信息），最后补齐一层中性灰阶，通常是 8 到 10 级。

中性灰阶是最容易被忽视的部分，但它决定了界面“高级不高级”。因为界面里 80% 的面积其实是灰的：背景、分隔线、次级文字、禁用态。灰阶没搭好，主色再漂亮也救不回来。

搭灰阶有个技巧：不要用纯灰（R=G=B），而是在灰色里掺一点点主色的色相。比如主色是蓝色，那么灰阶就带一点点蓝味。这样整个界面会显得更协调，而不是“彩色按钮贴在一块黑白画布上”。

对比度则要按场景卡死：

这三个数字是我每次验收界面都会抽查的，抽查方式也简单，把稿子转成灰度，看看还能不能读。如果转灰度后某些文字看不清了，说明它纯粹靠颜色区分，这在灰度打印、色盲用户、强光环境下都会出问题。

7.3 组件库与设计令牌

如果只做一个界面，用不着组件库。但只要产品要迭代，组件库就是省时间的唯一办法。这5款产品里，凡是长期维护得好的，背后都有一套稳定的组件库。

我现在的做法是维护一份“设计令牌”清单，把所有可变的视觉参数抽成变量：颜色、字号、行高、圆角、阴影、间距、动效时长。设计侧和代码侧用同一份令牌，命名保持一致。这样改一个主色，只需要改一处。

命名上我推荐语义化而不是描述化。color-primary比color-blue好，因为哪天主色从蓝改成绿，前者不用改名，后者就尴尬了。同理，spacing-md比spacing-16好，因为数值可能会调整，语义不会。

组件库还有一条隐性收益：它让新人上手更快。一个界面该用哪个按钮样式、哪种卡片，在库里都有现成的，不需要重新决策。减少决策次数，就是在提高整个团队的产出效率。

8. 常见问题与排查实录

8.1 问题速查表

下面这张表是我在还原这些界面时，真正遇到过的问题和对应的排查方向，都是实打实踩出来的。

关于app is not defined这类报错，说一个经验：它九成不是 UI 层的问题，而是变量作用域或者模块加载顺序的问题。排查的时候别急着改样式，先在控制台确认那个变量到底有没有被定义、是不是被包裹在了局部作用域里。这类问题的特点是，报错位置和真正的原因位置往往隔着好几十行。

8.2 我自己踩过的坑

最后分享几个只有真做过才会知道的坑。

第一个是阴影。很多稿子里的阴影很好看，但开发实现出来就发灰、发脏。原因是移动端的阴影渲染成本高，系统往往做了简化。我的做法是尽量用“描边 + 极浅阴影”的组合代替纯阴影，既轻量又清晰。如果一定要用阴影，把它拆成两层：一层大范围低透明度，一层小范围稍高透明度，叠加起来比单层自然得多。

第二个是图片圆角。给一张大图设圆角，如果同时用了缩放动画，某些设备上会出现边缘锯齿。稳妥的做法是给容器设圆角和overflow: hidden，让容器去裁切，而不是直接裁图片。这个细节在小图上看不出来，在大图或者动画里非常明显。

第三个是“设计稿里的字体在真机上没有”。中文界面尤其明显，设计稿用了某种商业字体，上线后要么没授权，要么包体积太大没法打包，最后只能回退到系统字体，整个视觉气质就变了。所以我在定字体之前，一定会先确认这个字体能不能合法使用、包体积增加多少、在主流机型上渲染效果如何。免费的思源系列和系统默认字体，其实已经能覆盖绝大多数场景，没必要为了那点差异去冒险。

第四个关于适配。我做过一个界面，在开发机上完美，结果到了小屏机型上，底部按钮被手势条盖住了。后来统一改成用安全区域变量控制底部内边距，问题才解决。这件事让我养成了一个习惯：每做完一版，先在小屏、大屏、大字号三个极端条件下各看一遍，确认都能用，再进入细化阶段。前期多花十分钟，后期能省掉一轮返工。

说到底，UI设计这件事，好看的案例看一眼就过去了，真正能带走的是它背后的判断标准。同样的圆角和间距，放在不同产品里，能不能成立，取决于你有没有想清楚用户此刻在解决什么问题。我自己的习惯是，每拆完一个案例，就逼自己写一句“它到底解决了什么”，写不出来，说明这个案例我还没看透。上面这5个，我都能写出来，所以它们才会一直留在那个参考文件夹里。