为什么你的交互计划过不了？大厂妙手教你这 4 个要领！

时间：2022.04.13作者：彩乐园浏览量：1380

你是否和我有过同样的经历：当我们费尽心思、信心满满地做好了一个完成度很高的交互计划，可能被别人的几句话就否定了。

场景 1

和 leader 确认交互计划时，刚讲两句就被 leader 全盘否定，导致自己带着 leader 没看一眼的稿子默默回到工位、重新再来。

场景 2

和 pm 确认交互计划时，pm 一遍一遍提出疑问、还说了 A、B、C、D、E 种种想法，导致自己的计划重复修改、无法准时交付。

场景 3

向 boss 推自己的设计自驱计划时，无法获得 boss 的认同，导致最终无法争取到开发资源、自驱项目最终流产。

场景 4

大厂面试官对作品集中的某个项目不绝发问，而自己却难以给出令他满意的回覆，导致面试最终失败、无缘 offer。

对新人设计师来说，计划被重复否定不但费时辛苦，还让人怀疑自己的能力、摆荡自己初入交互大门的自信。那今天我将和各人一起剖析什么样的交互计划是经不起推敲的计划，如何泛起展示，才华让我们的计划（至少看起来）严丝合缝，经得起别人的重复垂问和推敲？

泛起形式重要，但推导历程更重要

日常的琐碎事情和求职准备会让许多人忘记交互设计的实质。

从视觉设计师的视角来说，交互设计是对用户行为的设计，这和用户直观可感受到的视觉设计有很大的差别。

从产品的视角来说，交互设计更偏向对行为细节和用户心理的打磨，和宏观、粗糙地设计整体产品框架有很大的差别。

交互设计师应该输出的是整个设计推导历程：用户在操作流程中的行为习惯、预期心理、使用场景、使用痛点的等等，而不但仅是最终看似完美的视觉泛起形式、或者看似有条理，可是缺乏细节打磨的功效介绍。

用闭环思维严谨地介绍你的设计

那么，如何做出一个经得起推敲的设计计划、一个严谨的设计历程？或者说什么才是交互设计这个岗位需要去重点强调、重点展示的？我认为一共有这几点小技巧：

1. 永远不要一上来就讲设计图

不管你是晋升答辩、日常对接、组内过稿照旧面试讲项目，作为一个交互设计师，永远不要把一张设计图摊开来就开始讲细节：这里是什么颜色、那里是什么排版思路…这不重要。

交互永远都应该以「项目目标」作为开场话题：pm 想做的是什么？要取得什么样的结果？甚至集团、公司想要的是什么结果？甚至 pm 所想到的功效计划是不是合理的？这个计划为什么值得我们投入设计资源甚至技术资源？我们要做的是以目标为导向的设计，不然毫无目的设计所带来的产品大多是四不像。

2. 用“用户觉得”取代“我觉得”

挖掘、定位用户痛点是交互设计师两件最重要的事情之一，另外一件则是解决挖掘到的痛点。在你开始讲你的项目之前，花几分钟和你的老板、面试官介绍你的用户群体是怎样的？用户是在什么场景下完成整个流程的？他们有怎样的心理预期和行为习惯？

甚至在这个环节你可以把冷冰冰的、笼统的用户数据串联起来，讲一个似乎亲身经历的故事：好比你某次发明你们的用户如何使用产品、他遇到了什么问题，你又是如何解决的？好的用户故事能让人快速感同身受，你也就不需要一遍一各处向你的老板解释你为什么要做一件事——用户在这个场景下想要，就是这么简单。

3. 介绍你的计划和假设

每个交互设计项目上线前都是一个黑盒。用户可能喜欢它，也可能不喜欢它。设计师之间、设计师和老板之间、设计师和产品经理之间打嘴仗永远无法真正验证一个问题，今天可能你发挥得好吵架吵赢了，明天可能发挥得欠好只能回去洒泪改稿。

我认为为了真正说服你的听众接受你的计划，最幸亏介绍完计划后，直接说明设计计划中有哪些部分是基于推导和假设形成的：如何评估设计目标是否抵达、如何进行后续优化迭代，如何制定命据指标？虽然这关于一个快速迭代、或缺少数据基础建设、孵化的产品线来说可能是比较难的，但这是所有大厂的事情要领。

4. 靠谱的计划输出

上面讲的所有建议都是针对设计展示时演讲的建议。虽然打铁还需自身硬，一个交互稿能够经得起推敲和询问，实质上还要靠完整的计划输出。

交互稿有有许多种形式，比较常见的就是页面交互图，讲页面、操作流程、组控件状态、界限情况描述清楚以供视觉、产品、技术、测试等同学使用。一些庞大需求，建议在计划初稿输出后做可用性测试，这样就不至于在评审、过稿的时候针对计划的庞洪水平重复拉扯，可用性测试的证明足以一锤定音。

结合案例，究竟怎么做？

最后我们再回过头看下文章一开头那些场景——想必现在你也知道问题是什么、该如何解决了。

场景 1

和 leader 确认交互计划时，刚讲两句就被 leader 全盘否定，导致自己带着 leader 没看一眼的稿子默默回到工位、重新再来。

问题原因：在一开始需求剖析阶段就跑偏了，没有搞清楚目标是什么就开始做计划，导致后面的计划全盘跑偏。

解决计划：不要过快地深入交互细节，而是要让你的 leader 了解清楚需求的实质，对齐认知后再深入，不要被 pm 其时的计划带偏。对计划时，可以使用数据等有利说明的方法讲清楚配景和目标，让上级快速理解需求。

场景 2

和 pm 确认交互计划时，pm 一遍一遍提出疑问、还说了 A、B、C、D、E 种种想法，导致自己的计划重复修改、无法准时交付。

问题原因：这类型的 pm 大多只看最终泛起、缺少对用户行为逻辑的思考，很是容易陷入交互稿细节、拿未必主意。他们需要的是用户体验专业层面的建议，告诉他们应该接纳什么是合理的。

解决计划：先把设计研究阶段的结论同步给 pm，告诉他们因为是这样这样的问题，才有了最后的计划。相同历程中制止一些不确定、显得不专业的词汇，如“我认为 XXX、可能 XX、应该是这样的吧 XX”，建议使用“用户在真实场景中是 XXXX、从用户心理层面出发是 XXX、用户习惯于 XXX”。

场景 3

向 boss 推自己的设计自驱计划时，无法获得 boss 的认同，导致最终无法争取到开发资源、自驱项目最终流产。

问题原因：老板没有看到做这件事的迫切性、投产比。

解决计划：和老板推项目时 PPT 很是很是要害。调研历程尽可能可视化出来，特别是数字、结论。计划要完整，最好配合视觉设计师泛起出最的页面效果、用 DEMO 演示。

场景 4

面试官对作品集中的某个项目不绝发问，而自己却难以给出令他满意的回覆，导致面试最终失败、无缘 offer。

问题原因：或许率是保存两点问题：1. 项目没有抵达设计闭环，缺少某一环节，好比设计研究不充分、缺少效果评估；2. 设计研究结论与设计目标、战略没有完美对应，面试官质疑计划是否是以目标为导向、是否可以解决问题

解决计划：检查整个设计历程中是否缺环节，特别是效果评估的数据指标应如何选取、如何剖析；检查设计推导历程和最终战略、计划是否对应，逻辑要严谨。

上一篇 : 7 个实用要领帮你学会设计立体字效

下一篇 : 可视化大屏设计快速入门指南

14
分享到：

back