WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Design foundations from idea to interface

Design foundations from idea to interface

基础Design
观看原视频

Highlight

Majo 从 Design Evangelism 团队的视角，用一个虚构的黑胶唱片收藏 app 做 case study，从四个层面展示如何从零打磨一个 app 的设计：

核心内容

打开一个 app，第一眼找不到自己在哪、不知道能做什么、看不出下一步去哪——这是用户犹豫、困惑甚至直接卸载的根源。Majo 用一个虚构的黑胶唱片收藏 app 演示这种「看起来挺像样、实际用起来卡壳」的状态：顶部是个含糊的菜单，标题像品牌 logo，往下滑是一堆专辑封面无从交互，到了最底部才看到 tab 名 Records 才反应过来「原来这是 Records 页」（02:49）。屏幕没引导她，她得自己拼。

Apple 把整个流程拆成四步：Structure（结构）、Navigation（导航）、Content（内容）、Visual Design（视觉），每一步对应三个最朴素的用户问题——我在哪、能做什么、能去哪（01:56）。从信息架构开始把功能写下来、想象使用场景、删掉非本质项；用 Tab bar 承载导航，HIG 把 tabs 定义为 navigation 而非 action（06:01）；用 toolbar 同时回答「我在哪」和「能做什么」；内容上用 progressive disclosure 渐进式披露、按时间/进度/模式分组；视觉上用 system text styles + semantic colors 让文字和颜色自动适配 Dynamic Type、暗黑模式与对比度。每一步都把模糊的设计直觉换成可检查的具体问题，让判断有据可依。

详细内容

Structure：先做信息架构，再谈界面

Majo 的流程很机械：把 app 能做的所有事写下来（功能、流程、甚至 nice-to-have），不评判；想象别人在什么场景下用、什么时候用；然后开始清理——删掉非本质的、改名让标签清楚、把天然属于一组的合并（04:02）。她得出的判断很直白：如果你自己说不清什么是本质，就没法在 app 里说清楚。

Navigation：Tab bar 是导航，不是动作面板

最初的 tab bar 有 Records、Crates、Add、Swaps、Saves 五项。Crates 只是「把 Records 分组的页面」，合并掉。Add 是主操作，但 HIG 明确写「tabs 用于导航而非动作」，所以挪进 Records 内部（06:06）。剩下三个 tab 用 SF Symbols 配明确标签——不要自己画图标，因为「我也觉得自己设计图标很难」（06:42）。每多一个 tab，用户就多一次决策成本。

Toolbar 解决两个问题：标题告诉你「在哪」，操作按钮告诉你「能做什么」（07:23）。空间有限，只放最常用的，统一用 SF Symbols。

Content：渐进式披露 + 四种分组

把 Groups 和 Records 两类内容分开是第一步。但全部铺开会让用户瞬间被信息淹没——progressive disclosure 的做法是先露出几个 group，剩下的藏在标题旁的 disclosure control 后面，等需要时再展开（09:01）。

布局选择有讲究：两个 item 用 grid 太空旷且对长文本不友好，换成 List——结构化信息好扫读，垂直空间利用率更高（10:22）。Apple Design Resources 的 list 模板可以直接套，不用从头画。大量图片用 Collection（间距一致、文字尽量少），适合 photos、videos、products 这类滚动浏览的场景。

四种分组策略，按使用频率排序：

  • 按时间（Recent files、Continue Watching，或当季内容如「适合夏天的唱片」）
  • 按进度（草稿邮件、未完成的课程、整套合集）
  • 按模式（相关推荐、风格、流派）
  • 按事件（11:33 起讲分组主题）

Visual Design：squint test + system styles + semantic colors

视觉层级的最简检查叫 squint test——眯眼看屏幕，最先注意到的应该是最重要的内容（13:55）。如果最先看到装饰性元素，层级反了。

修法是把推荐内容放大、加对比度做成视觉锚点。但仅靠手调字号撑不住——文字可能变长、语言可能切换、用户可能开大字号。这时换成 system text styles：从 title 到 caption 一整套，自动支持 Dynamic Type（15:20）。

文字叠在图片上时，busy 或高对比图会破坏可读性。简单做法是加一层渐变或模糊背景——清晰度优先于美观（15:40）。

颜色上区分两种：palette 颜色（自己挑的四色 + retro 形状，混搭出风格）和 semantic colors（label、secondarySystemBackground 这类，按用途命名而非外观，自动适配明暗模式与对比度设置，17:00）。Accent color 谨慎用——只在 buttons、controls、选中态这些有意义的地方，避免影响动态切换、可读性和用户舒适度。

核心启发

  • 做什么：用「我在哪 / 能做什么 / 能去哪」三问审计每一屏

    • 为什么值得做：这是用户进入屏幕后大脑实际在问的问题，不是设计师想问的
    • 怎么开始：打开你的 app，每一屏都做 5 秒测试——5 秒内能不能回答这三问？答不上来的就是结构问题，不是审美问题

  • 做什么：把 tab bar 砍到 3-4 个，把动作从 tab bar 里挪出去

    • 为什么值得做：每多一个 tab 就多一次决策成本；tab 放动作按钮违反 HIG，会让 app 看起来比实际复杂
    • 怎么开始：列出当前所有 tab，问每个 tab「合并掉会怎样」；列出 tab bar 里所有非导航元素（添加、收藏等），挪到对应内容页的 toolbar 里

  • 做什么：把自定义字号和自定义颜色全部替换成 system text styles + semantic colors

    • 为什么值得做：免费拿到 Dynamic Type、暗黑模式、对比度适配，不用自己维护多套样式
    • 怎么开始：搜一遍代码里所有 .font(.system(size:)) 和写死的颜色十六进制，换成 .font(.title) 等语义化样式和 Color(.label) 等 semantic colors

  • 做什么：内容多到一屏放不下时，用 progressive disclosure 而不是无限滚动

    • 为什么值得做：上来铺所有内容会让用户被淹没；露出关键的几个 + 「展开更多」是处理大量内容的标准模式
    • 怎么开始：每个分组先只露 3-5 项，标题旁加 disclosure control；点进去的二级页保持和上一屏视觉连续，让人感觉像「展开」而非「跳转」

  • 做什么：每改完一屏，用 squint test 做最后一道关

    • 为什么值得做：这是检查视觉层级最便宜的方法，5 秒就能判断重点是不是真的重点
    • 怎么开始：把屏幕截图丢到 1/4 大小或眯眼看，记下最先注意到的元素，对照「最重要的内容」清单——对不上就调

关联 Session

评论

GitHub Issues · utterances