设计案例：SmartX 合作伙伴网站

ROLE

Only Designer

TIMELINE

2018

PLATFORM

Web

Client

SmartX

MY CONTRIBUTION

Prototyping

UI / UX Design

Product Management

Project Management

Product Documentation

项目介绍

SmartX 合作伙伴网站 (SmartX Partner Portal) 是为 SmartX 销售部门及其合作伙伴定制的 Web 系统，帮助公司管理商业机会，与合作伙伴共享业务、技术、销售和营销等资源。

客户原来使用 Salesforce 产品追踪商业机会和更新进展，但产品上缺少扩展性和灵活性，无法将合作伙伴加入系统参与到整个流程中，虽然 Salesforce 可以与其他产品进行简单的集成，但是无法增加复杂一些的定制功能。因此，客户希望开发一个满足其定制需求的合作伙伴网站。

合作伙伴网站面向内部和外部两种用户，内部供销售团队成员使用，外部主要供代理商使用。定制需求除合作伙伴提交商业机会外，还增加了销售资源管理（例如合同模板、培训视频等）、信息发布（通知销售政策、产品信息等）、代理信息查询、代理信息资格审核等多个模块。

这个项目是目前工作室完成的最复杂的一个项目，作为项目唯一的设计师，也是一次前所未有的挑战。在整个设计过程中，除完成了 UI 和 UX 等设计工作外，也承担了产品的职责，前期撰写产品需求文档、测试用例，后期参与样式走查和产品测试，以及开发过程中整体项目进度的把控。

100+ 页面

按功能将系统划分为 8 个部分，独立完成 100+ 个页面的最终设计。

10+ 文档

整理撰写产品需求文档、测试用例、页面汇总、UI 样式走查、问题记录等文档。

设计难点

合作伙伴网站在设计上既面临 SaaS 工具通用的难点（涉及多种角色和复杂的流程），又要解决一些定制化需求的问题。每一个定制功能都有较为复杂的流程，不同角色参与其中又使产品复杂度大大提升。

下面是我们在设计系统时主要面临困难：

1. 角色多样，团队层级复杂，需要复杂的权限设计

合作伙伴网站涉及团队内部销售团队和外部代理商共同参与，在系统中对应不同的系统角色，拥有不同权限和操作流程，因此账号系统是需要解决的第一个问题。

另外在销售团队内部按部门、地区划分了多个层级，这些层级关系需要在系统中反应出来，比如销售团队的各个部门、团队成员上下级关系等。在功能上行政角色也扮演重要的角色，客户对此的需求是：

所有账号由销售负责人统一管理；

按部门组织团队成员、项目；

部门负责人能看到本部门的成员和项目；

允许上级查看下级的工作内容，并进行操作；

允许销售负责人查看所有人的工作内容和操作记录；

代理商只允许看到部分信息。

系统角色

网站涉及多方参与，包括合作伙伴和内部销售团队，在系统中分为销售人员、代理商和管理员三种角色。

行政角色

系统中团队成员的角色与实际销售团队中的岗位职级挂钩，团队内部上级可查看下级工作内容，并有权进行相关操作。

部门层级

销售团队按照部门、区域划分了多个层级，在系统中按部门组织成员和项目也是一个常用的维度。

2. 功能模块多，流程复杂，需要建立清晰的信息架构

系统包含几个主要模块：项目机会管理、销售资源管理（例如合同模板、培训视频等）、信息发布（通知销售政策、产品信息等）、代理信息查询、代理信息资格审核等。

不同系统角色的加入，更提升了系统的复杂度，比如在同一功能下，不同角色会拥有不同的用户流程和用户页面，设计上也需要区分考虑。

另外还有账号系统、个人信息管理以及包含网页和邮件的通知系统等底层通用模块需要设计。

项目机会管理

代理商发现项目机会，提交给销售人员，销售人员负责审核、提供反馈建议，项目机会被接收后，代理商需要定期更新项目进展，直至项目成功或被关闭。

销售资源管理

销售人员和代理商在与客户沟通过程中会用到很多销售资源，例如公司资料、合同模板、招标参数、技术白皮书等，系统为这些资料建立一个统一的管理平台。

信息发布

公司向团队内部或合作伙伴通知最新信息的平台，比如介绍销售政策上的变化，或新发布的产品信息等。

代理信息管理

代理商需要向公司提供资质文件证明符合资质，企业也可以为代理商颁发授权证书，或者对代理商成员进行技能认证。

3. 数据的展示、处理和保存

项目中包含大量的数据，例如客户信息、项目信息，数据会在代理商、销售之间不断流转，整个过程中项目数据也会不断地增、删、改，因此如何从繁多的数据中区分出优先级，以及选择合适的交互形式将这些数据清晰地呈现出来，是另外一个设计的难点。

系统中的数据和资料十分重要，客户对数据的完整性有很高的要求，要求系统记录每个项目每次更新的信息和每位团队成员的操作记录。比如在合作伙伴提交项目后，项目可能经多个人维护，且更新的内容不一定准确，因此更新项目信息后，需要记录操作人以及修改的内容，以便追踪和回退。

在数据安全性上，系统要实现每天定时自动备份。

4. 及时可靠的通知系统

系统的每个任务的创建起码会有 2 名以上用户的参与，比如代理商将项目机会提交给销售人员审核，销售人员需要及时处理并返回给代理商更新信息，代理商更新后需要再次提交给销售人员……

系统中任务状态会经常发生变化，当发生变化时，任务涉及的所有相关人员需要及时得到通知才能保证任务的顺利流通。因此系统中需要设计一套及时可靠的通知系统，来保障功能的正常运行。

设计流程

接到项目委托后，我们并没有急于开始真正的「设计」工作，而是花费 2~3 周时间用来进行产品调研工作，因为我们相信只有真正地理解了客户的问题，才可能找到最合适的解决方案。

1. 理解问题

理解问题是找到解决方案的前提条件，我们从开始理解用户和理解产品流程开始着手。

因为合作伙伴网站涉及内部和外部用户参与，所以第一步我们需要明确参与的所有用户身份及其在系统中扮演的角色，然后将不同身份用户和在系统中的权限一一对应，统一整理到列表中。

2. 产品调研

明确使用系统的用户后，我们需要进一步了解产品的功能以及可能的设计方案，为此我们展开了产品调研工作。

用户访谈

与销售负责人和一线销售频繁沟通，了解实际用户希望通过产品解决的问题；

了解用户现有的解决方案及其在使用过程中的痛点；

理解每个功能的用户流程，弄清楚一个项目是如何在不同用户间流转的；

竞品调研

调研类似的 SaaS 产品在账户系统和权限设计上的解决方案，分析优劣；

调研在类似功能上做的比较好的互联网产品，比如在准备设计操作记录和历史版本时，参考了 Google Docs，Dropbox Paper 等文档工具。

3. 需求分析

通过调研获得足够的信息后，我们开始了对产品流程和需求的梳理，将其规范为文档。我们使用在线协作文档编辑，并邀请客户共同协作，这样客户我们遇到问题可能及时向客户获得反馈，客户发现问题也可以直接纠正。

本阶段的主要产出有产品流程图、产品需求文档和产品页面列表。

产品需求文档
产品流程图与客户确认无误后，开始撰写完整、详细的产品需求文档，包括各个功能模块以及账号系统、通知等通用模块的需求定义； — **产品需求文档** 产品流程图与客户确认无误后，开始撰写完整、详细的产品需求文档，包括各个功能模块以及账号系统、通知等通用模块的需求定义；

产品流程图
各功能模块的用户产品流程图； — **产品流程图** 各功能模块的用户产品流程图；

产品页面列表
根据确定的产品流程和需求，列出所有需要设计的页面，按功能组织，并给每一个页面编号。 — **产品页面列表** 根据确定的产品流程和需求，列出所有需要设计的页面，按功能组织，并给每一个页面编号。

4. 设计探索

在明确需求和问题后，终于进入到了设计探索阶段，在此阶段我们对产品的视觉设计和交互形式进行试验，找到最合适的设计方向。

视觉设计

在视觉上我们希望与客户公司风格保持统一，能够在视觉上加强关联性。因此从公司官网和现有产品中提取设计元素进行尝试；在主色调上复用了客户公司产品的色板。

交互设计

探索导航结构，页面布局、列表视图、弹窗等交互形式，针对主要页面和流程进行原型设计，通过 Invision 与客户协作，听取客户反馈并改进，为正式的 UI 设计做准备。

解决方案

1. 账号系统 & 权限设计

搭建系统第一步要考虑账号系统的设计，考虑到方便管理员进行内部管理和团队成员及时接收通知，客户采用了企业邮箱作为系统的登录账号，首次登录时需要设置密码，后续通过邮箱+密码的形式登录系统。所有用户通过管理员在后台统一管理，添加、编辑或删除。

管理员账号：系统默认创建，分配给销售部门负责人；

团队成员账号：管理员在系统中添加成员，成员即可在邮箱中收到系统注册邀请，点击后设置登录密码即可完成注册；

代理商账号：代理商先确定负责对接的联系人，并将邮箱提供给系统管理员，管理员在系统中为其添加代理商账号，联系人即可在邮箱中收到注册邀请。

账号创建后，接下来需要考虑的问题是账号的权限设计，不同身份的用户在系统中能进行的操作是不同的，而且用户在企业中的行政角色和系统角色耦合，因此不能按照单一角色属性设计权限。我们通过以下几个步骤设计了账号的权限：

1.1 分解复杂权限

我们按照产品功能将系统划分成多个模块，每个模块设置不可访问、只读、编辑（管理员）三个基本权限，实现权限上的可定制化，可以为不同角色定义不同的账号权限。对于离职的用户，关闭其登录系统的权限即可。

1.2 上下级权限设置

客户要求上级可查看到下级的数据和操作记录，并且可以进行相关操作。因此在创建用户表单时，设置了直属上级项，根据此项在系统中标记公司内部的树状职级结构。

1.3 不同部门的权限

对于拥有特定权限的部门用户，在管理员创建账号时，如果在「部门」一项选择了该部门，就会打开默认设定的权限组合，管理员可在此基础上继续调整，为管理员节省设置时间。对于不同部门的用户，设置不同的默认初始权限。

2. 梳理各功能的用户流程，确定信息架构

解决账号系统和权限设计方案后，开始进入了具体功能的设计。

我们从整体入手，首先明确系统的导航结构，之前设计探索中已经尝试了几种不同的解决方案，最后综合考虑系统管理员、销售和代理商具体的使用场景，选择了最直观、兼容性也最好的一个。

确定整体导航结构后，进入到各个功能模块的设计，根据之前整理的产品页面列表，按功能优先级依次设计。按功能模块设计可以让我们在完成一个相对独立的功能后及时更新到 Invision，及时让客户看到项目进展，收集他们的反馈，这样能提早发现问题，避免问题积少成多产生大的修改，影响项目进度。

3. 更新记录和操作日志

为了保存完整的记录系统中发生的事件，我们将记录分为分为两种类型：用户操作记录和项目操作记录。

用户操作记录记录用户在系统中进行的操作，只对管理员可见。

项目操作记录只在项目机会管理中存在，是围绕单个项目的操作记录，聚合多方用户（管理员/销售/代理商）对单个项目进行的操作。

所有操作记录包含以下元素：人、动作、被操作对象（内容）、时间。我们以此在文档中整理了所有需要被记录的操作。

3.1 项目更新记录

记录提交任务的时间，每次提交保存一个时间点，点击进入可查看该版本中修改的内容；

3.2 项目操作日志

即项目操作记录，记录每次提交任务的操作人和修改内容，可以清晰追溯变化；

3.3 个人操作记录

记录用户在系统中进行的操作，只对管理员可见。

4. 通知整理

通知的设计贯穿到整个系统中，几乎与所有功能模块联动，设计花费大量时间来整理所有的通知类型，包括操作、通知对象、通知形式、通知文案等内容。在通知被触发后，将会以下列几种方式通知到用户：如何保证用户在登入系统后的第一时间看到需要处理的任务？我们在首页增加了通知模块，用户可以立刻知道新增的任务数量，及时处理。

4.1 网站通知页面

汇总所有通知类型，支持通知中链接、操作入口以及标记已读。

4.2 邮件通知

对于需要用户及时处理的重点通知，除在系统通知中展示外，还会出发邮件通知。

4.3 首页通知模块

方便用户在登录后第一时间看到需要处理的通知。

总结

这个项目是工作室完成的第一个企业产品，也是目前为止最复杂的一个项目。作为项目唯一的设计师，独立完成一个包含如此大信息量和复杂的产品流程也是一次前所未有的挑战。整个设计过程从沟通需求到最终独立完成全部设计上花费了近两个月的时间，真正用在「设计」上的时间只有一半左右，更多的时间用在了与客户沟通、产品调研、写产品文档、以及后期测试等工作上。

从这个项目中获得的设计经验扩展了我对设计工作的认识：设计过程并不只包含打开软件画 UI，那些只是在后期呈现你解决方案的手段。特别是在面对复杂问题时，不要急着去开始设计，理解问题是最重要的，因为设计用来是解决问题的，如果理解问题上出现错误，就不可能找到正确的解决方案。

另外的收获是加深了我对企业产品的理解，有了处理复杂问题的思路，我也有信心尝试用设计去解决更复杂的问题。