在 To C 产品中经常可以看到基于场景进行的设计，比如旅游类 APP 在获取你的定位后，给你推送当前城市相关的旅游信息;支付软件在你支付后推送周围餐厅的优惠券;当你买完机票后，会给你推送目的地的酒店信息等等。

　　在 To B 产品中，存在的场景会更加复杂。因为 To B 产品更多的是提供一个针对某个特定问题场景的完整解决方案，在这个问题场景中会存在特别多的角色。只要把握住「角色」这个问题，就可以在不同「角色」组成的小场景中，进行有针对性的设计。

　　在从 C 端转向 B 端时，非常容易忽视的一个就是角色的区分。不同的角色在面对同一个功能的时候，需求会不一样。如果说能根据这个区分出不同的场景的话，将会更好的引导用户对产品进行使用。

　　面对一个功能，不同角色的主要工作内容肯定是有区别的。比如云之家的签到轻应用，主要分为3个角色，签到管理员、经理(以经理为代表的管理角色)、员工。他们在面对签到的主要功能分别为：管理签到规则、根据出勤计算工资;查看员工出勤情况并进行管理;签到打卡。那么这三个角色在进入签到的时候则会有不同的需求，且我们需要根据不同的情况进行引导。

　　下面将以签到为例，讲一讲在对签到进行优化的时候，我们基于不同的场景做了哪些设计。

　　「签到」的背景

　　签到是云之家的一个轻应用，周活在轻应用中排名靠前，但是转化率一直稳定在比较中庸的位置。

　　分析了一下问题的原因，主要有两点：一是客观上功能性方面与竞品存在差距;二是设计上的缺陷，用户引导上并没有做的很好。所以，我们以提高转化率为目的，对签到应用进行了分析和调研，并重新进行了设计。

　　那么如何根据角色进行设计呢?主要分为这几个步骤：

　　需求的目的：在设计之前的大前提，是明确需求目的，以目的为准绳，防止自己在之后的思考走歪路。其实这一点是非常重要的一点，对于比较复杂的功能，涉及的角色较多的时候，设计师在经过长时间的深入思考可能会出现思维跑偏的情况，时不时地回头看一看自己是否脱离了需求目的是非常有必要的。明确了功能需求的目的，才能够以此为准绳进行设计。

　　包含的角色：明确涉及到此功能使用的角色一共有多少个

　　主要角色是什么：找出主要角色

　　角色的场景：正确理解不同的角色在此功能下的使用场景

　　分角色进行设计：针对主要角色和次要角色分别进行设计

　　1、需求的目的

　　其实目的已经非常明确了，就是需要提高签到应用的转化率。但是，在此之前仍然需要进行调研。经过用户电话回访得出，用户在放弃使用签到的原因总结起来有两个方面：

　　功能性缺失：这个主要是在竞品的比较下，云之家的签到功能覆盖面相对而言会比较窄一些，相对复杂的场景没有覆盖到，导致用户在对比之下选择了竞品。

　　设计上的问题：这个主要体现在“不知道怎么用”、“界面太复杂”、“找不到我想要的功能(但其实功能已经存在)”这三个方面

　　针对第一个方面，在功能性的扩充上是一个持久战，需要花费很大的精力和人力去解决这个问题。但是第二个方面，却是设计可以比较方便解决的。所以，我们从第二个方面入手，去解决由于设计带来的转化率低的问题。

　　2、包含的角色

　　这也是一个非常容易回答的问题，只要设计人员对于产品的情况充分的熟悉，就能够很容易的回答出这个问题。

　　签到应用中包含的角色有：

　　管理员(团队)

　　签到管理员

　　老板

　　经理

　　员工

　　当角色过多时，我们需要分析角色的权限功能，看能否「合并同类项」。以上的 5 个角色，合并后变成了 3 种：

　　管理员：在这个场景之下，签到管理员和管理员的权限功能都是一致的，就是「能否对签到规则进行管理」，我们通过这一个功能来定义用户是否为「管理员」。当用户拥有权限的时候，会对其进行针对性的设计。

　　经理：以经理为代表的管理层人员，在这种场景下，除了基本的签到功能外，老板和经理都是对员工的签到情况进行查看和管理的角色，区别仅仅是查看范围大小的不同。

　　员工：被签到规则约束的角色，主要操作就是签到。

　　3、主要角色是什么

　　管理员、经理、员工，三中角色哪一种是主要角色呢?如果按照人数来的话，员工无疑是最多的，占据 9 成以上的比例。但是事实就是这样的么?