WWDC Quick Look 💓 By SwiftGGTeam
Create custom apps for employees

Create custom apps for employees

观看原视频

Highlight

Apple 把企业内部 App 的切入点收敛到移动岗位、纸质流程、随身设备替代和员工访谈,并建议用 Xcode、TestFlight、标准控件与小步迭代缩短从痛点到员工可用版本的周期。

核心内容

很多企业 App 项目一开始就走偏。团队先列系统字段,先画审批流,先满足报表需要。结果员工拿到 App 后,日常负担没有减少,只是从纸张换成了屏幕。Adam Humphrey 在这场 session 开头给了一个判断标准:好的企业 App 应该改善员工的工作,降低工作量和完成任务所需的心智负担。

这个标准会改变选题方式。适合做 App 的场景,通常出现在移动岗位、纸质流程、员工随身携带多台设备的工作、以及需要即时响应的任务里。电力维护人员在偏远地形工作,飞行员曾经带着厚重纸质资料,理赔员要带电脑、录音笔、卷尺和相机。这些场景都有一个共同点:iPhone、iPad 和 Apple Watch 能把多个步骤压缩成一个随身工作台。

接下来,设计流程也要改变。演讲反复强调,真正做这份工作的员工要驱动设计。访谈新人、资深员工和中间经验者,观察他们一天中的真实工作,追问每一步为什么卡住。团队曾经准备做移动收银 App,访谈后发现销售助理真正急需的是客户经营(clienteling)能力,于是早早调整方向,避免把工程周期花在次要问题上。

最后是交付方式。Apple 建议用 Xcode 加快开发和测试,用系统标准视图和控件减少培训成本,用 TestFlight 收集员工反馈。企业 App 不该等三年做成一个覆盖所有人的巨型系统。先做一个小而聚焦的版本,让员工用起来,再根据岗位变化继续迭代。

详细内容

1. 先判断企业 App 的工作边界

01:06)企业 App 首先是 employee-facing(面向员工)的 App。很多企业 App 不在公开 App Store 中出现,而是通过 MDM(移动设备管理)和 Apple Business Manager 在企业内部发布。它们可能是全员工具,例如通讯录和会议室预订;也可能是角色工具,例如销售助理 App;还可能是一组协同工作的 App,例如销售助理、库存 runner 和产品目录共同支撑店内流程。

这一段给出的设计检查表很直接。

Enterprise app fit check
- 面向员工,而不是面向外部消费者
- 服务一个明确岗位,或一组相邻岗位
- 能减少工作量、等待时间或认知负担
- 能在 MDM 与 Apple Business Manager 管理下交付
- 可以和 Single Sign-On、App Groups、Keychain 组成 App 套件

关键点:

  • 面向员工 决定了优先级,功能要围绕员工完成任务,而不是只围绕业务采集数据。
  • 明确岗位 防止 App 变成所有部门都要塞需求的入口。
  • 减少负担 是验收标准,员工完成同一件事应该更快、更少出错。
  • MDMApple Business Manager 说明分发、配置和可见范围需要从项目早期就考虑。
  • Single Sign-OnApp GroupsKeychain 适合一组企业 App 共用登录状态和数据,让员工登录一次即可进入整套工具。

2. 从四类高价值场景找机会

03:09)演讲把机会识别拆成几个具体入口。移动员工需要在不同地点完成任务,App 可以提供路线、预计到达时间、离线能力和位置服务。纸质流程适合数字化,飞行员用 iPad 存放大量航图和文件就是例子。员工随身携带扫描仪、相机、GPS、测量设备、录音录像设备时,iPhone 和 iPad 常常能替代多台设备。

Opportunity scan
- Mobile work: 路线、离线、位置准确性
- Paper-heavy process: 表单、文档、检查清单数字化
- Device-heavy role: 相机、GPS、测量、音视频采集整合
- Immediate action: 通知内处理任务,无需打开完整 App
- Team collaboration: Wi-Fi、Bluetooth、cellular、iBeacon 支持现场协作

关键点:

  • Mobile work 关注地点变化和网络不稳定,电力维护人员这类岗位经常需要离线工作。
  • Paper-heavy process 适合从资料携带和查找成本入手,航空场景已经证明 iPad 能替代大量纸张。
  • Device-heavy role 适合理赔员、检查员等岗位,把采集、记录和提交集中到 iPad 上。
  • Immediate action 对应 notification content extensions(通知内容扩展),飞行员可以直接在富通知里接受或拒绝行程任务。
  • Team collaboration 对应隧道检查等无蜂窝网络场景,iPad 可以通过 Bluetooth 和 iBeacon 帮助团队协作。

3. 让员工驱动设计,而不是只问管理层

06:59)演讲建议从访谈和现场观察开始。访谈对象要覆盖新员工、资深员工和中间经验者。新员工知道培训流程哪里难学,资深员工知道现实中的绕路办法。把他们放在同一场访谈里,可以让不同经验互相校准。

Employee interview loop
1. 找到真正每天执行任务的人
2. 同时访谈新人、资深员工和中间经验者
3. 让他们描述完整一天,而不只描述 9 点到 5 点
4. 追问每个模糊步骤,持续问 why
5. 用同岗位员工交叉验证答案
6. 在没有经理在场的安全环境里收集真实反馈

关键点:

  • 真正每天执行任务的人 比经理或领域专家更能暴露现场细节。
  • 完整一天 会揭示上班前、通勤中、咖啡时间里的隐藏工作。
  • 持续问 why 能避免团队把自己的假设填进员工叙述里。
  • 交叉验证 能发现同一岗位在不同地点、不同经验下的流程差异。
  • 没有经理在场 能降低员工修改答案以迎合管理层的风险。

4. 用小版本和反馈循环交付

11:34)Apple 给出的交付建议是优化设计和开发时间。Xcode 用来加快开发与测试;系统标准视图和控件能减少员工学习成本;TestFlight 用来在首个版本和后续功能中持续收集反馈。演讲明确反对三年周期的巨型 App,建议做小、聚焦、持续演进的工具。

Iteration plan
- Build: 用 Xcode 快速开发和测试
- Design: 优先使用标准视图、控件和导航模式
- Scope: 第一版只交付一个清晰员工价值
- Beta: 通过 TestFlight 收集团队反馈
- Roadmap: 根据员工反馈决定下一个功能或下一个 App

关键点:

  • Xcode 是开发和测试的主工具,目标是缩短部署前的等待时间。
  • 标准视图、控件和导航模式 能利用员工对 Apple 平台的已有熟悉度。
  • 第一版只交付一个清晰员工价值 能阻止项目膨胀成无边界系统。
  • TestFlight 让员工在正式发布前参与反馈,发布后也能继续验证新工作流。
  • Roadmap 应该从员工反馈自然生长,而不是先由项目组一次性写完三年规划。

核心启发

1. 给巡检人员做离线任务包

  • 做什么:为电力、轨道、仓储巡检人员生成当天路线、设备清单、检查表和离线资料包。
  • 为什么值得做:演讲提到移动员工经常在不同地点工作,甚至远离网络;离线能力和位置服务能提高数据准确性。
  • 怎么开始:先访谈一线巡检人员,记录他们一天里的路线、拍照、定位、签收和补录步骤;第一版只做离线检查表、照片采集和位置记录。

2. 把纸质审批改成 iPad 工作流

  • 做什么:把纸质表单、飞行资料、交接单或现场报告转成 iPad 上的可搜索文档和结构化表单。
  • 为什么值得做:航空案例说明,纸质资料搬到 iPad 后,可以减少携带重量和查找成本。
  • 怎么开始:选一个仍在大量打印的流程,统计员工每天携带、查找、填写、转交纸张的步骤;先交付阅读、搜索、离线保存和提交功能。

3. 用富通知处理紧急任务确认

  • 做什么:给飞行、调度、门店运营或维修排班做可操作通知,让员工在通知里查看关键信息并接受或拒绝任务。
  • 为什么值得做:演讲中 corporate pilots 可以在富通知里查看航段和天气,并直接接受或拒绝行程。
  • 怎么开始:梳理哪些任务只需要一两个决策动作;用 notification content extensions 展示任务摘要、风险信息和操作按钮。

4. 为销售助理做客户经营小工具

  • 做什么:帮助销售助理查看客户偏好、待办任务、产品库存和跟进记录。
  • 为什么值得做:演讲中的移动收银项目在访谈后发现,销售助理更急需 clienteling 工作流。
  • 怎么开始:先访谈新人和资深销售助理,找出他们服务客户前后最常查的信息;第一版只做客户摘要、库存可用性和下一步提醒。

5. 给内部 App 建立 TestFlight 反馈节奏

  • 做什么:把企业 App 的每次小版本都放进员工 beta 组,让真实岗位在发布前试用。
  • 为什么值得做:演讲建议持续通过 TestFlight 获取反馈,让产品路线从员工使用中生长。
  • 怎么开始:每个岗位选择 5 到 20 名代表用户;每个 beta 版本只验证一个工作流,反馈表只问是否解决问题、哪里卡住、下一步最想要什么。

关联 Session

评论

GitHub Issues · utterances