总听到有人说“交互设计师的门槛很低”。这样一个“是设计就能做”、“产品开发测试也能轻易转型”的职位，做个新人真有那么容易吗？
以下是我开始做交互所体会到的几条“新手陷阱”，希望它对你有用。
1. 识别需求
识别需求对交互新手尤为重要。为什么这么说？新人总是抱着学习的态度向周围人请教，我们以为做到低调、务实、谦逊、勤奋就够了。因此，产品提出的需求就是任务，有了就要做。
但在交互评审时，我常常看到大家把设计先放一边，热烈地讨论起需求来：“实现目标一定要新加这个功能吗”，“改了样式，会不会增加用户对它认知的难度”，甚至是“这个需求真的有必要做吗”。评审时听到这些我会无所适从、盼望产品现场给个答案，但工作一阵后我才发现，这是设计师接到需求第一时间内需要思考的事。识别需求是交互工作的一部分。
举个例子。刚来没多久，领导有意无意把一个“模棱两可”的需求交给我：为我们的电商小程序做一个多人拼单工具，满足多个熟人用户针对同一活动凑单的需求，增加小程序的回访和日活。
背景 多个熟人用户想要对同一个活动来凑单，达到省钱的目的。
目标 设计一个多人拼单的工具，增加小程序的回访和日活。
看似类似外卖小程序的“好友拼单”，我就一步步照需求做完了：
发起拼单流程
参与人拼单流程
其实，我并没有注意到：
外卖小程序的拼单场景：同地点的朋友同事一起点餐，拼单可以减免费用，且便于算账。
电商小程序的场景就有点奇怪了：好友未必在同一地区，且并无数据能证明用户会特别为了活动优惠而和好友一起下单。拼单需要共享购物车信息，如果真的要互助凑单，好友只要把要买的商品发给对方就可以，没必要在购物车里头疼地过目对方的每笔支出。
由此看来，电商平台的购物不是一个商品种类单一、可以快速选购付款的过程，且牵扯到个人优惠券的使用、邮费是否均摊等等问题。
除此以外的麻烦还有：
1. 小程序有了共享购物车而app不做，两端信息不同步；
2. 难以维护商品和操作人的关系：优惠券、活动优惠的均摊问题，是否单列出个人的优惠金额问题；
3. 分享的安全问题：共享购物车能否让所有人编辑？其他人能否看见非拼单的商品？
4. ….
交互评审中同事直接质疑了这个需求的合理性，而后续的方案评估也直接决定不开发这个需求。如果我能火眼金睛地早发现问题，和产品深入讨论后衡量方案的可行性，就不需要用白费的力气去证明它的不合理。不过，能学到这一点，力气也不算白费 🙃
2. 视觉呈现
视觉方面的事看似不在交互的考虑范围。而实际上，低保真的交互稿削弱了颜色、轻重对比等信息带来的感官刺激，加上没有放入真实的文字、图像，我们可能会忽略视觉对信息结构的影响。标题最多几个字？文案来自哪儿，如果是后台配置有字数限制吗？最多展示几行，放不下怎么处理？图文排版是否太密集，给用户造成视觉负担？这些都可能影响到交互的输出，如有必要，需让视觉稿把极端情况画进去。
在简单框架和视觉元素表达之间做出平衡
3. 交互稿的意义
我曾以为，交互稿就是输出各阶段所有可能有的页面，外加操作反馈和信息字段的解释说明。
这里存在两个问题：
1. 交互稿未必要放出所有页面。它直接作用于你的下游的工作，是视觉设计师的底稿，是开发测试用来实现和检验的逻辑标准。他们怎么看得懂，就怎么画。
2. 交互稿不止于页面元素和状态，而是“流程 + 页面状态”，特别是对涉及营销和社交互动的设计而言。此外，读者可能不熟悉/不记得设计前的页面是怎样的，因而交代清楚前因后果、前后比较也很重要。
比如，当用户操作触发了页面顶部弹出通知，完全画出来就是这样：
两页稿
实际交互稿也许不需要两个页面，因为通知（消息/提醒/警示等）很可能是一种全局反馈，设计规范里的样式和交互方式（点击跳转、上滑消失等）是统一的。只需单独给出通知文字，简单说明出现时机和操作反馈即可，剩余空间可以放其它元素的更多状态信息。
一页稿 + 说明
4. 工作驱动力
交互设计 = 用户体验？No, 交互设计本身就是一个交叉学科，涉及心理学、社会学、人机工程等等多方面知识，只关注信息结构和可用性还不够。
在公司做商业设计，协助产品运营达到商业目标也是我们的目的之一。关注业务目标，做劝导式设计、驱动行为的设计。就算功能完全没问题，也需要触动用户去发现、引导他们体验和完成，引起用户的情感共鸣等等。
5. 对待需求的方式
虽然项目时间有限，我们希望尽快摸索到设计方案、搞定需求，但只有长期和它相处、不断打磨，你才会发现更多的问题和可能性。
出完第一版稿后不要急着输出，多看两眼，评审完后再看两眼。和开发的沟通中多考虑一点，上线后多关心一下数据的变化（如果能让用研配合你的工作就更好了），可能你就会发现遗漏之处，对项目的目标和结果的印象也更深。
不知不觉写了这么多，其实交互50%左右的时间都是在和人交流，高效的沟通方式也很值得去探讨。下次说说怎么和各岗位的同事们合作吧 🙇
网友评论