My Secret Rainbow

#15 设计约束中的「五面墙」

篇首语

在创意和设计领域中，很多人都曾遇到过一个问题。那就是面对一个空白界面时，心中有诸多的灵感和想法但却不知从何开始。前段时间正好读到一篇文章，了解到这种现象它其实有一个专有名词，叫做「空白页综合症」。

Photoshop 从空白画布新建

空白页综合症其实并不是一个医学术语，它通常会被用来形容在面对空白纸张或屏幕界面时所产生的压迫和创作障碍的现象。有意思的是，与毫无“约束”的空白页面相对应，日常的工作中我们却又不得不面对着诸多对设计上的约束。

自由 or 约束，在设计中是一个很矛盾的问题。它不仅仅影响着设计师的具体工作，还关乎着设计师的职业信仰。最近借着这个话题忽然想明白了之前在团队工作中的一些事情，所以正好乘着思路还在写了这篇文章。与大家一起聊聊设计师在日常工作中所面临的那些约束问题，看看我们应该如何去与其共处。

 

约束的变化

随着互联网和设计行业的不断进化，设计工具也在不断地发生变化。我们逐渐发现，很多的工具开始从「创建一个空白界面」向「从模板创建」进行引导转变。比如我们前段时间和大家分析过的 UIZard，除了 AI 设计，它最重要的引导就是让用户通过模板开始创建设计。

UIZard 从模板新建

这种快速启动设计的方式的确有不少的好处，设计师再无需面对空白界面发呆个几分钟甚至几小时。基于模板开始快速进入工作，在现有的基础上进行定制或调整，设计师不必再对着空白页面从头开始。

究其根本，这些模板其实就是一系列设计规范的具象化、实例化，以此来约束设计方案的基础体验、一致性，以及提升设计的效率。

当然，在各类设计工具平台中这些模板都充其量只能算做建议，而只有在业务真实环境中应用的各类模板及组件、模式，我们才能将其定义为真正的设计约束，比如我们曾经介绍过的 CloudScape Design System 中的各类组件、Pattern、模板。

CloudSpace Design System

不过，如果我们日常工作的约束仅仅就是这些，那就太简单了。实际上，在真实的场景中设计上的约束仅仅只是我们所需要面对的一小部分，海油更多的约束其实是来源于设计之外，而这些也正是让设计师们最为头疼的地方。

在这里，我想还是先和大家说一个给很多人讲过的案例。

 

理想与现实的差异

阿里工作的这些年，我时常会与很多不同团队的设计师聊聊天，开导一下大家在工作中所遇到的苦恼。在这个过程中有不少的同学会有提到一个点，那就是真实的工作环境与他们所想象的环境之间的差异。

这些同学大多都有着很好的专业背景，在国内外一流的环境中完成学业，再满怀憧憬的进入到阿里的各个设计团队。但事实上真实的业务场却让他们感受到了另一番截然不同的情景，设计需要为业务目标服务，设计因为产品和技术的原因收到诸多的限制，必要的时候设计可能还会背个锅 ……

这些都与他们所想象中的“大厂”设计团队不太一样，很多人会为之苦恼。为什么我怀揣着想要设计出触动人心的产品的梦想来到这里，最后却陷入在无休止的会议中、争论中，最终做了一堆自己都不愿意放入作品集的设计方案？

设计不是艺术，艺术追求表达自我，而设计追求的是解决问题。现实的环境中，对于公司而言它需要的是能够解决问题的人，而不是来表达自我情感、思想的“艺术家”。

真正能想通这一点的人，是有可能在所谓的大厂中寻求更多更好的发展机会。而始终过不了自己这关的人，大家会的开始慢慢厌恶这个环境，最终毅然选择离开。

面对真我，选择离开并不容易，现实的环境不会因此而发生变化。对于绝大部分需要继续坚持的设计师而言，面对设计中的约束并合理的应用好它们才是我们必须思考的。

 

在日常工作中所面临的五类设计约束

作为设计师，我们在日常工作中会面临哪些约束？以这些年的工作经验来看，我会将它归纳为业务需求、用户诉求、技术能力、设计质量以及团队合作五个方面。

虽然设计约束只是这里面的一项，但事实上其它几个都会直接的影响到我们以及设计最终的交付质量。所以作为设计师，我们依旧需要在日常工作中对它们保持同样足够的关注。

01. 业务需求约束

我们做的每一个设计方案都是为业务所服务的，设计师必须理解并满足业务方所提出的需求。它们可能会涉及到营收指标、品牌定位、目标市场等多方面因素。设计师需要在这些需求与体验之间寻找平衡点。

不幸的是，这些设计之前的背景信息并不是每次都能非常及时、明确地给到设计师，有些时候情况甚至会更糟。这就导致了设计过程中可能出现了非常不准确的信息，导致大量的修改、调整，耽误工期。有时候业务方还会频繁的变更需求，进一步增加了我们设计的复杂度。

02. 用户需求的约束

在商业环境中，作为产品最终的使用者，用户对产品的需求和喜好就显得尤为重要。设计师必须考虑用户对产品和体验的期望，以确保设计方案最终能够满足他们的需求，提供良好的使用体验，最终才能为公司创造更多的商业价值，从而体现出自己的价值。

可事实情况是，用户很多时候与我们预想的有非常大的差异。产品经理和设计师一边看着用户反馈吐槽，一边思考着该如何调整来满足用户的要求，这样的场景是不是似成相识？在集团 CFO 线的业务中，我们的设计师就曾一边无奈于财务领域用户的古板习惯，一边与用户进行访谈，以寻找更合适的解决方案。

几乎我们所有人都没有像乔布斯一样定义产品和教育用户的能力，所以我们只能接受用户的需求与喜好与我们的预期不符，尝试着一步步去摸索，不断的寻找更好的解决方案。

03. 技术能力的约束

在技术的可行性方面，设计师还需要对现有的能力和限制有足够地了解，以确保交付的设计方案能够在开发环节中顺利实现并有效还原出预期的效果。

但在现实的情况是，在真实的业务环节中有很多技术上的限制和曾经被埋下的“坑”可能连技术团队自己都不清楚。如果说设计师对产品工作还有机会能“掺”一脚，那么技术方面的问题对于绝大部分设计师都只能望而兴叹了。

04. 设计质量的约束

相较于前面提及到的部分，设计部分的约束是相对而言最为清晰和明确的了。作为设计师的本职工作，我们需要基于业务目标、用户诉求以及技术能力来创建富有吸引力的、易用的产品体验。

同时我们还需要基于对业务的理解来主动建立约束，通过对设计原则和最佳实践的抽象来形成丢后续设计工作的指引，帮助团队提升设计的一致性和设计的生产效率。

05. 团队合作的约束

最后，请不要忘记，在真实的项目中与我们合作的是一个个具体的团队成员。任何的工作中只要涉及到其他人就会存在变数，哪怕是在“大厂”，同样也会有不少不靠谱的人存在。

事实上，有很多本来靠谱的项目都会因为一两个不靠谱的人而最终效果打折扣甚至是失败。我们无法在每个项目中去决定挑选什么样的成员参与，但我们可以适当的通过一些措施的保障来避免问题的发生。

聊了这么多，是不是觉得作为一名设计师实在是太不容易了。但这就是真实的现状，如果还无法改变，那么我们就需要借助一些策略来帮助自己。作为设计师，我一向的原则就是在保障设计交付质量的前提下，尽可能的让“锅”不要出现在自己这里。

 

约束中的「五面墙」

试想一个场景，在一个三维空间中我们的周围有五面“墙”。如果想要从这里顺利的走出去，那么就需要上、下、左、右以及后方的墙足够坚固，否则可能还没等我们顺利的离开，这个空间就崩塌了。

设计约束中的「五面墙」

回到日常的项目设计中，这里提及到的五面“墙”就是我们在上面提到的五个约束，而前方的出口则是我们想要最终获得的设计方案。

如果这个空间中有四到五个面是牢固的，我们可以很放心、顺利的走出去；如果只有两面墙足够牢固，我们可能会踉踉跄跄、狼狈的跑出去，但过程和结果可能都不会太好；但如果这里的每一面墙都不牢…… 那我们很有可能就会垮在里面了。

在设计的世界里，我们提到的这些约束就像是围墙，将我们的创作空间和风险限制在一个特定的范围内，也支撑着我们能够顺利的走出去。每一面墙代表一个约束，我们必须在这些约束中寻找确定因数或问题，再基于此来构建解决方案。如果在这些约束中我们都能做好提问与回答，那么我们项目的成功的几率会得到明显的提高。

 

面对这五面“墙”我们能做些什么

所谓的“墙”或者说是约束，其实本质上就是一些底线以及必须明确的关键因素。所以在我们需要结合自己的业务和团队现状找到它们，并在每一次的项目中尽可能的寻求明确的答案。

01. 上方：业务需求约束

绝大部分时候，我们的的项目都是为商业目标所服务的，这也就是意味着我们有了一个比较坚实的基础。无论这个项目的数据指标是什么，它一定与之有着最为重要的关联。

之前在 Q&A 中和大家提及的目标公式拆解，其实就是这个逻辑：

举例：付费用户数（Z） = 方案选择页流量（X）* 购买转化率（Y）

这里有一点需要注意，很多时候我们项目并不直接为最终的目标服务。那我们就需要对其进行向上溯源，搞清楚当前这个项目最终是要服务于哪个目标，避免我们做着做着就跑偏了。

同时，我们还需要尽可能对业务逻辑有足够清晰的理解。以前在很多讨论中，大家会将「理解业务」当做设计师的一种横向技能，有则更好，也不影响做设计。但在我看来，其实在如今它是设计师的必要技能，它更重要的作用是能够形成设计的“护城河”。

缺乏对业务逻辑的理解会让设计师时刻被业务方牵着走。当我们脱离业务来聊设计的时候，它的支撑往往是非常脆弱的。一旦业务逻辑的发生调整或变化，我们的设计就很有可能会直接崩塌，让自己一直处于被动的位置上。

结合对业务的理解和对项目目标的分析，大部分情况下我们是可以回答自己为什么做设计、解决什么问题、如何判断等问题。这些分析和理解也将成为后续我们和业务方进行 battle 的重要依据。

02. 下方：用户需求的约束

在项目的设计过程中，「用户需求」是一个“万金油”，可以在不同的场景下为不同的角色所用。产品经理为了达成自己的目的，可能会将自己的诉求“包装”成用户需求；设计师会以此作为设计底线的坚守；而工程师则会以此来质疑业务方的需求，推掉不利于技术团队发展的需求。

当然，我们不能因此而对用户需求曲解。它依旧是我们设计策略的最为重要的依据。但同时我们也需要注意，有些时候用户提出的需求以及业务方理解的需求其实并非用户的真实需求，这些答案依旧需要我们花时间去研究和分析。

至此，如果上面两个环节做得还行，我们的“天花板”和“地板”基本上没有太大的问题，不出意外的话走到“出口”之前应该不会垮掉。但我们最终是顺利的走出去，还是狼狈不堪的跑出去，还得依赖于我们左、右的两面“墙”，技术能力约束和设计质量约束。

03. 左侧：技术能力的约束

日常聊业务的时候，工程师会告诉你技术什么都能实现；但一旦到了具体设计实现的时候，工程师会告诉你由于一些原因这个实现不了。🙂

这就是真实的日常。正如我们前面所提到的，对于产品相关的工作设计师也许还能参与一些，但在技术方面，绝大部分设计师只能做到对技术能做什么有一定的理解，再深入下去就只能听工程师的了。

坦白讲，这么多年下来对于这个问题我也没有太多更好的办法。唯一能做的就是保持良好的沟通，维系好与研发团队之间的关系。在做设计的同时也更多地为对方发展考虑，建立起足够的信任感来确保技术部分有足够靠谱的支撑。

04. 右侧：设计质量的约束

作为设计团队最为核心的交付物，设计质量是评判设计师及其团队最为重要的标准之一。抛开前面提到的外部约束，设计团队最难也最需要做的就是建立设计的标准，或者说是约束。

同样是一个功能界面，你为什么不能做得和别人一样？你为什么不能做得和别人不一样？这里为什么不能多放一个按钮？为什么那个模块要放在这个模块的上面……

这些设计问题，如果单独一个个地去聊 ，可能花一整天你也掰扯不完，甚至还会被对方认为不够专业。因为它不像确定的业务目标那样足够的坚实，也不像技术能力那样有足够的专业壁垒。

我们唯一能做的就是放弃单点作战，基于数据、业务特性以及行业特性抽象并建立一整套完整、体系化的设计约束，如果可以，将它与研发团队进行绑定，形成一套稳固的产品设计研发的“脚手架”。

这里最典型的代表就是业务级的设计系统，通过它将业务场景中的核心流程、交互模式明确下来并不断的进行优化、迭代。让大家在项目中讨论设计时省去对那些基础设计模式的讨论，将关注的重点回到如何解决实际的问题上来。

05. 背面：团队合作的约束

如果要说在一个项目中最不稳定的因素是什么，那么我认为它一定是人本身。我们可以讨论出一个不错的解决方案、规划好所有的工作，但却无法防止有些人会在项目的过程中掉链子，甚至是完全没法顺畅的合作。

当大家铆足了劲向前冲的时候，还是得照看好自己的后背。我的核心原则就是：

•事前与项目组所有人明确好责任和角色，让大家都清楚自己的职责范围，杜绝模糊地带；

•事中做好确认和记录，及时发现和解决问题；

•事后总结和回顾，有问题的追溯责任，吸取经验教训避免后续再次发生。

 

不同设计阶段的重点关注

虽然前面提到的这五点约束在整个项目的生命周期中非常重要，但我们在每个阶段中所需要关注的重点还是有所不同。

不同设计阶段对约束的关注

在前面的输入阶段，我们的最首要关注的是背景、问题以及我们能给出什么样的解决方案。所以我们的重点会放在业务需求、用户需求以及技术能力上，首先保障的是我们能讨论出大致的方向和可行性。

在产品方向大致明确之后，我们就需要进入具体的设计阶段。这个时候设计会基于前面的背景来进行产品的体验设计，与研发团队共同协作确保设计方案的确定可行性。

当设计完成交付之后，研发团队将接手需求进入产品的开发阶段。这个时候我们的产品目标、设计方案基本都已经敲定，设计师需要更多的跟进研发来确保设计方案和体验的还原度。

写在最后

约束是团队运作、项目研发的必要保障，合理的应用这些约束才能够保障我们的每个阶段都能够获得足够妥善的保障，也有助于最终获得更好的设计结果并实现产品的交付。

当然，我们以上聊到的这些更多还是思路和方法，真正的项目过程中我们还会存在很多的不确定因素，这些都是真实的场景中不可避免的。

约束无法给予我们设计工作绝对的保障，但它的存在会很大程度上给予项目组成员一些必要的“约束”，让项目的推进能够获得必要的保障。它真正的价值和作用，还需要大家在日常的工作中去实践、调整。

也欢迎大家感兴趣的可以在群里或者私信我，聊聊在日常的工作所面临的那些约束。

最后，给大家推荐一篇 Shopify 设计团队的文章。虽然文中的讨论仅在设计环节本身，但大家还是可以看看他们如何基于约束，来推进自己的设计系统改版工作。