设计方案到处碰壁？资深高手深度分析设计师的边界 ！
从刚入门的案分析满怀信心，到设计方案的到处四处碰壁 ，可能不是碰壁团队有问题 ，或者你可以试试思考一下设计师的资深边界 。
边界感的高手话题要从试用期的述职 PPT 说起，有个价值观和专业的边界联系延伸，在中期用了"边界外延" ，设计深度设计师转正用了"底线策略" 。案分析近日又有些感触 ，到处索性一起拿来写了一篇文章。碰壁
一 、高手模糊专业边界
作为一个设计师 ，边界并不是设计深度设计师独立存在的，是要与产品 、研发、测试等紧密配合的 。在设计这个节点 ，为了使业务目标能从上到下的贯彻 ，需要设计师在专业上有更多的横向思考。
1. 思考产品
不得不说 ，一个整齐 、清晰的界面是设计师最大的"门面"，往往在设计阶段的后期 ，我们会花一部分时间去思考如何让界面更精致 ，更吸引用户 。但是在整个设计过程中，界面的表达不会是最主要的部分 ，重要的是如何去兜住业务 ，提升体验 ，所以在设计之初 ，我们的主要精力还要前置到产品经理的角色 ，去思考业务场景是什么？需要打通什么流程，解决用户的什么问题 ，解决之后能不能带来业务上的提升 ，这样的思考可以让设计方案一直遵循需求发起的初心。如果不去考虑产品所处的场景 ，利用惯性思维处置需求 ，难免会出现盲人摸象的状况 。
2. 思考实现
能满足业务和用户目标的方案就一定是最好的嘛 ？市面上不乏很亮眼的页面和让人惊喜的交互方式 ，但是如果该方案放到当下的业务场景下不一定是最适合的 。
作者认为，单纯从设计表达的角度去评估一个方案是否优良是有失偏颇的 。如果一个完全不一样的方案 ，同样可以满足用户和业务目标 ，并且能够实现 ，那么它应该比酷炫但难以实现的方案更有价值。所以在真实的项目环境中 ，除了满足目标之外 ，还要符合当前的实现成本（时间、技术和水平） 。
所以 ，我们在设计方案成型或者有了想法后 ，及时找产品团队和研发团队碰碰想法 ，这样的话 ，正式评审时 ，可以大概率的增加方案的通过率 ，更主要的是 ，能快速定位设计方向。从某种程度上来讲 ，团队的研发和产品也是设计师的"用户" 。其实这也是最开始图中提到的"范围内做创新" ，在已有的技术范围内设计 。
在最近的项目中进行了设计规范的搭建 ，搭建之初便定下了三条设计原则 ：要做 、可做 、能做 。
要做 ：确实有存在业务问题或者用户有反馈，才会被纳入到改造中 ，否则就用通用规范即可 。
可做 ：对所存在的问题进行预研 ，思考业务场景 、竞品现状，看是否合理。必要时要与产品共同决策。
能做 ：平衡设计方案与当前的实现成本 ，规范的改造设计一定是与相关研发负责人提前沟通过 ，确实可做 ，有技术方案，而不是设计师一拍脑袋 ，让研发去实现 。必要时，设计师应该主动发起规范评审 。把自己放到项目中，设计的价值就是能在规定的成本范围内 ，为客户提供满意的方案 。
不过在真实的项目中 ，也会遇到一些不好处理的事情 。团队内部已经对问题达成了共识 ，方案也有了 ，但是卡在了研发侧。比如这个方案很常见 ，竞品已经普遍实现了，但是研发就说不好做 ，或者没有工期 。这个时候应该怎么办 。如果经过自己的分析确实没有更好的方案 ，拉产品做"盟友" ，说服他（hhh） ，或者做两个方案让他们选择，并且阐述当前方案的业务价值以及与竞品的优势 ，让产品在评审的时候与研发沟通 ，让他们先评估排期或者着手去调研 。
3. 思考协同
交互不止是出出原型，搞一下流程 ，具体的页面尺寸或者展示数量等细节，与业务相关性比较大的样式也需要做一定的思考和定义 。因为和 UI 相比 ，交互往往是与业务更接近的 ，交互说明中要给 UI 相应的设计方向 ，减少业务目标的偏移 。
比如 ：表格展示中 ，如果出现了可以拖动列宽的功能，交互要知道不同字段的最小列宽如何根据业务场景差异化定义 、归类 ，将这个方向传达给下游设计师 ，或者直接定义好 。免得信息不同步 ，导致实现后效果不理想 。
虽然在说模糊专业边界 ，但其实是为了更好的触及到未知的问题 ，希望设计师能了解非专业范围的事情 ，给设计方案带来更多的确定性。
二、明确岗位边界
1. 需求范围
从用户体验五要素的层级来看，设计介入的范围是结构层 、框架层和表现层 。所以战略层和范围层的事情 ，前期的了解是为了能够更好的贯彻业务目标 ，绝对不是到了结构层和框架层 ，设计师再去加个功能，减个流程 。
想起来刚毕业做的很多虚拟项目，用双钻模型流程走的很全 ，从市场调研 、用户分析 ，得到机会点 ，然后确定需要解决什么问题 ，做什么流程和功能，最后设计表现 。因为是虚拟的项目 ，所以什么对目标实现有帮助 ，就会用什么方式 。
但是在真实的项目中 ，往往不会允许设计师去发散功能 。比如在一个社区页面 ，产品说把这个页面设计的好看点，现在太丑了，用户使用率很低 。经过设计师的分析 ，这个页面只有用户的基本信息 ，画面很单调 ，而且用户粘性不高 。于是设计师就加了一个积分的功能，通过登录次数和浏览次数 ，可以获得积分 ，然后兑换奖品 。但是这个功能并没有出现在本次的产品需求清单中，即使有规划 ，也不是现在就要去实现 ，会牵扯到前后端很多的开发细节 。毋庸置疑 ，方案被毙，需要重新搞 。
如果没有按照规定的需求做设计方案 ，是要承担延期风险的，代价就是自己加班补 ，然后被认为不专业（我曾经也这么干过） 。最明智的选择就是按照产品的需求说明搞 ，如果没有详细的说明 ，一定要确定好范围 ，做好记录 ，随时沟通。
2. 合理的推动边界
通过需求清单确定设计的范围没有问题 ，但是有的时候可能在思考业务流程的时候 ，难免会发现一些产品没有考虑到的环节或者有更好的处理方式 。
在一次批量创建任务的流程中 ，流程是打开对话框 ，先选择任务模版 ，根据任务模版创建任务 ，如果没有模版 ，用户仍然可以点击创建按钮-创建任务，遵循的是系统的自有规则 。有些用户没有模版 ，看到空选项和页面难免有疑惑 ，如果用户有模版 ，展示的是空页面也有点奇怪 。因此在页面设计的过程中 ，就与产品和研发沟通 ，系统的自带规则是否可以设置为系统模版 ，
- 用户没有模版 ，进入页面后 ，默认使用系统模版；
- 用户有一个自己的模版 ，则默认用户自己的模版；
- 用户有多个模版，则默认系统模版 ，用户可以修改；
- 在下拉框的底部给一个创建模版的快捷按钮 ，支持用户在这个页面跳转到设置页创建新的模版 。
虽然这与需求是有出入的 ，需要后端处理数据 ，但是确实为用户带来了更大的便利，团队觉得是值得做的 ，因此这个方案最后通过了 。
如果设计师洞察出了新的问题 ，但是团队觉得没有价值 ，自己又想推动实施 。这个时候可以先去了解用户 ，确定设计方案的问题场景是否真实存在 ，如果不是，那么就要乖乖回去改方案咯；如果是 ，那就好办了 ，收集用户的意见去和团队的成员讲 ，或者让用户自己去提反馈 。在一些 B 端的场景 ，用户的满意度往往卡着项目的喉咙（绩效）。另外需要提醒的一点是 ，如果问题最终没有与团队达成共识 ，就不要操之过急 ，因为无论方案做的多优秀 ，没有共识的价值是不会被承认的 。
所以 ，推动岗位边界 ，不仅需要一定的业务和专业积累 ，也需要失败的勇气 。
三、守住设计边界
这个边界是前面图片中出现的"底线策略" ，如果分个类的话 ，上面两个说的都是横向边界 ，而设计的边界是纵向 ，这个设计边界我是从两个场景思考的
1. 长期跟进的业务
在自己长期支撑的平台 ，需要保证的是不同时间 、不同页面的相似场景下的产出具有一定的一致性 ，这应该是我们每次做设计方案的目标之一吧 ，是个很常见的意识 ，主要是为了降低研发成本和用户的学习成本 。有很多的大公司为了平台的可持续发展考虑 ，做了自己的设计规范 ，能很好的指导设计师做到全场景的一致性 。
如果目前没有现成的设计规范 ，设计师心里应该要有"一把尺" ，自己的产物 ：最基本的页面架构 、基础组件、交互方式和常规流程保持一致性 。当然并不可能一开始就能考虑全面 ，对于快速迭代的初期平台 ，虽然允许设计师有更大的创新空间，但是对于通用业务场景还是要找一个能遵循的标准 ，比如第三方的组件库 ，element 、ant ，直接拿开源的组件 ，搭建产品的初期形态 ，对于业务性较强的场景，可以根据实际需要 ，做一些创新性的表达方式 。一边做，一边沉淀，等到稳定的迭代时机 ，实现整体的设计资源回落 。
对于一些要持续优化的组件 ，比如一开始做的时候没有考虑兼容性，出现了新的业务场景 ，需要做调整 ，这个时候一定要做好记录 ，与团队做好共识同步 ，是要特殊场景特殊处理 ，还是要统一更新 ，做好计划节点 ，切莫到处挖坑，不然最后填坑的还是设计师 。
2. 临时支撑的业务
另外一个场景是临时被抽掉到其他的业务线做设计支撑，这个时候除了要快速融入到团队中 ，另一个要做的是如何让自己的产物融入到这个平台的设计体系 。一开始，我做的事情就是上来先挑这个平台的体验问题和架构漏洞 ，一脸鄙夷的问这问那 ，但是后来却发现 ，这并不利于工作的开展 。讲实话 ，人家是让你来支撑的 ，是为了帮助项目顺利推进 ，而不是让你指导工作 。
那应该怎么做 ，后来这类的任务做多了 ，我就总结了自己的工作方法 ：首先要熟悉这个平台的业务逻辑 ，该理的流程梳理清楚；然后根据业务流程走查平台页面 ，熟悉平台的页面架构、基础组件 、交互方式和常规流程等，在已有的形态下 ，形成当前框架的设计总结，即使是漏洞百出的设计也会有自己的特点 ，掌握好"规律"不仅是为了能遵循一致 ，还能更好的做系统性优化 。同时记录我们比较关切的问题 ，并将自己的记录与团队同步 ，询问具体的实现场景以及是否要改进 ，如果不需要 ，遵循一致即可，往往用户习惯是不好改变的 。如果可以趁机优化，前期的设计走查总结就派上了用场 。
以上便是我对设计师成长过程中边界问题的思考，并不是所有的业务都是想象的那么完美 ，总会有一部分需要我们通过设计手段做不一样的诠释 ，也并不是所有的业务都是那么糟糕，总会有意外让设计发挥更大的价值 。总之 ，练好设计的闭环基本功 ，才是成长的关键 。后续也会对设计闭环能力进行总结阐述 ，希望一起在设计的路上越走越远。
作者：聿来体验笔记
从刚入门的案分析满怀信心，到设计方案的到处四处碰壁 ，可能不是碰壁团队有问题 ，或者你可以试试思考一下设计师的资深边界 。
边界感的高手话题要从试用期的述职 PPT 说起，有个价值观和专业的边界联系延伸，在中期用了"边界外延" ，设计深度设计师转正用了"底线策略" 。案分析近日又有些感触 ，到处索性一起拿来写了一篇文章。碰壁
一 、高手模糊专业边界
作为一个设计师 ，边界并不是设计深度设计师独立存在的，是要与产品 、研发、测试等紧密配合的 。在设计这个节点 ，为了使业务目标能从上到下的贯彻 ，需要设计师在专业上有更多的横向思考。
1. 思考产品
不得不说 ，一个整齐 、清晰的界面是设计师最大的"门面"，往往在设计阶段的后期 ，我们会花一部分时间去思考如何让界面更精致 ，更吸引用户 。但是在整个设计过程中，界面的表达不会是最主要的部分 ，重要的是如何去兜住业务 ，提升体验 ，所以在设计之初 ，我们的主要精力还要前置到产品经理的角色 ，去思考业务场景是什么？需要打通什么流程，解决用户的什么问题 ，解决之后能不能带来业务上的提升 ，这样的思考可以让设计方案一直遵循需求发起的初心。如果不去考虑产品所处的场景 ，利用惯性思维处置需求 ，难免会出现盲人摸象的状况 。
2. 思考实现
能满足业务和用户目标的方案就一定是最好的嘛 ？市面上不乏很亮眼的页面和让人惊喜的交互方式 ，但是如果该方案放到当下的业务场景下不一定是最适合的 。
作者认为，单纯从设计表达的角度去评估一个方案是否优良是有失偏颇的 。如果一个完全不一样的方案 ，同样可以满足用户和业务目标 ，并且能够实现 ，那么它应该比酷炫但难以实现的方案更有价值。所以在真实的项目环境中 ，除了满足目标之外 ，还要符合当前的实现成本（时间、技术和水平） 。
所以 ，我们在设计方案成型或者有了想法后 ，及时找产品团队和研发团队碰碰想法 ，这样的话 ，正式评审时 ，可以大概率的增加方案的通过率 ，更主要的是 ，能快速定位设计方向。从某种程度上来讲 ，团队的研发和产品也是设计师的"用户" 。其实这也是最开始图中提到的"范围内做创新" ，在已有的技术范围内设计 。
在最近的项目中进行了设计规范的搭建 ，搭建之初便定下了三条设计原则 ：要做 、可做 、能做 。
要做 ：确实有存在业务问题或者用户有反馈，才会被纳入到改造中 ，否则就用通用规范即可 。
可做 ：对所存在的问题进行预研 ，思考业务场景 、竞品现状，看是否合理。必要时要与产品共同决策。
能做 ：平衡设计方案与当前的实现成本 ，规范的改造设计一定是与相关研发负责人提前沟通过 ，确实可做 ，有技术方案，而不是设计师一拍脑袋 ，让研发去实现 。必要时，设计师应该主动发起规范评审 。把自己放到项目中，设计的价值就是能在规定的成本范围内 ，为客户提供满意的方案 。
不过在真实的项目中 ，也会遇到一些不好处理的事情 。团队内部已经对问题达成了共识 ，方案也有了 ，但是卡在了研发侧。比如这个方案很常见 ，竞品已经普遍实现了，但是研发就说不好做 ，或者没有工期 。这个时候应该怎么办 。如果经过自己的分析确实没有更好的方案 ，拉产品做"盟友" ，说服他（hhh） ，或者做两个方案让他们选择，并且阐述当前方案的业务价值以及与竞品的优势 ，让产品在评审的时候与研发沟通 ，让他们先评估排期或者着手去调研 。
3. 思考协同
交互不止是出出原型，搞一下流程 ，具体的页面尺寸或者展示数量等细节，与业务相关性比较大的样式也需要做一定的思考和定义 。因为和 UI 相比 ，交互往往是与业务更接近的 ，交互说明中要给 UI 相应的设计方向 ，减少业务目标的偏移 。
比如 ：表格展示中 ，如果出现了可以拖动列宽的功能，交互要知道不同字段的最小列宽如何根据业务场景差异化定义 、归类 ，将这个方向传达给下游设计师 ，或者直接定义好 。免得信息不同步 ，导致实现后效果不理想 。
虽然在说模糊专业边界 ，但其实是为了更好的触及到未知的问题 ，希望设计师能了解非专业范围的事情 ，给设计方案带来更多的确定性。
二、明确岗位边界
1. 需求范围
从用户体验五要素的层级来看，设计介入的范围是结构层 、框架层和表现层 。所以战略层和范围层的事情 ，前期的了解是为了能够更好的贯彻业务目标 ，绝对不是到了结构层和框架层 ，设计师再去加个功能，减个流程 。
想起来刚毕业做的很多虚拟项目，用双钻模型流程走的很全 ，从市场调研 、用户分析 ，得到机会点 ，然后确定需要解决什么问题 ，做什么流程和功能，最后设计表现 。因为是虚拟的项目 ，所以什么对目标实现有帮助 ，就会用什么方式 。
但是在真实的项目中 ，往往不会允许设计师去发散功能 。比如在一个社区页面 ，产品说把这个页面设计的好看点，现在太丑了，用户使用率很低 。经过设计师的分析 ，这个页面只有用户的基本信息 ，画面很单调 ，而且用户粘性不高 。于是设计师就加了一个积分的功能，通过登录次数和浏览次数 ，可以获得积分 ，然后兑换奖品 。但是这个功能并没有出现在本次的产品需求清单中，即使有规划 ，也不是现在就要去实现 ，会牵扯到前后端很多的开发细节 。毋庸置疑 ，方案被毙，需要重新搞 。
如果没有按照规定的需求做设计方案 ，是要承担延期风险的，代价就是自己加班补 ，然后被认为不专业（我曾经也这么干过） 。最明智的选择就是按照产品的需求说明搞 ，如果没有详细的说明 ，一定要确定好范围 ，做好记录 ，随时沟通。
2. 合理的推动边界
通过需求清单确定设计的范围没有问题 ，但是有的时候可能在思考业务流程的时候 ，难免会发现一些产品没有考虑到的环节或者有更好的处理方式 。
在一次批量创建任务的流程中 ，流程是打开对话框 ，先选择任务模版 ，根据任务模版创建任务 ，如果没有模版 ，用户仍然可以点击创建按钮-创建任务，遵循的是系统的自有规则 。有些用户没有模版 ，看到空选项和页面难免有疑惑 ，如果用户有模版 ，展示的是空页面也有点奇怪 。因此在页面设计的过程中 ，就与产品和研发沟通 ，系统的自带规则是否可以设置为系统模版 ，
- 用户没有模版 ，进入页面后 ，默认使用系统模版；
- 用户有一个自己的模版 ，则默认用户自己的模版；
- 用户有多个模版，则默认系统模版 ，用户可以修改；
- 在下拉框的底部给一个创建模版的快捷按钮 ，支持用户在这个页面跳转到设置页创建新的模版 。
虽然这与需求是有出入的 ，需要后端处理数据 ，但是确实为用户带来了更大的便利，团队觉得是值得做的 ，因此这个方案最后通过了 。
如果设计师洞察出了新的问题 ，但是团队觉得没有价值 ，自己又想推动实施 。这个时候可以先去了解用户 ，确定设计方案的问题场景是否真实存在 ，如果不是，那么就要乖乖回去改方案咯；如果是 ，那就好办了 ，收集用户的意见去和团队的成员讲 ，或者让用户自己去提反馈 。在一些 B 端的场景 ，用户的满意度往往卡着项目的喉咙（绩效）。另外需要提醒的一点是 ，如果问题最终没有与团队达成共识 ，就不要操之过急 ，因为无论方案做的多优秀 ，没有共识的价值是不会被承认的 。
所以 ，推动岗位边界 ，不仅需要一定的业务和专业积累 ，也需要失败的勇气 。
三、守住设计边界
这个边界是前面图片中出现的"底线策略" ，如果分个类的话 ，上面两个说的都是横向边界 ，而设计的边界是纵向 ，这个设计边界我是从两个场景思考的
1. 长期跟进的业务
在自己长期支撑的平台 ，需要保证的是不同时间 、不同页面的相似场景下的产出具有一定的一致性 ，这应该是我们每次做设计方案的目标之一吧 ，是个很常见的意识 ，主要是为了降低研发成本和用户的学习成本 。有很多的大公司为了平台的可持续发展考虑 ，做了自己的设计规范 ，能很好的指导设计师做到全场景的一致性 。
如果目前没有现成的设计规范 ，设计师心里应该要有"一把尺" ，自己的产物 ：最基本的页面架构 、基础组件、交互方式和常规流程保持一致性 。当然并不可能一开始就能考虑全面 ，对于快速迭代的初期平台 ，虽然允许设计师有更大的创新空间，但是对于通用业务场景还是要找一个能遵循的标准 ，比如第三方的组件库 ，element 、ant ，直接拿开源的组件 ，搭建产品的初期形态 ，对于业务性较强的场景，可以根据实际需要 ，做一些创新性的表达方式 。一边做，一边沉淀，等到稳定的迭代时机 ，实现整体的设计资源回落 。
对于一些要持续优化的组件 ，比如一开始做的时候没有考虑兼容性，出现了新的业务场景 ，需要做调整 ，这个时候一定要做好记录 ，与团队做好共识同步 ，是要特殊场景特殊处理 ，还是要统一更新 ，做好计划节点 ，切莫到处挖坑，不然最后填坑的还是设计师 。
2. 临时支撑的业务
另外一个场景是临时被抽掉到其他的业务线做设计支撑，这个时候除了要快速融入到团队中 ，另一个要做的是如何让自己的产物融入到这个平台的设计体系 。一开始，我做的事情就是上来先挑这个平台的体验问题和架构漏洞 ，一脸鄙夷的问这问那 ，但是后来却发现 ，这并不利于工作的开展 。讲实话 ，人家是让你来支撑的 ，是为了帮助项目顺利推进 ，而不是让你指导工作 。
那应该怎么做 ，后来这类的任务做多了 ，我就总结了自己的工作方法 ：首先要熟悉这个平台的业务逻辑 ，该理的流程梳理清楚；然后根据业务流程走查平台页面 ，熟悉平台的页面架构、基础组件 、交互方式和常规流程等，在已有的形态下 ，形成当前框架的设计总结，即使是漏洞百出的设计也会有自己的特点 ，掌握好"规律"不仅是为了能遵循一致 ，还能更好的做系统性优化 。同时记录我们比较关切的问题 ，并将自己的记录与团队同步 ，询问具体的实现场景以及是否要改进 ，如果不需要 ，遵循一致即可，往往用户习惯是不好改变的 。如果可以趁机优化，前期的设计走查总结就派上了用场 。
以上便是我对设计师成长过程中边界问题的思考，并不是所有的业务都是想象的那么完美 ，总会有一部分需要我们通过设计手段做不一样的诠释 ，也并不是所有的业务都是那么糟糕，总会有意外让设计发挥更大的价值 。总之 ，练好设计的闭环基本功 ，才是成长的关键 。后续也会对设计闭环能力进行总结阐述 ，希望一起在设计的路上越走越远。
作者：聿来体验笔记
