实习小总结(真)

趁着找实习的时候,彻底回顾了上一次实习的日记(和之前写的实习小总结),提取、整理了更加有代表性的部分。本来上周就已经整理好,也记在了日程本里,不过突然得知要面试,就先准备面试的事情了。寒假做好的作品集终于有了用武之地。突如其来的两场面试,一场通过了却因为时间不符合而无法获得最终 offer,一场还在等待结果,…不过今天已经是通知期限的最后一天了,姑且让我还抱有一丝希望吧。

说起来,上周终于把 Microinteractions 看完了,寒假还看完了 Emotional Design ,偷懒了。感想写在了豆瓣,倒没有仔细做笔记。现在照着书单,开始看《网站设计解构》和 The Smater Screen,也开始系统地做一些笔记。前者解答了我一直以来的疑惑,即交互设计与系统框架是否冲突,后者目前还未看到令我眼前一亮的地方。

以下是正文啦。

与 G 前辈聊天

设计的落地问题
这是在做后台交互的时候遇到的问题,关于职位的意义。在后台的时候,开发很少会严格按照交互稿的形式出品,这让我不满又困惑。前辈给的建议是从其他角度,比如易用性、少出错性去说服产品经理和开发人员。当然最重要的还是沟通和沟通和沟通,如果坚信自己的方案是更好的,就去表达、沟通,让其他人明白「为什么要这么做」。这一点在实习小总结:101天(一)中详细写了。

熟悉业务
了解情境,包括是谁在使用这个业务、业务的上下文是什么、为什么要使用这个业务,并且明白这个业务对其他业务的影响。

拿到需求后要?
主要看需求是简单的/复杂的?如果是简单需求,比如小优化、单个页面,那么在最初与产品经理沟通的时候,就可以通过画草图迅速地总结、给予对方反馈,而不是到出了交互稿后再与对方确认。如果是复杂需求,则需要更进一步地挖掘,弄明白提出需求的原因、与其他业务交互的情况,等等。

与 P 前辈聊天

用户提出解决方案
这其实是在旁观 P 前辈进行用户访谈时得出的结论。当用户说得起劲,给出自己的建议时,无论那些建议有多不现实,P 前辈仍是微微向前俯身,给予用户积极的反馈,鼓励用户接着讲,并且适时总结用户的表述。而我当时在一旁偷偷想「这是不可能做到的」。不过现在也算是学习到了,可以从用户各种各样的建议中挖掘他们的真实需求。

优化的需求
因为本身是优化而不是大改、重版,所以需要考虑到开发和需求本身,一般依照原有的框架进行修改,而不需要另辟蹊径。

职位的意义
当时还在做后台, P 前辈之前也做过后台交互。所以在聊天的时候提到这一点,P 前辈说尽管有很多困难,但是在做一个业务的交互时,还是要抱着尽善尽美的态度,去思考场景、提高可用性,追逐太阳的人可能得到月亮,但是追逐月亮的人就只能得到星星。大概说了这样一番话。

APP 端和长租项目

视线流问题
这个大概是弱项了,遇到了两次。其实是知道的,但是在做的时候经常忽视了,直到被其他同事提醒才发现。

模块和流程
也算是在长租项目里最困难的一件事。第一次接到完整项目,一开始自己梳理需求,把整个项目按照模块划分(软件工程思维),不知道该如何下手,自己也说不出哪里不对劲。向同事请教后,才明白应该以用户的视角去思考,用交互设计的思维、按交互的流程划分,比如主要流程和次要流程(写到这里突然加深了对用户旅程地图的理解)。而找准流程、在交互稿里清晰地展示,则又花费了不少的精力去学习。

数据到底对谁有用
这是很让我自责的一点。跟着产品经理做项目,陷入了「获取对公司有用的数据」这一陷阱,脱离了交互设计中以用户为中心的思考与反思,没有坚守在用户的角度去思考这个行为对用户是否有利。

各种各样的异常
直到项目开发的末期,才在测试同事的帮助下确定了异常流程。但实际上,在最初考虑流程的时候,就可以思考哪里会出现异常,然后一步一步多问多想、确认不同的异常,而不是到最后匆匆忙忙地思考。

不要做最好的假设
在这里,「好」=「偷懒」,与上面的异常可以一起思考。不过不仅是思考网络、设备方面的问题,更多的是人会犯的错误。

在会议上使用 User Story
这是在参加后台产品经理与其他部门沟通业务的会议上感受到的。在产品经理讲完一大段很多角色参与的需求后,一个参会人员举手说是否能以 user story 的形式讲述,否则很难明白。这提醒了我,user story 不仅仅是画在作品集上好看的,也不仅仅只是交互设计师的利器,而是可以串联起业务内的各方人员的线,降低沟通成本,提高沟通效率与同理心。


还有很多要学的,还有很多可以改进的。祝自己好运。