企业内部的IT产品，通常来说，都不好用。尤其是内部IT部门做的系统，为什么？因为企业毕竟不靠这个产品盈利，能用即可，“以用户为中心”的设计，似乎没有必要。
这种思路下做出来的产品多为工程师思维的产品，也存在很多可用性问题，导致用户学习成本高，系统使用效率低，最终带来其员工的工作效率低下等问题。所以很多企业已经开始注重内部系统的用户体验问题，希望能做到“以用户为中心的设计”，提升员工的工作效率。
我参与了企业内部项目管理的首页改版，我们希望能够为用户带来一个更好用和更有价值的项目管理页面。（什么是项目管理应用？简单来说就是这样一款工具：员工能够在这里制定项目计划，协调各种人财物等各类资源，监控项目进度保证项目成功交付。比如大家熟知的Omni家就有OmniPlan这款产品，就是此类应用，但是对于大型的项目来说，OmniPlan太轻量化。而teambition、trello等偏向项目协作，很难满足工程类项目交付的需要。）
为什么要对首页进行改版？
现有系统采用了launchpad的导航模式，这种交互模式是为各个业务模块提供了入口，用户能迅速跳转至业务模块。其设计类似下面windows的metro设计风格，类似这样：
这样的设计相当于让首页只承担了“导航”的作用，并带来了以下两个问题：
1.信息有效性低
系统服务的对象繁多，除项目交付的自有员工外，还包括客户、分包商。
其中，自有员工中业务角色也包括PM、PCM、TL、TD、TD等角色，每一类的业务角色使用系统的习惯不同、关注的信息点也不相同。而现有系统首页未对业务角色进行区分，所有的业务角色进入首页后，所呈现信息和功能完全一样，导致用户查看信息的效率较低。
2.常用功能模块入口深
虽然首页提供了业务模块入口，但进入次级常用模块的路径较长，如用户需要查看PPMM，其路径是（从导航栏中的13个类别中选择）项目管理-项目质量-PPMM，导致用户操作效率较低。
新版系统首页改版的目标
1.减少不同业务角色寻找信息的时间，提升系统使用效率。
2.督促用户关注红线信息，满足公司管控需求。从公司的角度出发，公司希望项目经理能够关注一些关键信息，如所在项目的PPMM得分，督促项目交付流程更标准化。
如何改版？
在明确问题和目标后，我们按照研究-设计-验证的方法对首页进行设计。
1.研究
1.1 梳理现有首页信息结构
现有首页由顶部菜单导航和launchpad导航构成。
其中顶部菜单导航能够进入每一个业务或功能模块，launchpad导航则为用户快速进入常用的模块提供了便利，launchpad中主要包括以下几类：
1.与我相关的内容
包括和用户相关的待办、申请、问题、预警提醒，需要用户进行跟踪或处理
2.业务模块入口
包括各类角色经常使用的业务模块入口，包括：
“项目主计划”、“人力资源计划”、“大循环履行”、
“实施管理”、“资源与权限配置”、“实施地图”、“实施报表”
“项目经营”、“问题管理”、“问题管理”等10大业务模块入口
3.通知
我们发现，主要问题在2，占据了首页大量空间，却只提供了入口的作用，价值和效率都较低。那么应该呈现何种信息，提供什么功能呢？我们需要进一步理解业务角色。
1.2 理解业务角色
PM和PCM是系统的核心角色，因此我们优先选择他们我们为PCM这类业务优化首页，通过对以往的用户画像研究和企业内部流程文档中，我们发现对PCM的工作职责是这样的：
1.指定计划编制和管理规则
2.组织各专业模块按项目集成计划实施
对项目进度的计划数据和实际数据及时性和完整性负责。
3.跟踪监控与评估项目进度：并通过数据分析，及早发现进度问题并采取适当的预防措施；及时向项目干系人、项目组内部和客户定期通报计划进展，及时预警项目里程碑的延迟风险。
但是，这部门职责定义相对笼统，无法直接支撑设计，所以我们进一步从后台提取数据，比如用户监控何种数据？进行哪些操作？这些我们可以通过分析后台数据得到。
1.3.提取用户行为数据，定位用户最常使用的功能模块
提升用户系统使用效率，那么首先需要分析用户经常在系统里进行哪些操作，查看哪些信息。然后作为我们首页改版的参考。以PCM角色为例，我们通过提取用户后台行为数据，发现PCM使用最多的功能模块包括：
但是，用户怎么使用这些功能模块？他们在里面是查看信息？还是执行一些操作？通过和业务方讨论，进一步对这些行为进行梳理和。
1.4 对用户行为进行分类进一步梳理
了解了用户的目标、行为数据之后，我们需要进一步对用户的行为数据进行分类，以便为后续的首页布局提供依据。
对PCM经常使用的模块进一步归纳，发现可以分为以下两种场景：
场景1：信息查看
如双周MOS计划准确率报表、主计划、PPMM、人力资源计划等。用户进入该功能模块主要目的是查看进度、数据是否异常，以便进一步开展工作。如在主计划中，用户能通过图表快速了解自己项目的plan值、actual值、target值。
场景2：完成任务
任务类可分为两类，一类为主动发起的任务类型，如DRX申请及评审是用户主动发起的任务，同时需要跟踪评审结果，属于“主动发起的任务类型”
另一类为被动接受的任务类型。如“交付审批”，别人发起审批后系统分发至该用户进行审批，任务的执行是“他人驱动”。
2.设计
2.1 卡片化设计
卡片化的设计能够更好地将信息、图像按维度分类整合到一个卡片，避免信息散乱、信息分类不明确。有效地减少用户思考的时间，能快速找到自己所需的信息。
卡片化设计能够将信息模块化，扩展性高，方便后续增加功能模块。
根据前期的研究结果，我们可以将用户行为进一步转化为三种类型的卡片：
指标卡：
即“信息查看”的内容，我们突出指标信息，以图表、数字的形式将信息可视化。这一类卡片我称之为“指标卡”。
用户查看卡片即可了解关键信息，如“主计划”卡片，用户能对比actual和plan的gap，“PPMM”卡以仪表盘的形式告知用户当前项目健康度。
当用户需要进一步查看详情时，点击卡片跳转至详情页。
任务卡：
对于主动任务类型的模块，我们只需为用户提供快速入口即可，无需做数据可视化。
将多个任务呈现在一个卡片中，如“DU/活动流：的卡片中，用户可以通过该卡片快速进入DU创建、关联活动流等任务。
提醒卡：
对于被动任务类型模块，我们以提醒卡的形式，用户发现当前有需要处理的事项，再点击进入事项列表页，进行处理。
TIPS：值得注意的是，由于设计师对卡片的业务逻辑缺乏了解，所以需要寻求业务方为设计师进行输入，尤其是对指标卡和任务卡的设计时，需要讨论确定每张卡片的关键信息点。
最终我们的设计效果类似这样，根据卡片的类型、使用的频次和重要程度进行排布。用户能够通过首页对项目进行全览，了解关键指标的信息，提高信息查看的效率和操作效率。
2.2 让用户能够对卡片进行自定义
我们虽然对用户行为进行了分析，但是很难保证我们提供的默认首页就是他需要的，因此我们允许用户根据自己的业务需要增加、删除卡片，甚至对卡片进行拖曳布局。
3.验证阶段
由于时间关系，没有执行严格的可用性测试，但是在对仅4名实际用户的可用性测试中，仍然发现了一些严重的可用性问题，其中与卡片设计相关的包括：不理解卡片含义，希望能够自定义卡片的数据类型，比如3位用户都表示自己平时对比主计划的plan和actual信息就足够，但是现在还展示了target等信息，有些多余。
我们根据用户建议，修订了部分卡片的文案，同时对于自定义卡片数据类型的需求排在了后续版本计划中。
