上一篇说了高校平台产品的用户量大且低频的用户群，包含了在校大学生和普通任课老师，这篇将会说平台产品在校内的高频或重要的用户。
1、业务部门老师
用户特性
业务部门老师平时的工作就是处理校内的各项事务，高校信息化的进程导致了原本很多线下的事务都搬到了线上，从而就引发了从统一身份认证、统一数据同步、统一的门户入口等等一系列问题，平台产品组合的出现就是为了解决这些通用的问题。
此部分的用户属于业务敏感类的群体，首先希望的是产品本身符合他们实际工作中的业务流程，并能够在一定程度上减少他们的工作负担，所以产品对于他们的核心价值在于如何提高工作效率。只要能够提升工作效率，哪怕适当的改变原本的工作流程和使用习惯，这部分用户都是能够接受的。
原始需求
业务部门的老师几乎每天都使用平台产品处理各种业务，可能涉及到的业务内容包含如下：
(1) 查看通知公告
这是用户日常工作的一部分，在我和用户接触的过程中，这部分用户每天上班都会通过各类的渠道查看有关通知，判断这些通知内容是否和自己有关。如果部分重要通知被遗漏，可能会造成工作中的纰漏甚至更严重的后果。
(2) 处理待办任务
业务部门的老师通常会负责某个职能部门下的某些流程类业务，需要对这些任务进行查阅、审批、分发等等，这些待办任务往往分布在不同的系统或者同一系统的不同模块，用户需要进入不同的业务系统中处理。
(3) 业务系统维护
除了流程类的业务以外，这类用户还会有日常业务系统的维护，内容可能是发布通知、录入或调整数据等等，用户需要在平台上找到这些服务并长期使用。
平台需要针对这类用户的办公场景专门设计内容，旨在利用线上化的工具大幅提升此部分用户的工作体验。
除此以外，整个平台的稳定和可靠也是此类用户非常重视的，也是首先要保障的。
2、信息中心
用户特性
信息中心使用厂商的产品完成信息化建设的目的就是省时省力还要看得见。
信息中心并不是前台业务系统或者门户大厅的直接用户，而是管理后台的高频用户，他们普遍信息技术知识水平较高，对于复杂的管理后台功能也更容易接受和上手。
信息中心作为学校信息化的牵头部门，面临的压力是很大的，一方面要面对普通老师的各类疑问需要作出处理和答复；另一方面要向领导层面通过数据汇报信息化建设的进展情况。而信息中心除了自己的业务之外，对于其他业务部门的业务内容几乎没有话语权，在整个学校层面，信息中心的地位也并不是最高的那一类，故在建设平台的过程中有相当一部分的工作信息中心是做不了的。
即便能做决策的事情，由于牵扯到的是全校的用户，他们也会非常谨慎小心。
原始需求
根据信息中心的职能以及业务场景，他们原始需求大致如下：
(1)信息化建设需要省心看得见
省心：
需要整个平台产品从前期的建设思路及规划到真正实施落地都需要公司和学校配合。如果校方的思路清晰，那么平台就需要想办法通过软件工具实现校方的想法；如果校方在这件事情上并没有明确的思路，那么产品线除了提供工具以外还需要根据校方的实际情况给出有说服力的建设方向和计划，而其中的建设方向应该是由公司在多年的行业积累中沉淀出来、有数据支撑的业务模型。
看得见
信息化的建设对于信息中心来说势必要是数据可视化的，无论是数据治理、身份认证、办事大厅、业务系统，所有的用户行为数据和业务数据都需要平台完整采集并做相应的分析，供学校下一步决策提供支持；这些数据也是信息中心向领导汇报、向师生展示信息化建设成果的最有利工具。对于产品来说也是直接体现产品力的表达手段。
(2) 权责明确
信息中心希望能够将不属于他们的权限下发给业务部门。这就需要平台能够提供合理的权限分分配模式，将业务管理和平台管理分开；另外需要对整个系统的操作日志留痕，便于查找所有用户针对于平台的操作。
(3) 排错
信息中心在排除某些问题时往往需要花费非常久的时间，这是由于整个平台的自检和出错时，没有能够明确错误的内容导致的，平台自身应该有从硬件到软件的周期性自检机制，在此机制下能够提前将某些风险报出，使管理员能够及时发现并方便的查找和排除问题。
