实习小总结:101天(一)

in 实习, 交互

如果实习日记没记错天数的话,在滴滴一共实习了六个月,工作日期为101天。从最初每天都写,到后期以周为单位进行记录(一种熟练外加偷懒)。

回到学校,在给了自己充足的躺着不动的悠哉时光后,翻看实习日记,回顾整个实习过程,不如正式一点进行记录。大致可以将整个过程划分为三个时期,可能分为两到三篇日志进行总结。这三个时期,分别命名为信息收集时期、长租时期、写论文时期。

一、信息收集时期

即刚开始实习到接了长租项目的时间。主要做了以下几件事:

  1. 熟悉公司业务
  2. 约谈
  3. 看书/文章

期间当然也接了一些细碎的需求,包括后台页面的优化、协助同事制作软件原型和顶替离职的实习生做一点应用端优化。正如大部分在成型的公司实习一样,从被切碎的模块里不断寻求新的小的优化点。这一时期,基本上在不断询问着身边的产品经理「还有什么需求吗」中度过。

作为后台交互实习生被招进公司,在还未开始接需求时,得到的建议都是「可以先熟悉业务」。同事不厌其烦地告诉我,坐在我某个方向的同事是谁、负责哪个部分,有什么问题可以直接问对方。

于是在 wiki 上按照顺序熟悉公司的业务线和后台的模块。记得在面试的时候,被问觉得 to B 的和 to C 的有什么区别。当时对 B 和 C 的概念甚至是第一次开始思考的我,回答说面向的用户群不同,对系统的熟悉情况和使用动机不同。在真的开始接触 to B 的产品即后台之后,除了惊讶逻辑与业务上的复杂程度,更多的是体会到这些「区别」带给我的困惑。

在熟悉业务的过程中,除了 wiki,也结合了 mentor 给的交互稿和后台已实现部分进行熟悉。后台多是表单、表格,所以不需要视觉同事产出视觉稿,在界面上没有像素级的要求。在说服自己这一点后,仍然发觉后台的实现效果和交互稿有很大差别,主要体现在表单的模块划分和默认组件上,甚至用了不同的组件,页面效果也没有统一。同事说这是因为业务忙、开发量过大,在紧急情况下可能没有遵循统一规范,有的组件也是已经写好的,难以按交互产出的组件设计。

在我真正开始接需求的时候,这些困惑没有因为我身处其中而得到解决。最开始接触的是几个页面的优化需求。我按照理「清需求点 - 与产品经理沟通 - 产出草图 - 再次沟通 - 绘制交互稿」的步骤进行。其间,当我就一个组件的选择问题与产品经理讨论时,产品经理指出这个地方没有必要用 radio,用 dropbox 就可以了。

出于对组件的理解,在此情景下无疑应该选择 radio 的形式。产品经理则说:反正开发同事也会按照之前的做法做成下拉框。被这样告知后,我不由思考职位的意义在哪里,后台交互这个职位真的有必要存在吗?

答案积极一点,当然是有的。有其存在的意义,有其存在的必要。

后台也是有用户的。后台的用户不一定在意美观与一致性,在经过一段时间的培训后也能掌握使用方法,是带有「强制性」与「黏性」的的用户。在使用后台系统的时候,更少的出错与较高的效率才是他们需要的。结合不同的业务属性,在「实现功能」的基础要求上,解决用户将会面临的问题。

在攒够了关于工作的困惑和一些想法后,开始找资深的交互同事聊天。同样也找了其他实习生聊一聊。这是从 镇雷的设计小作坊 中看到的一种获取经验的方法。

每次都从这段时间遇到的事情开始谈起,打好腹稿,最后询问建议。对于后台的「匆忙开发」问题大概是难以解决的,但是仍然要从使用者入手,询问情景,摸清业务需求。一起聊过的同事里,有理性的方法派,也有感性的直觉派。让我看到了更多的可能。

在没有什么活做的时候,除了约谈,还抽空带薪看书和关于 UX 的文章。比起最初在 Medium 上找文章来看,现在更倾向于看 NNgroup 的研究以及规范。还看了网易的《破茧成蝶》,庆幸是在这个刚入行的时间点读完的,否则不是看不出所以然就是觉得太浅。

同样庆幸的是能有这第一份交互实习。普通如我,也能在这个过程中慢慢进行思维的转变。在拿到一个需求后,从分析功能、复杂度,转变到关注用户、使用情景与目标。


很久没写,真·硬憋出一篇真是好难过。∠( ᐛ 」∠)_