专栏名称: 超人的电话亭

只分享有价值的设计经验。

这是你在网上找不到的真实交互实战思路

超人的电话亭 · 公众号 · 设计 · 2024-10-16 22:34

正文

交互工作中的主要问题解析

虽然对于UI设计师来说，理解交互是什么，以及掌握不同需求、场景中输出交互方案的形式很重要，但它们都只是做交互设计中最入门的要求，简单学习、掌握就可以上手。

文章链接：苹果商店界面用户体验改版

约等于写一篇作文，掌握了削铅笔、给钢笔补墨、打开笔盖、正确握笔、书写格式这些基础知识，但不等于你能写出好文章。

那什么才是优秀的交互产出成果呢？

用一句话解释，就是 —— 解决问题的交互方案！

解决问题这种笼统的话术大家肯定听得耳朵都要怀孕了，重点在于，解决的是什么问题？我相信大多数同学对这是没概念的。

我们先把一个完整的交互方案的生命周期整理一遍：

在前期，上游需求方会整理业务上的需求，再经由产品经理转化做成产品需求，然后通过产品需求评审会议，来解释产品功能意图和安排，并根据反馈改进需求。

设计师在获取需求以后，要进一步对需求进行分析，理清背后的目标和逻辑，然后再开始动手设计交互方案。在完成方案以后，再进行交互的评审，收集团队的反馈和建议，然后做进一步的优化做定稿，再进入下一步设计的过程。

在交互和设计都完成以后，那么就开始正式的前端开发过程，前端工程师需要实现相关的界面和交互操作，并发布测试版供内部进行测试，排查问题。

问题会出现在流程中的各个角落，下面依序列举一些常见的问题：

业务需求没有完全确定，或是后续很快会做调整改动
产品需求没有闭合，很多操作细节没做，逻辑缺失
产品做了比较离谱的需求，而且要求按他框架做
做的交互非常“独特”，没有先例也找不到类似的参考
做好的方案在评审中被各种反驳，大家对方案不满意
其它团队成员对交互方案的意见不统一，各执己见
做好的交互方案实现成本过高，开发不愿意实施或做不了
……

只要真实项目经验稍微多点，那么对上面这些问题一定都不陌生。交互要解决的问题，就是要——独立输出可以满足上游需要且能符合团队成员预期的方案。

在流程中，前期最大的难点是“没有参考”，因为很多设计师属于没有成熟的设计案例致敬或壮胆就做不出设计方案的状态。但它可以通过经验的积累来解决，是相对容易克服的。

更困难的是后期评审阶段，团队成员对当前交互方案不满意，或意见都不统一的时候怎么办？而这又会牵扯到上一个问题，因为做的交互是独有的没有线上案例，团队成员又有意见，更没有想法也没有信心了怎么办？到底怎么做才是最完美的方案？

很多初级设计师都会面临这种处境，结果不是摆烂随便应付，就是到网上、社群里提问，我们在交互方向碰到的最多的问题也是这么来的。

但很遗憾得说，在交互的领域中基本不存在完美的方案，想要符合专业评价的优秀案例也很困难。在真实项目中，往往只有 能过稿的方案和不能过稿的方案两种。

不要用理论还是书籍的内容建立对交互设计师的理解，真实的交互工作要做的是先能过稿，再考虑体验、交互、样式这些“次要”的问题。

下面，我们就基于这个思路，来解释在真实项目中，如何完成交互方案的准备和输出。

交互设计输出的案例分享

还是以学员的真实工作项目为例，下面是一个环卫车辆调度计划创建的流程，每个调度计划下包含多个任务，而每个任务内又包含多条路线的组合，所以目前完成的方案是这样的：

解释一遍当前的交互流程：

先进入调度计划列表页，点击创建计划
在计划页面填写信息，并点击创建任务
在创建任务弹窗内填写信息，并点击创建路线
在穿梭框中添加街道并排序，点击确认完成
在任务弹窗中点击完成完成任务创建
再在计划表单页中点击完成创建计划
回到计划列表页面

在输出交互流程中，不会动摇的核心标准首先是要能实现功能需求，在当前的方案中，满足计划、任务、路线的创建是可以实现的。

但是，能不能过稿，好不好用，体验如何能精准预判嘛？

当然是不能！

即使是给我评价，我也很难给出完美的解答，或者让我做，我也不能确保我做出来的方案就必然能过稿还是最优的选择。不确定性多、疑问多，很容易让我们陷入迷茫，但这也是我们要接受和挑战的地方，而不是陷入虚无。

所以，解决这类问题的方式，第一步就是先用最常规、最原始的模式实现需求。比如上面案例，就符合这个标准，每个操作步骤，做一个独立的页面或弹窗，一次解决一个产品需求和操作步骤。

你们如果用这个思路去套多数的交互流程，会发现只要愿意多给页面、弹窗，几乎就没有解决不了的需求。

但这种做法肯定是很粗糙的，能用但是不会太理想，所以我们要带着批判的眼神去分析当前做出来的版本，总结它的优缺点，并输出后续的版本。

假设上面是我做的第一个版本，那么下面是分析的内容：

优点：操作步骤直观，易于理解，实现简单
缺点：层级过多，弹窗套娃，关闭确认过多

然后我就可以根据对原有界面的缺点，去做改动。首先针对弹窗套娃的问题，那么新的方案就要减少层级，首先创建计划级别最高，且计划下可以包含多个任务，既然操作时间会很长，就直接用新页面操作即可。

任务创建作为下级内容可以用弹窗实现，但是选择路线的穿梭框弹窗就多余了，所以干脆就合并成一个页面，那么难点就是如何选择路线。

第一种做法也可以用类穿梭的模式，罗列出所有路线，然后选择生成相应的表格，而怎么布局没有固定的，我的第一个想法是做成左右布局，左侧是路线列表，通过选中在右侧表格中生成。

但因为空间不是非常够，感觉正常的操作思路中选择路线的权重是表格操作和检查的，所以我再换个做法，突出路线选择，把路线和表格做成上下排序，为了提高路线的展示数，做成多列的卡片，使用中选完路线再去检查下面的表格。

这些做法都比较激进，感觉开发起来挺麻烦，所以干脆再预留一个最简单的版本，只留表格，每次添加新的路线的时候，从一个下拉菜单里选路线（让用户麻烦）。

到这里第二个版本就做好了，结果如下：

PS：只是交互原型，不代表实际样式，还有很多想法没空做了

站在设计的角度，我们自然会更倾向不断调整后的版本，但我们自己怎么想不重要，因为最终过稿不是根据我们自己的喜好。

所以也不用纠结有没有线上的参考，把产品的需求实现出来（能用的），并尽可能考虑不同的解决方案，每套方案有自己的依据，那么它就可以进入评审了。

输出多套方案的好处在于我们了解每套方案的优缺点，在评审阶段我们可以直接展示不同方案介绍它们各自的优点和缺点，让团队成员进入我们的思考模式中，要让他们在评审里对交互方案做选择题而不是应用题。

除非是用真实体验数据、可用测试报告做支撑，否则引用的任何体验、用户、理论都只是说服团队成员的工具，它们是过程的一部分但不是目标。

没有任何事情比过稿的权重更高！

结尾

网上之所以很少有人分享交互案例，说到底就是每个成型的案例里涉及的问题太多，有非常繁琐的前置条件，如果不解释前面的需求，以及项目实际的环境制约，那么这套方案就没有任何价值。

尤其大多数人没耐心看字，原因都没搞明白就“还不如原版”了。所以交互知识、内容的就会变得闭塞、玄学起来，只可意会不能言传。

一直以来我们不断分享交互相关的改版，都是基于我自己分析的前置条件给出的解法，不代表它们是唯一标准，仅供参考。基于过稿的标准的话，那么我所做的一切方案都是“错的”。

至于什么才是对的，就要靠你们自己在项目中领悟了。

B端设计明晚开课了，第一节试听可以预约观看，有需要的同学下方扫码：

如果需要直接报名那就来找我，等你一起变强了。