交付单助手首页

本项目最大的收获为，得到了如何在时间紧迫资源稀缺的情况下，一稿过的设计方法。

电子交付单是公司的一个服务O2O项目，它替代了原来需要销售员（卖完加密锁后）打印纸质交付单，并去找客户签字确认，然后再回执到公司的过程，现在客户只需要打开PC端G+上的一个小工具（电子交付单的载体），插入新购买的加密锁并输入短信交付码即可完成确认交付的操作。

公司从中实现交付环节无纸化从而节约成本，以及避免某些“过分聪明”的销售员做出越过公司价值红线的行为（捏造假客户自己签单骗业绩）。

在主体业务上非常简单，但是在利益相关性上它需要同时满足客户，销售管理部，加密锁管理部，财务部，以及我本部门的共同利益，所以麻雀虽小，并不好搞~

另外在工期方面只给了1个月的时间。分配到设计上只有1周，而且UI设计师同学因为手上也有一个紧急项目，最早解放时间也要一周后，所以这个项目只能先我一个人来了......

定义设计活动

因为项目紧人员少，因此在开始动手之前就要好好考虑一下这次设计的活动范围，并明确重点，以避免草草收场的结局。

首先是红线思考（Dead-line）：

1）必须1周内出成果，成果为经过评审定稿的详细交互设计文档

2）必须满足内部干系人的诉求，因为他们是推动这个项目成败的关键

3）必须保证使用简单，这是一个UX设计师的基本操守......

因为时间太紧，再加上目标用户和过去的产品有重叠，因此就大胆决定不做用户研究，利用已有的认知共情用户。

综上考虑之后，设计活动也就基本就确定下来：

1）搞清利益干系人的诉求和用户诉求，优先满足用户诉求，其次也要满足干系人的诉求

2）确立产品的体验调性，功能架构，交互流程，界面原型及细节case说明，并产出到Axure文档中保存

3）中间过程始终保持与干系人的沟通和反馈，尽量达到让最终评审一稿过

搞清主要干系人诉求

干系人很多，试图都去满足，到最后可能都无法满足，所以确定谁是主要干系人最关键。

怎么确定主要干系人呢？通盘思考一下这件事的原委，可以推断出公司做这件事其背后真正的动机在于控制越过价值红线，如果我是老板，我肯定会让销售部自己定策略处理。所以销售管理部很可能是背后的主要干系人，因此决定在他们身上多花一些时间调研。

通过总计约3个小时的访谈后（期间断断续续），搞清了他们的诉求为“避免销售员越线，但又不能完全让加密锁交付过程自动化（销售员需要尽量多的和客户见面）”，并且了解到过去的场景是“销售员拿着加密锁去到客户那里，帮助安装调试好软件后，然后用户签字验收，销售员再把单子回执公司”。基于这个诉求，这次的设计基本原则也定下来，就是“尽量不改变原服务场景的基础上，通过电子交付单工具避免价值越线行为”。

再跟加密锁部门和财务部门访谈后，验证了我的想法，他们其实是配合销售部的工作，他们的诉求也都比较笼统简单，基本上都是“不要破坏我现在的工作流程，不要添加额外的工作量”，ok，这些基本上也都不是问题。

而跟本部门访谈时，部门提出来的诉求则比较的具体和“私利”，就是希望这个东西能为G+（部门重头产品）带来黏性，并且顺带推一下“服务授权工具”，提一下它的活跃。这些则需要在场景对头的基础上审慎的加入。

干系人的主要诉求有了，次要诉求也搞清了，接下来就是目标用户的诉求了。

搞清目标用户诉求

搞清目标用户诉求前，先要搞清目标用户是谁。根据前面访谈对场景的理解，这个工具的目标使用者一般是主管或者小公司的boss，而他们的画像之前就清楚了，所以就决定直接上马scenario推导用户诉求了。

还是时间紧迫的原因，只探索了最为核心的4个剧本，并根据这个剧本推导用户诉求。在推导用户诉求的同时，也对干系人的诉求进行思辨和整合。

scenarios推导用户诉求（needs）

期间最大的发现是可以利用“交付码”来实现不破坏原场景基础上，给红线行为加上有力的闸门。

交付码是根据交付单编号生成的唯一7位数列，会发送到用户的手机上（手机号是购买时登记的），这样再配合码和锁实现用户本人签单验收。

关于交付码的构想和优化，跟利益干系人聊了几轮，最终也都获取了支持。

让记忆转为识别

在#1和#2scenario那里反复迭代了几个版本，最初的版本是列出所有锁号（兼容多把锁场景），用户选择哪把锁，然后输入交付码列出交付单。这里通过利用“懒惰帽”法（带上这顶虚拟的帽子，摇身变为一个懒得要死的人，找找那里还能让我更懒）思辨，发现用户识别和记忆锁号是一个巨大的痛点，因此决定解决这个痛点。

相对于记起锁号，识别手机上的交付码是一件更容易的事。所以就以此为原点来思考，结合实际的场景经过几轮推演，确定现在的1#故事版本，并及时跟技术负责人沟通，发现这种方式可行，于是就确定了下来，并据此修改了后面的剧本。修改后，把这个想法口述方式传达给了利益干系人，干系人也觉得很不错。