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