业务与需求、业务设计与需求设计的区别

业务和需求，业务设计和需求设计，这两组词我们经常能够听到，那么你了解它们的有什么区别吗？本文作者站在软件工程师的角度，为我们进行了分析和说明，搞清楚它们的区别之后，或许会对我们的工作有不小的帮助。

“业务和需求”，这两个词软件工程师们每天都会用到几次，但却不一定很清楚两者的区别：

“业务”指的是软件客户现在从事的工作，“需求”指的是客户对未来系统的期望或要求，因此业务设计与需求设计是两个不同视角的设计。

正确的顺序是：先对业务进行充分的设计，然后基于业务设计成果再进行软件的需求设计。搞清楚这两者的定义、区别、相互关系，对需求的理解、分析，并通过设计提升客户的满意度是有非常重要的指导意义的。

一、需求与业务的区别

1. 业务

站在软件公司的角度看客户的工作时，软件工程师们把未来系统所要对应的客户工作称之为“业务”。

如系统要实现的业务包括：销售工作、人资工作、采购工作、财务工作、物流工作等，在软件工程师来看，不论客户的领导、还是普通员工的工作，都是客户的“业务”（注：在客户企业内部对“业务”的定义与软件公司是不同的）。

2. 需求

“需求”是指客户根据自身的业务内容，对即将要开发的软件系统所提出来的需要、要求，当只提“需求”两个字的时候，通常默认为是指系统的“功能需求”。

但是实际上在调研分析过程中，“需求”并不仅仅指的是“功能需求”，收集到的原始客户需求来自于不同的岗位、需求表达的形式也不近相同，如：

①企业经营岗：用信息化手段，提升企业竞争力（目标需求）；

②部门管理岗：在采购流程上设置审批功能，强化对生产成本的过程监控（业务需求）；

③业务执行岗：在合同界面上增加Excel表的导入功能，提高合同编制效率（功能需求）等。

从上面的三个例子可以看出：③直接给出了对系统的具体“功能”需求，而①、②则不能直接看出来对应什么样的系统功能。因此，需要通过分析①和②的需求，并将它们转换为具体的系统功能需求③，交付给后续的软件设计师和开发工程师。

可以从上述定义看出来，“业务”和“需求”不是一回事：

业务：指的是客户现在从事的“工作”；

需求：指的是对客户现在从事的工作在引入到信息系统中时所提的“需要、要求”。

二、需求设计与业务设计区别

清楚了需求与业务的区分，下面探讨一下“需求设计”和“业务设计”的不同，各自的目的、作用、价值以及相互作用。

1. 需求设计

有些软件公司常常使用“需求设计”一词，需求设计一般指的就是对收集到的功能需求，按照系统实现的要求进行的功能设计，需求设计的主要目的是给出对系统实现的“功能”描述。

2. 业务设计

业务设计，主要内容是对客户的工作现状按照未来的信息化标准要求进行梳理、优化、完善，如：物资采购流程的优化设计、组织管理结构的扁平化设计、成本过程管理设计等。

为什么需要有业务设计呢？

因为客户提出的需求大都是根据既有的工作现状提出来的，这些工作现状不一定是符合信息化要求的，管理方式甚至是落后、不科学的，按照这个工作现状提出的需求去开发系统，其结果可能是用先进的信息化手段、模拟了落后的工作方式。

这样做的结果客户最终不能获得信息化带来的价值，只有充分地理解业务、并对既有的工作现状按照信息化的标准进行优化、完善设计，在这个业务优化设计的基础上，才能确定需要什么功能、并依据业务设计结果判断客户提出的需求是否正确。

业务设计是需求设计的基础，顺便说一句，前面的①和②的需求，只有通过业务设计，才能找出来需要的是什么系统功能。

业务设计主要包括三个层面的内容，即：架构层、功能层和数据层，包括：

架构层：首先，从整体上对客户工作现状用架构图（分解图、流程图等）的形式进行梳理、优化、完善；

功能层：其次，对客户的每个工作（界面的原型）的具体操作内容进行梳理、定义、优化，制定操作层面的标准、规则等；

数据层：最后，对每个工作产生的数据建立标准、定义、采集规则等。

3. 两种设计的相互作用

两个设计的理念和目的是不同的：

业务设计：关注的是对工作现状如何用信息化的标准进行梳理、优化、再定义；

需求设计：关注的是系统功能该怎么实现。

软件工程师获得了功能需求，但如果不熟悉业务背景，直接去设计功能需求，就是“知其然，不知其所以然”。在充分地理解了业务、优化了业务、并在确定了未来信息化环境下业务处理最佳方式的基础上，再去确定功能需求、设计功能需求，才是做到了“知其然、也知其所以然”。

由于客户不是信息化专家，往往提的需求不一定正确，软件工程师通过对客户业务的设计，就可以正确地理解客户需求，并且可以识别出需求的真伪（同时，软件工程师也会根据自己的经验提出建议）。

也就是说，只有将“需求”放在“业务”的背景中去思考、设计，才能做出优秀、实用、客户价值高的系统功能。

总结，“需求设计”不是“业务设计”，也不能替代“业务设计”，业务设计有业务设计所需要的知识和方法。业务设计的水平高，完成后的系统带来的客户价值就高。

要想获得高水平、高价值的软件系统，就一定要先进行业务设计（业务优化），再进行需求设计。

为了活动快速上线，交互设计师是如何“排雷”的？

一个活动从设计到上线往往需要经历很多的步骤，需求繁杂、各方意见不统一……你对自己所做的设计能做到心里有底吗？一个活动上线之前还需要注意哪些问题，你能明确的说出来吗？下面的看法仅供大家参考学习。

一、项目立项阶段

项目立项阶段主要有两个“地雷”，一个是运营玩法和策划需求变更，一个是业务细节和熟识度不足导致的设计返工。交互设计师可以通过提前介入、整体活动逻辑可视化的梳理来避开“踩雷”，下面将分别阐述。

1. 排除“运营玩法和策划需求变更”的地雷

提前介入，从用户体验和开发成本角度管理运营玩法和策划需求。众所周知，一个活动从发起到下线流程如下图， 笔者一般是在运营立项阶段就开始介入项目，这个阶段运营往往会有很多玩法的脑爆idea，且开发资源尚未介入，交互设计师一定要站好这个节点的“岗”，防止有纰漏的玩法方案溜进需求池。

提前参与玩法需求讨论可以让我们更全面地了解活动目标、针对人群，以及运营想推的活动玩法，在想法产生之初通过交互设计师的专业建议使活动玩法更加落地可行、体验优雅、带来更多转化，降低返工可能性，提升上线效率。

此时交互设计师一方面要站在用户体验角度上跟运营说明哪些idea会增加用户认知和操作成本，降低活动转化率，以及优化建议；另一方面站在开发角度跟运营说明哪些想法开发成本高，可能在限定的日期无法上线，如果坚持要做的话，需要与开发同学确认技术方案或申请更多研发资源；第三方面是基于交互设计师对用户心理学天然的了解，建议运营同学如何在活动中利用诱饵效应、从众效应、目标阶梯效应等方法提升用户的转化。

大家一定要谨记“提前介入”，否则等idea经过运营策划立项后推进到交互阶段发现问题要修正的话，会浪费极多的项目时间和团队精力。一方面是因为重新组织各方讨论的协调难度很大；另一方面是因为运营和策划已为玩法需求付出很多时间和精力，过程中必定相互洗脑要推的方案是可行且完美的，说服他们接受新修改意见的沟通难度和耗费的时间成本可想而知。

2. 排除“业务玩法、技术方案等理解不足导致设计返工”的地雷

活动立项之后，尽可能完整地梳理完整的业务流程图、功能流程图。对于复杂一些的活动，业务流程图一定要输出（也可以和策划协作一起输出，或者规定让策划同学输出）。

梳理业务流程图的过程就是理解活动玩法的过程，将运营用文案表达的玩法规则进行可视化。业务流程图可以让各方对活动玩法、流程、功能状态流转一目了然，便于让各方发现新的问题点，及时修订。

梳理功能流程图是促使策划和开发将项目中所应用功能的技术方案一一确认，减少后续设计阶段的变数，增加输出设计文档的确定性。

如果对规则和玩法复杂的活动没有清晰的理解就盲目开始设计，很容易囿于细节而失去全局概念，后期如果规则玩法、活动流程或技术方案稍改就会被推倒重来，做很多无用功，耽误上线时间。

二、项目执行阶段

项目执行阶段主要有三个“地雷”，一个是设计方案输出效率低，二是各方信息没有对齐，三是开发过程中各方沟通不顺畅。交互设计师可以通过模块化的组件设计、组织交互评审会和及时跟进开发测试中的突发问题来避开，下面将分别阐述。

1. 排除“设计文档输出效率低”的地雷

在以往的活动中，我们搭建的活动配置后台里已经沉淀了很多复用性高的组件，可以用组件像乐高积木一样快速搭建普通活动，这种方式这样可以极大的提高活动上线效率。一些新玩法活动现有组件无法满足，需要梳理后设计控件的样式（采用按键、热区、上下结构、左右结构等）。

组件交互设计的优先级是：稳定性-易用性-拓展性：

所谓稳定性是活动组件设计的第一大原则，需要交互设计师尽量保证组件逻辑简单、开发难度低且能承受活动短时间高并发环境的压力，这样才能保证在开发同学在较短时间内快速上线且bug少；

所谓易用性是易于用户理解和操作，这直接关系到用户在此组件触点的转化率；

所谓拓展性是两方面：一是后续可以应用到其他活动中，二是为活动的视觉设计阶段保留了更多样式发挥的可能性；拓展性强的组件可以在后续活动配置中持续使用，长期来看提升活动上线效率。

2. 排除“各方信息没有对齐”的地雷

交互评审是促进各方信息对齐的最最重要的扫雷秘诀。因为交互设计师需要将运营玩法、产品需求、业务逻辑，以及用户体验相结合，转化为各方可见可理解的低保真模型，所以交互评审十分重要，即使时间再紧也不可或缺。

交互评审的目的是让运营、策划、视觉、前后端开发、测试同学更加直观和形象的了解活动上线的大致呈现效果。运营和策划可以据此判断方案是否符合他们的需求，视觉可以构思活动页面的装饰元素和视觉风格，研发可以据此确定前后端接口、评估开发工作量和预估工时，测试同学可以以此来进行测试用例的输出。

评审方案的时候有两个技巧可以提升评审效率。一是按照活动前中后三个阶段来给大家进行讲解，这样会让各方更易理解。二是前端组件样式和对应的后台配置一起讲，这样不仅可以方便运营同学知道如何配置，和各配置项在前端如何展示，也方便开发同学快速梳理数据接口和核对参数。

交互设计师针对会上的功能点实现问题、前后端配置问题等暂时不能确定的，会后一定要拉各方核对定稿。即使活动上线周期十分紧急，也一定要进行交互评审，磨刀不误砍柴工，千万不能为了省时间而省略该步骤，否则各方在信息没有对齐的情况下按自己的想法推进，一旦出现执行偏差，必将需要更多的时间来弥补。

3. 排除“视觉、开发和测试过程中各方沟通不顺畅”的地雷

视觉设计过程中，视觉同学对活动控件有新的想法或做了方案调整，需要及时沟通确认调整后的方案仅仅是样式的变更还是修改了控件的逻辑或字段，一方面需要确定视觉改动是否可接受，另一方面如果改动控件逻辑或字段的话需要找对应开发同学沟通，看是否增加开发难度和工作量，是否会影响上线时间。

开发过程中，开发、测试同学中对于交互文档中的细节有疑问时，交互设计师需要及时答疑。部分功能或流程因为技术实现问题或开发周期问题，需要组织各方沟通讨论出新的替代方案，需要对设计方案进行及时修订并将修订记录同步全组。

测试验收过程中，测试同学完成第一轮冒烟测试后，交互设计师就可以进行交互走查验收：

第一，将走查发现问题创建验收清单，采用有道云协作来创建截图、问题、终端、备注的表格，将走查过程中发现的问题整理进去，便于测试、开发同学查看和跟进。

第二，确定修bug的优先级，按照普通用户参与活动路径设立优先级，及时跟进和更新修bug的结果，上线前一定要再走查一遍，防止一些修好的bug复发和一些修bug过程中新产生的bug；

第三，关注高并发压测环境下可能出现的问题，如果时间紧急没法变更技术方案，就需要通过采用用户体验的方法来进行引导或补救。

为了保证各方沟通顺畅，除了及时跟进处理各方遇到的问题外，交互设计师需将每日跟进的沟通结果和修订记录在项目组里同步。这样一方面让运营、策划、开发、项目管理等各方了解项目最新变动和进度；另一方面营造一种大家共同推进活动的感觉，让项目组同事更愿意相互协作配合工作。

三、项目收尾阶段

项目收尾阶段主要是物料准备不充分的“地雷”，交互设计师可以通过走查物料准备情况来避开。

排除“物料准备不充分”的地雷

活动项目中有很多物料需要准备，在线上活动项目中设计师需要重点关注的是活动冷启动阶段前置假写数据的准备和上线预演。假写数据的益处显而易见，例如在某些活动中前置假写的弹幕数据可以在冷启动阶段很好的营造场面热烈的氛围，激励用户“从众心理”参与活动，但在真实数据进入后要立即清理掉假数据避免造成用户信任危机。

活动上线前各方联调时，由于大家都忙于走查功能、合并代码、准备预发等，经常会出现假写数据准备不充分或者遗漏的情况，这个阶段交互设计师一定要检查到位，并且确定假写数据的上下线策略。

总结

交互设计师也可以整个项目过程中实时收集各方从项目立项到项目收尾过程中对活动项目的的想法和建议，包括玩法策略、业务逻辑、交互视觉设计、开发过程等，一些好的建议可以在后续开发中推行，让项目协作更加顺畅，项目上线更加快速高效。

以上是小编在近些时间参与活动类项目过程中，交互设计师促进活动类项目快速上线的一些经验沉淀。虽然不同公司、项目在活动流程、团队协作中有所差异，但交互设计师在项目前、中、后阶段遇到的“地雷”大致相似，希望对大家有所帮助。