业务不熟悉，还能完成设计任务吗？

众所周知，B端产品和C端产品因为目标用户，使用场景，业务和本质，产品需求，产品思维，设计原则等因素的不同，使得两者在设计上存在着巨大的差异。

本文主要是以B端产品为主，阐述在不熟悉业务的情况下，设计师如何开展工作。希望可以抛砖引玉，引发大家更多的思考。

设计师需要懂业务，这是做好产品设计的基本条件。

但是在实际工作中，往往任务急，时间紧，有些业务知识还没有来得及消化就要被赶鸭子上架。

一般而言，C端产品的业务逻辑相对而言比较简单。而B端产品往往伴随着复杂的业务逻辑和产品知识，我曾经做过一款银行财资管理系统的设计，属于银行对公业务，目标用户是大中型企业的财务人员。一开始接受到业务知识时，很多闻所未闻，又生涩难懂的财务名词扑面而来，别说熟知业务知识，就是光消化这些远离实际生活的财务名词就得一些时间。

遇到脾气好，分析讲解能力强，且懂业务的产品经理和需求，他们往往会耐心地给你讲解业务知识，梳理业务逻辑。

但现实生活中，这样的产品经理在数量上并不占据优势。而且，产品经理的工作重点并不需要放在具体业务上，他们有更重要的问题需要解决。

所以问题来了：对于产品设计师，遇到不熟悉的业务，如何短时间内解决问题，完成设计工作？

首先我们来熟悉两个名词：1.通用模型  2.业务模型

通用模型，是一种可以用来解决工作中绝大多数问题的模型。

设计领域的通用模型包括1.SWOT模型，2.Google Design Sprint设计方法，3.GUCDR模型，4.双钻模型 5.卡诺模型 6.METUX模型。

因为这里主要是讨论业务模型，所以通用模型不在此做详细阐述，感兴趣的朋友可以多了解一下。

业务模型

定义：是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系。

目的：对业务进行建模，包括对业务流程进行建模和业务组织进行建模。

日常工作中，我们运用最多的就是对业务流程进行建模。

前不久我做了一个OA考勤系统，需要做一个考勤日历界面。产品经理给我的就是一句话，“需要做一个考勤日历界面，来记录用户每月打卡，以及迟到等异常”。

就这么一句话，需要构建出一个界面，相信很多人都会一筹莫展。但是作为一名产品设计师，怎么能被这些困难打倒呢？

打卡流程可以划分为：来到公司——用工卡在打卡器上打卡——上楼——打开电脑——查看今日考勤。最后一步是界面需要呈现出来的信息---查看考勤，在界面中我们需要给用户传达哪些有用信息？

首先来拆解考勤日历这个名词：考勤+日历。我们先把目光放在「日历」上，如果没有做过类似日历的项目，没有积累日历业务模型，面对这个需求会很陌生。

之前做过一个日程项目，以月为单位展示的日程界面其实和产品经理需要的记录每月用户考勤日历大同小异。如下图所示：

有了这个日历模型之后，考勤日历的基本框架便出来了：

基本框架出来了，也就成功了一半。剩下的工作就是把往框架里添砖加瓦--填充内容。如何填充内容，在这里我们还得引用「4W场景分析法」：

Who:什么人  When：什么时间   Where：什么地方  What：做什么事

如下图所示

从上图中我们可以提取到能表现在界面上的信息：

1.公司规定的签到时间  

2.公司规定的签退时间  

3.员工签到时间  

4.员工签退时间

这个时候我们就需要把提取到的信息 交叉在一起：

1.如果签到时间超过公司规定签到的时间，那么会产生什么后果？

2.如果在公司规定的签到时间签到，那么会产生什么后果？

3.如果签退时间早于公司规定的签退时间，那么会有什么后果？

4.如果签退时间晚于公司规定的签退时间，那么会有什么后果？

5.如果有签退，却没有签退会有什么后果？

6.如果有签到，却没有签退会有什么后果呢？

7.如果既没有签到也没有签退呢？

8.还有哪些特殊情况没有考虑进行呢？

9.我们设计考勤日历的目标是什么？

10.需要强调的重点是什么？

11.还有哪些机会点可以进行完善？

带着这些问题，我们就可以和产品经理进行沟通了，带着问题进行有效沟通交流，就可以避免漫无目的地交流。同时也会显得我们很专业，也就不会被产品经理和业务诟病设计出来的东西脱离实际了。同时也可以帮助产品经理厘清业务，在他们的心目中，即使你不是最专业的，也会是一个较为合格的设计师了。

从产品经理那里得到答案之后，我们就需要对信息进行整合分类，然后填充进上图的日历模型：

考勤日历只是其中的一个小小的案例。在实际工作中，几乎每一个B端产品都会涉及到审核，其实审核的要素都差不多的，无外乎：提起审核，进入审核环节，撤回审核，通过审核，拒绝审核，审核步骤，审核人，审核时间，审核人等等。当做第一个审核业务时，我们积累下审核这个业务模型，那么在接下来的工作中，无论遇到什么样的审核，我们心目中都已经有了审核的业务模型，只需要针对具体业务进行优化。

当然也有很多人说，你这么做是不是抢了产品经理的活儿？在我看来，产品经理更应该关注商业上的问题以及产品的走向，定位等大方向。只有大方向抓好了，设计师在大方向的指导下才设计出体验更好的产品。他们可以检验设计师产出的成果，但不一定非要非要参入到产品的设计细节中，

所以，在B端设计和工具类产品设计中，设计师一定要注意积累业务模型，对完成的设计工作要实时进行总结，积累更多的业务模型和通用模型。面对不熟悉和需求不明确的设计时，我们可以套用这些通用模型和业务模型，迅速地熟悉业务，分析问题，进而解决问题。