01-04 UI设计师的思维和方法论

如果说设计技能决定设计师的根基，那么思维和方法论则是UI设计师突破提升瓶颈的关键。很多设计师发现自己在工作2～3年后提升乏力，之前那种研究某种技法的新鲜感，逐渐在不断“改改改”的操作中消耗殆尽。网络上流传着不少设计师吐槽甲方，吐槽产品经理或者需求方的段子，也有很多设计师在这种自嗨中负能量满满。但是，我们可以想一想，问题到底出在哪里。在这个现象中，问题很简单，无非是需求方与执行方认知的差异化，想当然。这也是站在不同角度看问题所存在的必然现象。也许你可以诉说你眼中的“甲方”的不专业，其实，“甲方”也在吐槽着你没有做出他们想要的产品。对于设计师来说，关注设计稿的美观无可厚非；而对于甲方来说，更关注通过这个设计，他们会获得多少用户，活动效果会不会好，转化率会不会高，自己花出去的钱是否产生了效果。所以不要以为花钱的主是好当的，甲方同样承担着巨大的压力，一旦他们付了钱但最终拿到的设计没有获得良好的效果，那么这个甲方同样可能会被“炒鱿鱼”。所以，大家都很难，不是吗？

要改变别人很难，那么不妨先从自身去改变。在这里我想要强调的一点就是“面向用（客）户”的设计思维。这种思维其实不仅仅在做设计时会用到，在准备简历的过程中同样用得到。想象一下，如果你投出去一份从网上下载的、连改都不带改的简历模板，那么这份简历到底能否吸引面试官呢？也许面试官每天看几十上百封简历已经看到眼睛生茧子了。所以，不妨多站在对方的角度考虑一下，他们最想要什么？最希望得到什么，然后再去设计。

因此，设计师所要做的，或者提升的关键，就是多一些“同理心” ，少一些吐槽和抱怨。这才是你摆脱瓶颈的关键所在，如下页图所示。

1.面向用户（客户）的设计思维

首先我们要明确一点，设计师不是艺术家，可以随心所欲地“创作”，大部分是面向商业服务的。也就是说，你做的设计、产品，需要被用户认可、被用户买单，才能产生价值。虽然设计师很多时候和开发工程师都被定义为“技术岗位”，也是跟用户接触最少的（相反，工作流中越靠前的岗位，和用户接触的概率越大，比如产品经理、运营、客服等），因此很多时候我们感觉产品经理、运营等提出来的设计需求匪夷所思，就是我们没有站在他们的角度去考虑问题的结果，也许他们只是通过自己在接触用户或者客户时的感受提出了一种解决方案，但是设计师并不知道设计背景是什么，需要解决什么问题。因此就会设计出跟需求者设想的方案完全不一样的内容，最终不断被返工，造成了双方矛盾激化。双方相互吐槽，在工作过程中痛苦万分。

除了“同理心”，我们还必须具有面向全局的设计思维，有时候，用户想要的并不是100%正确的，我们必须去挖掘用户需求背后的深层次心理动机，进而更好地满足这种动机，所以我们再次回忆上文提过的冰山模型图片，可以看到，用户大部分是盲目的、表象的，浮于水面上的部分大部分只是“假象”，我们需要用一种面向全局的设计思维来进行考虑。

所以，对于我们UI设计师来说，要有深挖需求、寻根究底的能力。比如，产品经理提了一个需求：我们的应用首页要改版，然后扔过来一个低保真原型图。在这个时候，设计师应该怎么做呢？正确的做法不是直接打开设计软件开始画图，而是先就原型图进行讨论，收集信息并思考。相关问题包括但不限于：

（1）为什么要做这个首页的改版？

（2）之前的页面存在哪些问题呢？

（3）用户对于老版本首页的点击和关注热点区域在哪里？

（4）做这次改版的大背景是什么？

（5）对于视觉设计方面，有哪些预期和期望？

……

如果你能在做设计之前养成追问这些问题，了解设计背后的故事的习惯，那么恭喜你，你已经开始养成“面向用户（客户）的设计思维”。不妨在这些方面下点功夫，相信你之前的很多执念都会迎刃而解。

2.拯救设计师的“方法论”

如果我们把设计师比作感性思考的动物，相信没有人会提出异议。但是正是这种“感性”，让我们在设计工作中变得无据可寻。而没有任何论据支持，单纯地以“我认为”“我觉得”等方式来表达自己，在业务陷入争论的时候，你将无疑处于不利的境地。这也就是设计师为什么总是在吐槽自己的设计作品总是被“改改改”的另一个根源所在，如下图所示。

互联网瞬息万变，大部分情况下，无法去预知用户对于你设计的产品的反馈。有时候我们一厢情愿地觉得，这版式设计太棒了！用户一定会喜欢！但结果却是，用户反响平平。而有时候却恰好相反，没有花太多精力做的设计反而受到了用户好评。

一切是那么捉摸不定，而这种捉摸不定，不知道正确答案的设计，却最容易在产品设计和开发团队中引发争论。有些人说，这种方案好，有些人支持另一种。在这种僵持不下的情况下，我们不妨用数据说话，通过实际投入用户群的反馈来决定，哪一种是最优方案。这就是灰度测试和A/B Test的由来，如左图所示。在设计稿有争论的时候，这种方法最有效，可以让我们可以摆脱无休无止的无意义讨论。

我们需要做两套设计方案，并分别投放在一定量级的渠道中。通过在产品中埋入统计数据点，对比用户对哪种设计的反馈效果更好、数据更优。请注意，最终我们需要通过数据说话，而不是大家经常会犯的一个错误，即做出两套设计稿，让同事去选择“我喜欢哪一套”。这种选择是毫无意义的，请特别留意。A/B Test是一种低成本的试错方式，也是可以最大限度保证产品和设计安全的一种方式，否则，当我们耗费大量精力，给予极大希望做出来的设计，被用户无情地否定的时候，一切都来不及了。也可以通过这种方式，来说服你的客户或者需求方来认同你的设计方案。这比单纯地大喊“请尊重设计师！”“我才是更专业的！”效果要好上几百倍。

而灰度测试则是A/B Test实施的一种形式。继续举例：比如你设计的应用分别在A、B、C、D应用市场投放。A和B应用市场用户相对较少，但也有一定量级，可以小规模在A和B渠道投放你的新设计，来观察用户的反馈情况。而C和D渠道保持原设计不变，如果A和B渠道的用户反馈调研数据占优，那么标明A和B上的新设计是可以“安全”地投入市场的；反之，打回来重做。

当然，除了这两种方法，设计师也可以展开多种不同规模的测试和调研，借助问卷调查，大数据来支撑你的设计，让需求方看到你的设计所带来的效果。没有什么比这种方法可以让你的设计稿更快通过的了！