上次的后台系统规范发布之后很多同事都给予了我们肯定，给了我们很大信心。谢谢大家。
我们的后台系统现在有新版本在不断地发布。原来的系统规范也就开始不适应所有的环境了。
下面是我们需要的困难以及解决方案：
1.功能不能满足需求只有上线之后用户真正使用了才会发现新需求。之前的系统是1.0版本主要满足“可用”，等到系统跑起来了，用户开始追求这个系统的“易用”
对应方法：添加新功能——通知功能，配置功能，映射功能，高级管理功能
2.用户层次多系统上线后，我们的用户数量开始增加，在用户中就会有一些高级用户，他们的权限会比普通用户高。
对应方法：系统权限增加——负责一些类目，权限等配置
3.技术同学数据订正量大系统上线之后数据量会很大，由于系统的严谨性和用户的操作失误，使得需要订制的数据量很大，技术同学会把一部分资源耗在这里，耽误正常的项目
对应方法：高级管理功能+系统权限——只有具有高级权限的小二才能进行系统配置。可以更改相应的数据。
4.个别用户需求BI部门，业务部门等特别希望系统中能有直接进行数据分析的地方
对应方法：分阶段实现——主要通过沟通，和其他部门沟通，确定大家都能接受的方案
好了，现在有了对应的方法，那么这些功能我们怎么来进行设计呢？互联网发展到现在这中间阶段，基本上在线下的任何沟通方式都能在线上看到。所以，只要用户保持在线，系统能够解决所有沟通需求。好的产品，背后都凝聚了设计师和技术工程师们的智慧。我们的用户也会使用这些产品，完全可以设计成这些产品的交互形式，使用户方便使用，而不需要重新学习一套交互形式（重新学习的成本是很大的）。
1. 邮箱VS通知中心邮箱是线上的通讯工具能保存所有的邮件记录方便查看，我们系统也需要一个类似的功能，但是不需要写邮件，不需要看发件人是谁。
下面是某邮箱的效果。
我们保留了他的基本功能，还有我们这期系统需要的功能，把其他功能都删除是用户使用更简单。
2.即时通讯VS整改即时通讯是现在用户几乎都是用的工具，整改的业务逻辑和它一样，所以我们采用了同样的方式。
我们的效果
这样既能在短时间产出，用户使用又会很方便。
我们要注意的几点：
1.可用性测试设计好自己的模型后，给用户看，进行可用性测试。发现是否能满足用户预期，再进行修改，从而减少开发成本。
2.贴近用户后台系统在实施过程中一定要贴近需求方，甚至和需求方一起工作，了解他们的业务，了解他们的习惯。从而做出对大家都好用易用有感情的商品。
作者：张科
文章来源：阿里巴巴良无限UPD团队Blog
