新设计师可能都会遇到这样问题：在设计个复杂需求时候，各场景、可能性在脑来回乱窜，常常觉逻辑不够严密。设计完成后，又被各质疑，提出各异常场景，导致频繁改，缝缝补补。本文将和大家分享下解决以上问题小法。
本就「企权限分配平台」的需求为案例，整了之前处复杂需求的一些思路。讲讲在交互设计的过程中，如何避免上两种情况，我们的工作更好地务户，体现值。
首先，我想任何设计师在设计产的时候第一步都是解需求，这包括了需求的目标背景、角色场景、产逻辑等，同的需求侧重点会同。「企权限分配平台」的需求为例，目标背景和角色都较简单，但是一般涉及权限的产，背后的逻辑就会很复杂，场景情况很多。
和产品沟通，和用户沟通，甚至网上找资料，都是理解需求的一些好方法。比如本次计的需求是关于权限配，这一篇《网易高：角色权限计的100种解法》的文章，就好地帮助理解权限配背后的计逻辑。
包括理解需求内的专词，其建立特殊的标识样式，也帮自己、团队、用户好理解产品需求的一种方式。
△ 名词解释
在最初思考需求的候，肯定会从景/问题出发，思考怎去解决这个问题，是以「人」的思维来思考这个问题的，这是必然的，也是正确的。但此的思维是散点式的，例如当想权限配的需求，可能会说：这次要新增一个「岗位」的概念，让权限和岗位绑定，不要和人绑定。对了，还有人员离职这个问题困扰业久了，这次要在人员离职的候进行……
所以，初的需求框架确后，我得到的这样两段文字：
看去已非常全面了，但由于我们散点式收集需求，很多时候可能还会遗漏，或者错误关联了内逻辑，导致一些逻辑冲突、漏洞。
此时，我们需要将我们的思从「散点式收集」转为「结构化梳理」。从需求说明里抽丝剥茧，我们以得到：
- 用户角色三类：超级理员、业务理员、HR；
- 操对象是：部门、位、人、权包；
- 可执操作括传统：增、删、改、查，有和本业务相关「关联」，即权限赋予。
各对象之间的关系又怎样呢？我们把所的对象两两组合，再把关系的删掉。
也就：
- 在部门可以下立岗位，岗位必须从属部门；
- 人员必须从属某一部门；
- 人必须从属某一位；
- 权限可以赋予部；
- 权限包可赋予给岗位；
- 人员和权限包没有任何直关，这也是本次权限配的核心。
这个具体的务逻辑并重要，需要心解，重要的是这样一种结构思考的方法，可应在后续各种各样的设计中。
对象间的关，再和刚才梳理的人物、操作相结，就可以还成一系列的需求描述：「角色」可以在「A对象」下「操作」「B对象」，例如：超管理员可以在部门下新增岗位。
至此，我们已可以建立「需求→功能对应表」：
其中，色部分都之散点式的需求罗列中考虑到的功能点，通过结构化的梳理，我们可以提把它们都一一补齐。
这过程可以减少我们小颗粒功能点的遗漏，避免完部分设后，突然发遗漏了某功能，任务时间点又已到了，慌慌忙忙加功能，就可能会影响整体的设思框架。
完了功能点的整理归纳后，就可以始我们的界面设了。初的界面设中，这三点需减法：
- 优先进行框架计，不要在一开始就考虑细节；
- 优先完主流程，再考虑异常场景；
- 按照功能对应表将各个模块独立设计完成，添加快捷操。
当然，可以先把可能存的异常、细节都记录下，以便后续补充。
比，在人权分的界面结构中，分为三个大模块：
在有界面框架和功能对应表，我们做设计变得比简单，按照之前整理的「需求→功能对应表」，把每个小颗粒的功能细节填充到界面框架内即。
当主流程设完毕之后，我们就始加法了，之，我们一直用一种纯理性的视角完我们的设，保持纯理性的设会两问题：
- 多业景靠逻辑思维是无法想象的，必须身地站在用户的角度去思考，才能理解景，进而补充可能的体验细节。
- 纯理性的设，可能功能点完整的，但用户体验缺失的。
例如，纯从逻辑思维角度你能想在一个企业有人是没有任何部门归属的吗？然而现实中就存在这的情况──外包人员。不结实际景，也不知道用户一需要理多少次重复操作，目前的计对是否足够便捷。
作一企业内部权限分配平台，我们可以把部⻔、岗、人员对象作初始线索，站不同的用户使用角度，沿线索去全面思考场景，修改功能。一些实难以理解的业务，找用户聊聊也一好方法。
很快，我们就找到下面特殊场。
1. 人变动
- 新增人员流程：找新加入部门→找岗位→添加人，由于企业内部还有一个最基础的 OA 系统，那HR是否会需要重复操作，一个人员在不同添加次？是否增加了的工作成本？
- 人员变动频繁，否易遗忘？
理方法：行政架构动同步，红点待。
OA 系统数据通，动形成四类待红点：人员新增、人员离职、行政部门新增、行政部门删除。
这样 HR 就不需重复新人员的添加操作，只需业务理员把 OA 内无法覆盖的人员岗设好就可以，也不会出遗漏的况。
2. 高兼职
例如某高：本身 A 部门负责人，临时兼任 B 部门负责人，那么当他不再负责 B 部门时，该如何处理他的岗？离职？转岗？似乎都不合。
处理方法：新增位移除功能。
3. 外包人
到现情况中，外包人是没有部门归属的，但是际上他们肯定也有自己负责的业务范围和位，在初始化时何安置没有部门的人？
处理法：新增个部，叫做「岗位员」，并标红作为待办，提醒操作者去处理这些「岗位员」。
4. 员离职/转岗
在进功能设计合时，我考虑是否「员离职」应该叫「员删除」更系统化？是否可以接合为个「员编辑」功能，将离职、转岗操作合并？（实上这2个功能操作起来确实比较相似）
处方法：最终我依然保留了「人员离职」、「人员转岗」的功，因为这样更场景，户清晰地知道自己当前该操作么。
目前对一个人进行离职操作的路径是：找部门→找岗位→找人→理离职，而的企业有 2500+ 员工，对于离职操作者 HR 来说，这个路径是否现实？是否快捷？
处理方法：新增搜索功能，直接搜索人→处理离职，这功能也方便了其他找人的场景。
5. 多
诸如此类的考虑还很多，例如新建部门的时候否会空部门，企业行组织架构重组时否会批的人员、组织变动，需批操作。找到初的线索，站用户的角度沿线索思考，行全局扫描，就会发很多需加法的方，发的方式可以观察、访谈、思考任何方式。
在已经证主流程的简洁、清晰，用局扫描的方式去搜集特殊场，给我们的设计做加法，以证我们整的设计框架是清晰用的，而特殊场是散落在骨干上的各种小分支。
如我们可以做到，所有主干场景、分支场景了然于心，并有自己优先级考虑，那么于项目成员、用户提出质疑，我们也有足够理由来证明自己设计合理性。
当然，场景基本考虑全面后，还有最后一步，就是统一交互，善细节，这一步是设计上的法。
上，就是一个针对复杂需求的减设计法案例，总结来说有个大步骤：
- 从实场景出发，发现问题，理解需求；
- 需求结构：把本源的场景、需求结构成功对应表；
- 计的减法：先解决最根本的问题；
- 设的加法：回归场景，全面考虑。
所以，交互计是需要理性和性的结，要有抽丝剥茧，提炼总结的能力，也要有贴近用户关注情的细腻。把的工作规范化，减少无效付出，也是的一种能力。希望本篇文章对新人计有一些帮助，也欢迎大家一起探讨交流。
欢迎关注「网易UEDC」公众号：
浙公网安备33011002017549号