LONG TAO
企业工程项目管理APP
为中小型机械设备工程企业量身定制iOS移动端管理平台，通过系统化需求调研方法完成从需求梳理到交互视觉设计交付
iOS移动端平台
4+8一级页面+功能模块
5种需求调研方法综合运用
2个月从调研到设计交付
Role
移动端设计师
iOS 端独立负责
Timeline
2021.02 - 2021.04
约 2 个月
Team
个人项目
移动端部分独立负责
Market
机械设备工程
B端iOS · 定制化产品
我的角色
| 项目名称 | 企业工程项目管理APP |
|---|---|
| 项目类型 | 定制化移动端产品设计 |
| 客户类型 | B端 移动端 |
| 行业 | 机械设备工程 |
| 平台 | iOS（移动端App） |
| 项目时间 | 2021.02 – 2021.04（2个月） |
| 我的角色 | 移动端设计师，独立负责iOS端的用户调研、需求分析、交互设计及视觉设计全流程 |
| 参与深度 | 全流程独立负责（用户调研→需求分析→信息架构→交互设计→视觉设计→原型测试→设计交付） |
| 项目状态 | 已交付 |
具体任务清单
- 客户公司线下实地调研与员工访谈，收集业务需求与工作流程
- 通过卡片分类法验证并确定模块架构（4个一级页面 + 8个子模块）
- 运用故事板梳理核心任务流程中的用户接触点
- 通过亲和图法逐接触点完善设计需求
- 输出完整的页面信息架构与业务流程图
- iOS端全模块交互设计与高保真视觉设计（交互+视觉合二为一）
- 自定义UI规范与组件库
- Flinto可交互原型制作与用户测试
- 设计交付与开发对接
我直接产出的交付物
- 用户调研报告（含访谈记录与需求梳理）
- 信息架构与业务流程图
- iOS端全模块交互与视觉设计方案
- Flinto可交互原型
- UI设计规范与组件库
项目挑战
项目背景
客户是一家处于快速发展期的中小型机械设备工程企业，希望引入移动端管理平台以提升项目管理和办公效率。此前曾接洽知名办公系统供应商，但发现市面现有产品多为面向大型企业的标准化套件：功能冗余、不支持量身定制，且无法适配工程行业特有的管理模式与流程习惯。客户的核心诉求是——「量体裁衣」，定制一套精巧的、贴合本行业特点和管理流程的移动端管理平台。
我负责的是移动端（iOS）部分的全部设计工作。Web端后台部分因需前端先敲定数据交互需求，且可由开发直接使用Bootstrap框架搭建以提升效率，本阶段暂未跟进。
用户痛点
- 市面现有产品功能大而全但行业适配度低，花钱买了用不上的功能
- 工程行业有独特的项目管理流程（商机→投标→施工→验收→收款），通用系统无法灵活配置
- 企业处于快速发展期，管理模式持续演进，系统需要支持快速调整
- 一线员工以手机为主要办公设备，需要原生移动端体验而非Web端缩放适配
核心挑战
挑战1：B端复杂业务到设计需求的拆解
工程行业有独特的业务流程（商机→投标→施工→验收→收款）和审批层级（多级逐级审批），如何从海量、零散的业务描述中系统化地提取和梳理出结构化的设计需求？
💡 为什么难：B端项目的需求分析侧重从业务需求到设计需求的拆解、合并和梳理，以及服务设计流程的构建——和C端产品的需求分析有本质不同。设计师需要在短期内深入理解一个完全陌生的行业领域。
挑战2：十余个模块的信息架构如何验证
哪些直接作为一级页面、哪些作为子模块？每个模块涵括哪些细分功能？——单凭设计师的经验判断风险高，需要用户参与验证但用户缺乏信息架构的专业词汇。
💡 为什么难：B端产品信息架构庞杂、流程复杂度高，信息架构和流程设计通常是同步进行、相互补充完善的——这要求设计师同时驾驭两个维度的复杂度。
挑战3：单人全流程 + 2个月时间约束
作为项目唯一的移动端设计师，需要在2个月内独立完成调研→需求→IA→交互→视觉→测试→交付的全流程。传统的「交互稿→评审→视觉稿→评审」流程在这种条件下效率不足。
💡 为什么难：按照常规流程，交互和视觉分步进行需要多轮评审和修改，在2个月的时间窗口内很难完成全模块的深度设计。需要找到一套既能保证质量、又能压缩周期的设计方法。
设计过程
这个项目最有价值的部分是需求调研与梳理的方法链——在一个全新的、复杂的B端领域中，如何通过多种设计方法的综合运用，逐步收集、理顺并和用户一起确认需求。
阶段一：用户访谈 — 建立业务认知基线
在一个全新的、复杂的B端产品中，很难通过简单的头脑风暴或焦点小组收集完整需求，而问卷也可能因设计师对业务背景理解不够深入而设计出不合理的问题。因此我选择以线下实地调研 + 线上/线下一对一访谈作为切入点。
通过在客户公司实地观察，以及针对性访谈，我系统收集了以下基础信息：客户企业的部门和人力资源如何构成？工程项目从商机、投标到验收和收款如何运作？哪些事务流程需要引入线上审批？采购、报账和工资核算需要哪些人员参与、按什么流程逐级审批？
线下实地调研与用户访谈，建立对工程行业业务流程的认知基线
阶段二：卡片分类法 — 确定模块架构
通过需求调研，产品需要实现的主要功能点和模块数量已基本有数。但十余个模块中，哪些直接作为一级页面、哪些作为子模块？每个模块涵括哪些细分功能？
我邀请了工程行业的用户进行封闭式卡片分类法测试，并允许用户补充确实需要新增的卡片。将测试结果与自己设定的分组进行比对——吻合度良好的部分予以确认，偏差较大的部分逐一排查和回访，修正后加入经过验证的信息架构。
卡片分类法：邀请用户参与封闭式卡片分类，验证模块归属和命名合理性
最终确定：4个一级页面 + 8个主要功能模块
阶段三：故事板 — 梳理接触点
模块架构确定后，按模块列出核心任务、非核心任务和辅助任务清单。逐一通过故事板方法梳理每个流程的用户接触点，确认每个任务中不同职位角色的用户在各个环节中的情境场景和行为。
阶段三：通过故事板梳理「现场图库」模块中不同角色在各环节的接触点与行为
阶段四：亲和图 — 完善设计需求
故事板确定了核心任务的流程和接触点后，下一步是回答：在每个接触点上，用户需要看到哪些信息元素、找到哪些功能控件？
我将故事板得出的接触点陈列在横轴上，先按自己的理解贴上预估的信息需求和功能需求，再邀请用户逐一浏览、删除不合理项、补充遗漏项。最终通过整理、合并和去重，得到详细设计所需的设计需求清单。
通过亲和图法逐接触点收集、验证和补充设计需求
💡 B端与C端的一个关键差异：C端产品通常信息架构先于流程确定，而B端产品信息架构庞杂、流程复杂度高，两者通常是同步进行、相互补充完善、同时收官。
信息架构与流程图
经过反复补充、取舍和整理，在正式进入线框图方案绘制前，最终确定的页面信息架构和业务流程图如下：
完整的页面信息架构
核心业务流程图
关键设计决策
每个决策都包含了「选择了什么」、「为什么这样选择」、以及「放弃了什么替代方案」。
决策1：用卡片分类法验证信息架构，而非设计师自行拍板
为什么：十余个模块的层级归属和命名，单凭设计师的经验判断风险高——对工程行业术语和业务流程的理解偏差可能导致架构不合理。封闭式卡片分类法让用户用自己熟悉的语言来组织信息，设计师的角色从「决策者」变成「验证者和修正者」。
| ✅ 选择的方案 | ❌ 放弃的方案 |
|---|---|
| 邀请工程行业用户进行封闭式卡片分类测试，允许补充新卡片。设计师将结果与自身方案比对——吻合处确认、偏差处回访修正 | 方案A：设计师自行确定信息架构 方案B：完全交由用户自由分类 |
决策2：交互设计与视觉设计合二为一，压缩交付周期
为什么：传统的「交互稿→评审→视觉稿→评审」流程在2个月的时间约束下效率不足。作为项目唯一的移动端设计师，直接在交互方案上按照自定UI规范进行视觉设计，可以将两步合二为一——评审时呈现的就是接近最终效果的高保真界面，客户和团队的反馈更直观、决策更快。
| ✅ 选择的方案 | ❌ 放弃的方案 |
|---|---|
| 在交互稿阶段直接进行视觉设计，按自定UI规范形成组件库。定稿后交互稿可直接用于原型测试、稍作整理即可交付开发 | 方案A：严格按「交互稿→评审→视觉稿→评审」分步执行 方案B：先出线框图快速评审再补视觉 |
决策3：故事板+亲和图联合使用，系统化地从流程推导设计需求
为什么：对于B端复杂流程，从业务需求直接跳到页面设计容易遗漏关键接触点和信息需求。故事板先把每个任务的用户接触点可视化铺开，亲和图再逐接触点收集用户对信息和功能的需求——两步走形成了从「业务流程」到「页面元素」的完整推导链，减少设计遗漏。
| ✅ 选择的方案 | ❌ 放弃的方案 |
|---|---|
| 故事板梳理接触点 → 亲和图逐点完善设计需求 → 整理合并去重 → 形成设计需求清单 | 方案A：凭经验直接从业务需求推导页面功能 方案B：仅用亲和图而不先做故事板 |
决策4：采用Flinto可交互原型进行用户测试，实时标注问题
为什么：iOS单平台应用的原型测试需要一个轻量高效的工具。Flinto可以快速制作接近原生体验的可交互原型，让用户在手机上真实操作核心任务流程。同时我习惯将交互稿排版为可打印格式——在观察用户操作时，直接在交互稿上实时标注问题和发现，任务结束后针对性访谈偏差原因，然后立即在稿上修改。
| ✅ 选择的方案 | ❌ 放弃的方案 |
|---|---|
| Flinto制作可交互原型 + 手机上操作测试 + 交互稿上实时标记问题 + 当场修改迭代 | 方案A：评审会上静态演示设计稿 方案B：开发完成后在真机上测试 |
设计结果
🟢 已交付（客户对方案满意，确认缩短了交付期限）设计方案
系统化的需求调研方法链
- 用户访谈：实地调研 + 一对一访谈，建立对工程行业组织架构、项目运作模式和审批流程的认知基线
- 卡片分类法：通过封闭式卡片分类验证和修正信息架构，最终确定4个一级页面+8个子模块
- 故事板：逐核心任务梳理用户接触点，确认不同角色在各环节的情境场景和行为
- 亲和图：逐接触点收集、验证和补充信息需求与功能需求，形成设计需求清单
iOS端全模块交互与视觉设计
- 交互与视觉合二为一：直接在交互方案上按自定UI规范进行视觉设计，缩短交付周期
- 自定义UI规范与组件库：统一全模块视觉语言，便于后续迭代和维护
- Flinto可交互原型：让用户在手机上真实操作核心任务流程，发现并修正可用性问题
交互设计方案：在交互稿阶段直接进行视觉设计，评审时呈现高保真界面 ↕ 滚动查看完整内容
原型测试：使用Flinto制作可交互原型，在手机上操作测试的同时在交互稿上实时标记问题并快速迭代
项目成果
- 在2个月内完成从行业认知空白到全模块设计交付的全流程
- 客户对方案满意，确认「大大缩短了交付期限，评审直观程度远超线框图」
- 5种调研方法综合运用（用户访谈+卡片分类+故事板+亲和图+原型测试），形成可复用的B端需求梳理方法链
- UI规范与组件库为产品后续迭代提供设计基础
⚠️ 本案例为定制化项目，以上线交付为核心目标，未进行独立的量化数据追踪。案例价值主要体现在B端需求调研与梳理的系统化方法论，以及单人全流程的设计执行效率。
反思与成长
经验教训
- B端设计，需求分析是核心战场：在一个全新的行业领域中，花在需求调研和梳理上的时间不能省。「用户访谈→卡片分类→故事板→亲和图」的方法链虽然投入大，但减少了后期因需求理解偏差导致的返工。
- 让用户参与信息架构验证：卡片分类法在这个项目中是性价比最高的方法——实施成本低（无需专业工具），但能有效暴露设计师对行业术语和用户心智模型的理解偏差。
- 流程不是枷锁：「交互→视觉」的标准流程是有条件的——当满足「单人负责全流程」和「时间紧迫」两个条件时，合二为一是更高效的选择。前提是设计师已经建立了自己的UI规范和组件体系。
- 可交互原型在移动端项目中价值巨大：B端移动应用的很多交互细节（如表单填写、列表滚动、多级审批流转），静态设计稿无法充分传达。Flinto让用户在手机上真实操作，暴露了多个评审中未发现的可用性问题。
后续优化方向
- 前期加入量化基线测量：在用户访谈阶段同步收集客户当前的效率基线数据（如审批流转平均耗时、日报提交率等），为设计成果提供量化对比依据，弥补本案例缺乏数据支撑的遗憾。
- Web端纳入设计范围：本项目仅覆盖了iOS移动端，后台管理部分由开发直接用Bootstrap搭建。如果同时跟进Web端，可以确保移动端和后台的信息架构和交互模式保持一致，避免双端割裂。
- 建立更系统的组件库：本项目形成了UI规范但组件库的体系化程度不如后续的HRM和VivaTalk项目。如果重来，应从第一个模块开始就按「基础元件→业务组件」的层次结构搭建。
方法沉淀
- 系统化需求调研能力：在一个完全陌生的行业（机械设备工程）中，独立建立业务认知并输出结构化设计需求——这套方法在后续多个B端项目中持续复用和迭代。
- 单人全流程执行效率：2个月内从零完成一个完整移动端产品设计，验证了「交互+视觉合并」的高效工作模式。
- B端与C端设计方法论的差异认知：深刻理解了B端需求分析的核心在于从业务需求到设计需求的拆解和梳理，而非C端常用的用户画像和情感化设计路径。
能力映射
- B端需求调研方法链
- 信息架构设计
- 移动端iOS设计
- 卡片分类法
- 故事板与亲和图
- 单人全流程独立Owner
- 交互+视觉合并高效交付
- 原型测试与快速迭代