记一次设计外包项目总结（上）

最近，也不能说最近吧，总之就是大四这段时间，写论文之余闲得无聊，和朋友接了一个设计外包项目。我们三个人，我是交互设计师，其他两个负责视觉设计，第一次组队就接了一个项目，团队算是一边磨合一边进行工作，而我们团队和公司那边也是一边磨合一边进行工作，其实工作进行得不是很顺利，不过总归做完了。回顾这次项目经验，有几点想跟大家分享一下。

一、项目需要一张数据表

这次算是一个全新的项目，从零开始，但是实际上第一版出来的功能已经非常多了。产品那边没有一个完整的功能列表给我，需求也是时不时进行改动。所以，在做设计的时候，总感觉会遗漏某些状态的变化，所以，针对这一点，我觉得可以有一张数据表。这张表就是工程师后台的数据记录，产品在规划功能的时候就需要把这张表格给罗列出来，然后在设计交互流程的时候，每进行一个步骤，都需要考虑这个步骤对于这个数据表格的影响，然后把这些变化完整地写进交互文档里面。

举个例子，由于我们的平台是一个优惠券发放的平台，那么这个时候涉及到两个主体：优惠券和领券的人，优惠券的数据就是一个数量的问题。不过对于领券人，数据表有如下：1、未使用的券；2、已使用的券；3、已过期的券；4、待付款的订单；5、已付款的订单；6、已退款的订单；7、积分；8、返利。罗列了一下，这些是最主要的数据，然后比如说订单的数据，因为订单是进行购买优惠券的活动的，所以订单的数据也会影响优惠券的数据。优惠券消费会有返积分或者返利，所以，优惠券的状态也会影响积分或者返利的数据。那么也就是说订单的变化也会影响积分或者返利。这些数据之间关系错综复杂，如果有一张详细的表格，可以把这些变化写进交互设计文档里面，我觉得逻辑会更加完整，对于开发人员来说也比较便捷。只是可惜，这些都是做完了才发现的，所以当时就没有做。

二、将功能模块化

这次的项目是我有史以来接到的最大的项目，项目功能比较多也比较杂乱，特别是后期加入了一个支付功能，导致整个交互逻辑的复杂度大大增加了。复杂度变大的坏处有三个：①难以梳理逻辑；②容易遗忘一些逻辑；③难以恰当地阐述设计。针对这三个缺点，我在做的过程中尝试将功能进行模块化。模块化的意思是将一些功能进行打包，然后只梳理这些功能之间的关系。梳理完之后，这些功能就形成了一个整体，然后其他功能只和这个整体进行交互而不和其中的功能进行交互。

这么说有点不形象，举个例子吧，就说电脑吧，电脑可以看成是由显示器、CPU、内存、硬盘等部件构成的，而其实显示器里面又是由各种零件构成的，显示器里面的零件就相当于我的功能，我所做的就是先把一部分打包成“显示器”，一部分打包成“CPU”，然后把他们当成一个整体来考虑。

显而易见就是，这么做首先每次处理都只是一部分问题，逻辑比较容易梳理，也不容易遗忘逻辑。当然，更重要的就是表达的问题。如果不进行模块化的话，我真的不知道该如何在一张画布上把这些逻辑流程表达出来，所以，模块化之后，我可以在每张画布只表达其中一个模块，当我把所有模块都阐述清楚了，整个项目也就清楚了。

当然，除了以上的种种优点之外，模块化还有一个优点就是方便复用。一些常见的模块，比如注册登录模块，消息通知模块，个人中心模块，这些模块在当今的APP里基本都存在，也就是说他们的复用率都比较高。如果在设计的过程中就已经将这些功能进行模块化了，之后如果需要设计新产品的功能时，这些模块就可以直接拿过来复用，省时省力。这个省时省力节约的是功能规划、界面设计、逻辑推演等等这些时间和精力，所以还是相当可观的。

先写这两点，后面还有公共交互和团队沟通的问题，后面再补。