大型的校园后台系统都是怎么设计出来的？

由于一直在做教育相关的产品，在事业部调整之后，我们获得了设计生涯中最重要的一个挑战。承接一个大规模智慧校园产品。虽然事业部旗下的每个教育项目都能很好提供校园服务，但是由于是项目的原因所以它们并不具备令人满意的整体体验和交互逻辑，也难以给予那些期待成长的学校以信心。从一个产品到另外一个产品，UI模式、色彩、图标、甚至字体样式都不一样，整体的体验就显得颇为过时了，同现在的互联网产品相比显得比较脱节。

前期实践调研获得的资料

所以说，我们更希望能创造出拥有一致且满意用户体验的产品，让它真正服务与校园用户，甚者能产生足够的情感关联。我们还希望通过这个项目让校方对我们的服务更满意。

深入调研，多样体验

在前期调研的过程中，全程只有三人参与。由于种种原因，最终只有一人坚持做完了此次的调研。要面对的，是一整个完中[拥有幼儿园+小学+初中+高中的学校]所有负责教师组长/主任，以及校长。错综复杂的校园社会造就了不同于社会的特有关系网络。而我们就要在这样复杂的关系网中穿梭和搭建桥梁，进行调研和体验。

复杂关系网

我们并不知道最终这个设计系统会是什么样子，但是我们很清楚它一定不能太精确，因为不能限制得过死。它需要是可扩展的，灵活的，并且是可迭代的形态。所以在真正开始产品设计之前，我们会尽力去了解对用户更好的交互是怎样的。接下去的就是到处的“转悠”和体验学校生活。再确定了大功能方向后，寻找对口负责人进行了解和访谈，以便于获取一手信息和负责方的想法和态度。这为期两周的调研时间足以让只身一人调研的小伙伴瘦个几斤了。

不放过任何一个角落

与利益相关方保持一致

在探访各个负责人时，表达出发起人[校长]的期望，并听取他们的反馈。同时，不仅要收集校方单方面的想法，还要走访各个年级的学生和家长。我们采取的是问卷的方式来收集用户的信息和反馈。尽可能多的组建关系网，获得即使反馈意见。在收集信息过程中，规避一些伪需求，提炼真正的痛点和发起人的刚性需求成为了我们的主线。这个过程花了一周时间去完成。得到的信息将会被整理到我们接下去需要落地的信息架构中去，成为我们的产品功能。在这里强调的是切记不要求快而忽略样本数量和信息获取的数量。因为前期的思考对后续的产品实现有极大的帮助。在实际的产品中有时候它们甚至能帮你规避80%以上的错误需求。

有效的整合

你的一个决定将影响接下去的开发难度和交付时长。我们将所有的反馈整合之后，分成两个阵营，即校方和家长方。在这个基础上，我们挑选最痛和最刚需的部分作为第一个可交付版本的功能点。而一般第一个版本的功能点不会超过10个。在输出方案后我们需要再次和校方确认第一版本的所有细节，因为我们需要与利益相关方保持一致。

功能点脑图

成果展示

说来也不易。整个第一版本我们花了几乎2/3的时间在校方后台系统上。由于牵扯到缴费和用户中心打通等业务问题，我们几乎跑遍了整个校园了解线下办理具体流程。同时我们也需要同之前给校方做学校后台的部门沟通用户打通问题。在产品上，必须要体现花费这三方最小的时间成本和人力成本之余在使用上获得最大的体验。说实话，谈何容易？但是最终我们还是成功的完成了这个艰巨的任务。在这儿也并非是吐槽，只是心路历程太坎坷，不得不说一下这份得之不易的成果。在一个月的时间内，我们完成了整个产品的前期调研，需求确认，功能点梳理以及最终第一版本交付。以下为我们产品的产品介绍截图：

产品V1.0版本

最后有话说

1.这次的校园类产品是我们接手的第一个整体产品。其中我们需要从前期调研开始一直到落地这个产品并实现成完整功能。挑战即使机遇，这次的合作再一次巩固了我对后台型产品的理解：产品功能需要在实际的业务逻辑限制的基础上体现最方便的使用体验。

2.在和技术人员沟通时，为了更好的完成交付内容。尽可能多的让技术也参与产品的设计。因为我们需要更多的声音来告诉我们各种可能。

3.在把握优先级时，需要和我们的利益相关方保持一致。一定要多听他们的想法，挖掘他们迫切的需求。

つづく