设计方案到处碰壁？资深高手深度分析设计师的边界！

从刚入门的满怀信心，到设计方案的四处碰壁，可能不是团队有问题，或者你可以试试思考一下设计师的边界。

边界感的话题要从试用期的述职 PPT 说起，有个价值观和专业的联系延伸，在中期用了“边界外延”，转正用了“底线策略”。近日又有些感触，索性一起拿来写了一篇文章。

一、模糊专业边界

作为一个设计师，并不是独立存在的，是要与产品、研发、测试等紧密配合的。在设计这个节点，为了使业务目标能从上到下的贯彻，需要设计师在专业上更多的横向思考。

1. 思考产品

不得不说，一个整齐、清晰的界面是设计师最大的“门面”，往往在设计阶段的后期，我们会花一部分时间去思考如何让界面更精致，更吸引用户。但是在整个设计过程中，界面的表达不会是最主要的部分，重要的是如何去兜住业务，提升体验，所以在设计之初，我们的主要精力还要前置到产品经理的角色，去思考业务场景是什么？需要打通什么流程，解决用户的什么问题，解决之后能不能带来业务上的提升，这样的思考可以让设计方案一直遵循需求发起的初心。如果不去考虑产品所处的场景，利用惯性思维处置需求，难免会出现盲人摸象的状况。

2. 思考实现

能满足业务和用户目标的方案就一定是最好的嘛？市面上不乏很亮眼的页面和让人惊喜的交互方式，但是如果该方案放到当下的业务场景下不一定是最适合的。

作者认为，单纯从设计表达的角度去评估一个方案是否优良是有失偏颇的。如果一个完全不一样的方案，同样可以满足用户和业务目标，并且能够实现，那么它应该比酷炫但难以实现的方案更有价值。所以在真实的项目环境中，除了满足目标之外，还要符合当前的实现成本（时间、技术和水平）。

所以，我们在设计方案成型或者有了想法后，及时找产品团队和研发团队碰碰想法，这样的话，正式评审时，可以大概率的增加方案的通过率，更主要的是，能快速定位设计方向。从某种程度上来讲，团队的研发和产品也是设计师的“用户”。其实这也是最开始图中提到的“范围内做创新”，在已有的技术范围内设计。

在最近的项目中进行了设计规范的搭建，搭建之初便定下了三条设计原则：要做、可做、能做。

要做：确实有存在业务问题或者用户有反馈，才会被纳入到改造中，否则就用通用规范即可。

可做：对所存在的问题进行预研，思考业务场景、竞品现状，看是否合理。必要时要与产品共同决策。

能做：平衡设计方案与当前的实现成本，规范的改造设计一定是与相关研发负责人提前沟通过，确实可做，有技术方案，而不是设计师一拍脑袋，让研发去实现。必要时，设计师应该主动发起规范评审。把自己放到项目中，设计的价值就是能在规定的成本范围内，为客户提供满意的方案。

不过在真实的项目中，也会遇到一些不好处理的事情。团队内部已经对问题达成了共识，方案也有了，但是卡在了研发侧。比如这个方案很常见，竞品已经普遍实现了，但是研发就说不好做，或者没有工期。这个时候应该怎么办。如果经过自己的分析确实没有更好的方案，拉产品做"盟友"，说服他（hhh），或者做两个方案让他们选择，并且阐述当前方案的业务价值以及与竞品的优势，让产品在评审的时候与研发沟通，让他们先评估排期或者着手去调研。

二、明确岗位边界

1. 需求范围

从用户体验五要素的层级来看，设计介入的范围是结构层、框架层和表现层。所以战略层和范围层的事情，前期的了解是为了能够更好的贯彻业务目标，绝对不是到了结构层和框架层，设计师再去加个功能，减个流程。

想起来刚毕业做的很多虚拟项目，用双钻模型流程走的很全，从市场调研、用户分析，得到机会点，然后确定需要解决什么问题，做什么流程和功能，最后设计表现。因为是虚拟的项目，所以什么对目标实现有帮助，就会用什么方式。

但是在真实的项目中，往往不会允许设计师去发散功能。比如在一个社区页面，产品说把这个页面设计的好看点，现在太丑了，用户使用率很低。经过设计师的分析，这个页面只有用户的基本信息，画面很单调，而且用户粘性不高。于是设计师就加了一个积分的功能，通过登录次数和浏览次数，可以获得积分，然后兑换奖品。但是这个功能并没有出现在本次的产品需求清单中，即使有规划，也不是现在就要去实现，会牵扯到前后端很多的开发细节。毋庸置疑，方案被毙，需要重新搞。

如果没有按照规定的需求做设计方案，是要承担延期风险的，代价就是自己加班补，然后被认为不专业（我曾经也这么干过）。最明智的选择就是按照产品的需求说明搞，如果没有详细的说明，一定要确定好范围，做好记录，随时沟通。

2. 合理的推动边界

通过需求清单确定设计的范围没有问题，但是有的时候可能在思考业务流程的时候，难免会发现一些产品没有考虑到的环节或者有更好的处理方式。

在一次批量创建任务的流程中，流程是打开对话框，先选择任务模版，根据任务模版创建任务，如果没有模版，用户仍然可以点击创建按钮-创建任务，遵循的是系统的自有规则。有些用户没有模版，看到空选项和页面难免有疑惑，如果用户有模版，展示的是空页面也有点奇怪。因此在页面设计的过程中，就与产品和研发沟通，系统的自带规则是否可以设置为系统模版，

• 用户没有模版，进入页面后，默认使用系统模版；
• 用户有一个自己的模版，则默认用户自己的模版；
• 用户有多个模版，则默认系统模版，用户可以修改；
• 在下拉框的底部给一个创建模版的快捷按钮，支持用户在这个页面跳转到设置页创建新的模版。
  

虽然这与需求是有出入的，需要后端处理数据，但是确实为用户带来了更大的便利，团队觉得是值得做的，因此这个方案最后通过了。

三、守住设计边界

这个边界是前面图片中出现的“底线策略”，如果分个类的话，上面两个说的都是横向边界，而设计的边界是纵向，这个设计边界我是从两个场景思考的

1. 长期跟进的业务

在自己长期支撑的平台，需要保证的是不同时间、不同页面的相似场景下的产出具有一定的一致性，这应该是我们每次做设计方案的目标之一吧，是个很常见的意识，主要是为了降低研发成本和用户的学习成本。有很多的大公司为了平台的可持续发展考虑，做了自己的设计规范，能很好的指导设计师做到全场景的一致性。

如果目前没有现成的设计规范，设计师心里应该要有“一把尺”，自己的产物：最基本的页面架构、基础组件、交互方式和常规流程保持一致性。当然并不可能一开始就能考虑全面，对于快速迭代的初期平台，虽然允许设计师有更大的创新空间，但是对于通用业务场景还是要找一个能遵循的标准，比如第三方的组件库，element、ant，直接拿开源的组件，搭建产品的初期形态，对于业务性较强的场景，可以根据实际需要，做一些创新性的表达方式。一边做，一边沉淀，等到稳定的迭代时机，实现整体的设计资源回落。

对于一些要持续优化的组件，比如一开始做的时候没有考虑兼容性，出现了新的业务场景，需要做调整，这个时候一定要做好记录，与团队做好共识同步，是要特殊场景特殊处理，还是要统一更新，做好计划节点，切莫到处挖坑，不然最后填坑的还是设计师。