企业工程项目管理APP的交互&视觉设计

今天分享的是这两个月在做的一家中小型工程公司的工程项目管理平台项目。客户是一家正处于快速发展期的机械设备企业,希望引入移动端管理平台以提高项目管理和其他办公事务的效率。客户在此前也曾经联系过较为知名的办公管理系统供应商,但发现大多数功能完善的产品都更适合大型企业的需要,而且多为现成的成套产品,不支持功能的量身定制。对客户来说,其中有些功能不但浪费,而且不适合工程行业的特点、企业特有的管理模式和流程习惯。因此希望能根据自身需求,量体裁衣定制一套精巧的、适合本公司行业特点和管理流程的管理平台。

我负责的工作是移动端部分(iOS),包括前期的用户调研和需求分析,以及交互设计和视觉设计全程。至于Web端的后台部分,由于需要前端部分先敲定所有数据的交互需求,并且考虑到后台界面可以由开发直接用Bootstrap框架搭建,更有利于效率(有的经过较长时间沉淀和迭代的框架也确实非常美观、可用性也很棒),因此本阶段暂未跟进。

实际上,这类B端项目占了我今年工作中的绝大部分,但由于对接中国电信等大型运营商的项目涉及较多运营商内部的管理模式方面的保密内容,一直没有机会通过一个相对完整的B端项目,和大家一起交流一下在复杂的企业需求和商业背景约束下进行产品设计的过程。而这次很高兴经过客户允许,难得地可以把不涉密的设计过程和文档在这里和大家做一个简单的分享。这个项目其实和我在公司的项目相比,在同类的B端项目中算是模块数量相当少的了,但对单个模块而言,模块内的功能点和审批流程的复杂度都是应有尽有的,因此“麻雀虽小五脏俱全”,从这个角度上讲也是一个最适合展示设计思考过程的项目。

B端项目的需求分析过程更侧重从海量的业务需求到设计需求的拆解、合并和梳理,以及和服务设计流程的构建,和C端项目的需求分析过程有极大的不同,下面会首先展示和简述自己在这个项目中,如何通过多种设计方法的综合运用,逐步收集、理顺并和用户一起确定需求的过程。当然,由于需求分析中很多思考都是基于客户企业内部的基础资料(例设计文件规范、各类报表、工资单等)确定的,另外也考虑需求数量和篇幅,所以详细的分析推导过程和需求文档就不方便逐一展开讲解了。不过最终产出的交互设计(含视觉设计)文档可以在后面比较完整地展示给大家。

对企业管理类的移动端应用来说,产品的目标非常明确,就是以企业的实际需求为出发点,在保障数据的安全的前提下,改善以往传统办公或者Web端管理平台的效率问题,减少完成同样一件任务的精力、时间和成本,最终给企业带来利润。同时,帮助员工提升办公效率、降低每个人的工作强度。这是相比C端应用来说较为明确的部分,而从产品目标到设计目标的转化过程,则有很多不同的地方。

1. 用户访谈

在一个全新的、复杂的B端产品中,很难通过简单的头脑风暴、焦点小组的讨论收集完整的需求,而问卷这一在C端产品调研中的有力手段,也可能因为设计师在接手项目之初对于业务背景、行业特点理解不够深入,有可能设计出让受访者觉得别扭甚至“啼笑皆非”的问题。因此,个人觉得更为行之有效的方式是有针对性的用户访谈和实地调研。

通过在客户公司进行线下的实地调研,以及对客户员工的线上/线下访谈,在客户员工的讲解中了解并收集了大量基于真实员工反馈的基础资料。例如:

  • 客户企业的部门和人力资源是如何构成和配备的?
  • 一个工程项目从商机、投标到最终的验收和收款是如何运作的?
  • 哪些事务流程需要引入线上审批功能?
  • 采购、报账和工资核算的流程需要哪些人员参与、按什么流程进行逐级审批?
    ……

2. 卡片分类法:确定模块架构

通过需求的调研和梳理,产品需要实现的主要功能点和相应的模块数量已经心里基本有数,但十余个模块中,哪些直接作为一级页面、哪些作为由一级页面进入的子模块?每个模块中涵括哪些细分的功能页面?为了解决这些问题,我邀请了工程行业的用户进行了封闭式卡片分类法的测试,并允许用户补充他认为确实需要新增的卡片。

通过卡片分类法确定模块和基本的信息架构

本产品的4个一级页面与8个主要功能模块

根据测试结果与自己设计时设定的分组进行比对,其中吻合度良好的部分予以确认,成为经过验证的信息架构。而偏差较大的部分则或多或少反映了命名的不合理或层级位置不合理,对这些偏差进行逐一排查和回访后,将修正后的卡片重新加入经过验证的信息架构。最终确定的模块架构由4个一级页面和8个子模块构成,这一最高层级结构的合理性也在后续的设计过程中得到了充分的验证和确认,而细分功能页面的信息架构在此时只是一个初版方案,根据流程设计中更深入的讨论、调整补充才能形成最终的信息架构。

3. 故事板:梳理接触点

在模块的架构基本确定后,可以很快按照模块列出若干核心任务、非核心任务和辅助任务,形成一份清晰的任务清单。此时可以按照清单逐一通过故事板的方法梳理每个流程的用户接触点,并通过故事板的展示,确认了每个任务中不同职位角色的用户在每个环节中的情境场景和行为。下图为在“现场图库”模块设计过程中绘制的故事板。

通过故事板梳理用户接触点

4. 亲和图:完善设计需求

通过故事板基本确定了核心任务(以及比较重要的非核心任务)的流程和接触点后,下面要解决的问题是,在每个接触点上,用户需要看到哪些信息元素(信息需求)、找到哪些功能控件(功能需求),亦即设计中需要满足哪些设计需求。作为设计师,凭借自己的经验和对项目背景的研读,可能可以正确分解得到其中的大部分,但仍然可能存在大量遗漏的,或者设计了但理解存在偏差、或者用户实际不需要的需求。因此,倾听用户真实的声音在需求分解中是非常重要的一步。
其中,对重要的核心模块,可以通过亲和图方法,按照故事板中得出的接触点,逐一进行设计需求的完善和确认。对一个任务而言,首先,可以将由故事板整理得出的接触点陈列在横轴上,然后先按照设计师对任务的理解,贴上自己认为需要的信息需求或功能需求,接着再邀请用户浏览各接触点下的便利贴,查看是否有不合理或者不必要的需求,从中摘掉。并写下自己认为需要补充的需求并贴上去。当然,在参会人数较少、进行快速确认时,也可以在Excel中通过单元格的形式进行亲和图步骤。
最终,通过整理、合并和去重(部分因用户用词不规范、不一致引起的重复),就可以得到详细设计过程需要的设计需求清单。

通过亲和图法完善接触点的设计需求(方法示例)

因此,可以看到,和C端产品设计中信息架构经常先于流程确定的习惯不同,B端产品信息架构庞杂、流程复杂度高的特点决定了这两个过程通常是同步进行,通过上述方法不断地相互补充和完善,最后也是同时收官确定的。

最终,经过反复的补充、取舍和整理,在正式进入线框图的方案绘制阶段前,确定的页面信息架构(页面内的信息架构因篇幅所限不在此展开)和流程图如下图所示。

页面信息架构(右键“在新标签页打开图片”可查看大图)

流程图(右键“在新标签页打开图片”可查看大图)

5. 交互方案

具体页面的设计阶段,“交互稿(线框图)→视觉稿”是通常意义上最规范的做法,在交互和视觉同学的配合默契的情况下也是最能让团队成员各就其位、效率最高的方式。但在项目由于客观原因人力配备不足、交互和视觉需要由同一个设计师兼任的情况下,或者像这个项目一样有机会独立承担整个项目的产品设计时,个人觉得就没有必要严格按照这个步骤来执行。直接在交互方案上按照自己定制的UI规范(包括形成相应的组件库)进行视觉设计,可以将这两步合二为一。

虽然在做交互稿的时候可能会觉得或多或少影响了效率,但考虑到定稿后交互稿中的页面可以直接用于原型测试、并且稍作整理就直接切图交付开发这些优势,交互设计阶段的效率代价如果在合理范围内的话也是可以接受的。本项目中我就是直接在交互稿上进行了视觉设计,从结果上说客户还是非常满意的,不但大大缩短了交付期限,评审时的直观程度上也比线框图的效果好了太多。

为了避免用流量阅读本文的朋友浪费流量,这里只放一张全部交互稿缩略图,有兴趣查看完整交互稿的朋友请戳完整版交互稿

交互方案(0.10.4版)

6. 原型测试

在交互方案评审完成后,通过可实际操作的原型,让用户对核心任务流程在手机或电脑(最好是手机)上进行操作,可以有效地发现一些设计和评审中都不易发现的可用性问题。

Flinto原型测试的同时在交互稿上实时标记问题

本项目由于是iOS单平台应用,我习惯采用的原型演示工具是Flinto。在观察用户操作的同时,可以把存在的问题或者其他注释实时地记录在交互稿上——这也是我习惯将交互稿排版成可打印形式的原因。对一些偏差较大的操作,在任务测试结束后可以对用户进行针对性的访谈,找到这些偏差背后的原因。

在收集到可用性问题或其他可以考虑改进的地方后,可以马上在交互稿上进行修改,从而迅速地将方案形成更为完善的版本,交付下一次评审。

以上就是这个项目从需求收集和整理,到交互稿、视觉稿的产出的全过程分享,希望对有需要的同行朋友有用,更希望听到好的建议和指点,欢迎一起交流。

此外,这里没有展开讲的一个重要环节是交互设计自查,有效的自查可以帮助我们在方案提交给客户评审前及时发现很多问题。关于自查的思路和方法,同样依托于这个项目,我在另一篇文章中进行了详细的小结,感兴趣的朋友可以戳《交互设计自查:思路总结与项目实例》

Qinsman wechat
关注我的公众号,一个卖馒头,也卖故事的地方:)