［反思］从Basic走向Pro

实习到岗一周多，和leader进行了一次简短的one on one meeting，就我当前分配到的任务，和近期的一些表现交流了一会想法。

从一些近况开始谈起吧。

我现在手上负责的是一个“个性化应用推荐”页面的交互工作，因为算法和应用库的更新，产品希望提高转化率，开发希望优化算法，所以决定对推送页进行一些调整。

在需求研讨会上，产品反复表达自己发现的问题，希望得到的结果，和开发协调排期，这和在学校做东西很不一样，诉求感很强，也许这是推动产品前进的关键。

会后算是正式安排进了日程，我开始按着自己习惯的方式开始着手解决：

1、先陈列出当前的问题：推送转化率不高，展示内容详细，但是局限于单一推荐不能够很好的反馈数据验证推送准确率。

2、列出设计目标：提供多item的展示页面，收集更多推荐反馈，提高转化率。

3、理解推荐item：

它能做一些什么？

用户为什么需要它？

它的评价如何？

我怎么得到它？

4、用纸和笔画出几个自己的第一次想法，给出一个大概的轮廓。

5、去上手试试观察其他应用当前的推送方式，和对推送内容的处理手法。（这里想到了之前好玩的一点，新闻类应用推送都强调实效性带来的影响，网易新闻每次都是第一个给我推送时事新闻，但是我可能在上课或者忙于其他的事情而没有去查看，再次拿出手机时，每次看到的都是其他应用推送更慢的消息）

6、将主要场景构建出来，作出主要任务的原型，和导师沟通，返工修改，再考虑异常场景，让页面在更多时候都能优雅。

现在看来依旧有很多的问题，所以晚上leader在one on one meeting询问我，自己更偏好给出的哪一套方案时，我还是一时语塞，做出来的东西我自己也没有信心能带来很好的起色，当时觉得还不错的图，过几天再来看真的糟糕。

接着leader问了我几个相关的问题：

建立这个算法的数据模型是怎么样的？

除了推送展示类型，什么时间推送会有效？

站在用户的角度来看，这样的推送能不能吸引到你？

推送是不是提升转化率最好的方式？

我试着一个个的回答问题，我们也许从输入法的输入关键词来找相似，涉及到相同应用名称的用户的应用圈里去找重合度最大的交集，或根据最近的时事热点来推荐近期可能增长的应用，例如最近欧洲杯，可能会带动涉及足球的运动类或直播类的应用；推送可能尽量在安排在晚上空余的时间，这个时候的活跃用户较多，而且wifi状况下的用户更愿意去下载；推送本身是来源于产品自身的业务诉求，我是用户的话，如果推送和我的期望不匹配，那推送吸引不了我；除了推送外，可以试着在内容中插入软文更柔和的推广...

然后leader说了一点，你这些回答都很basic，这样的回答你做交互能说出来，做产品的也能说出来，研发的人也知道，那你的这些意见对团队而言的贡献是很小的，这样对产品的发展把控是没有话语权的，给出来的方案也很容易被一些有深度的质问给打破，整个设计的过程就会变得非常被动。

观察，理解，共情，对业务更深入的理解，而不是停留在一些“我觉得”这样的认识上，行业发展的十分快速，可能我们还没有追赶上一个浪潮，身后又掀起了新的巨浪，但是事物的发展还是有规律可循的，从更早的一些互联网发展来看，更多的连接，更多的便捷，生活方式在冲击下发生的变化，可能仍在进化。

走向pro的道路，资深人士和初学者的区别都在哪里呢？对产品的理解，业务的认识，长期面向用户实践总结出来的经验，能够了解到产品研发过程中每一个环节上的变动会给用户带来的影响，在产品和用户间轮转。

我觉得这或许就是我当前存在的一些问题，不够深入，浮于表面和理论，能够养成阅读的习惯，但是缺乏更多的思考，与实际产品相联系，所以往往看完之后会有“原来是这样啊”的感慨，而不是能够针对其中表述的某几个问题引入更深的探讨。平时个人的练习也更多的停留在概念之上，摸索着应该是，或许是，一般都是这样的思维进行设计，更像是对生活中已经存在的一些交互方式的复刻，而没能了解这样的优劣，以及判断是否还有更优的解决方法。

这就是前辈对新人的一些启示性的谈话，让我也找到了很多可以努力的方向。

今天又经历第一次的交互评审，stand up meeting，评审会上开发，产品还有导师一起站着听我讲述完自己的设计方案，其实心里还是有一些紧张，表达起来还是不够清晰，以至于一开始问了许多没有表达出来的设计细节，同样也开始能够认识到leader之前说的basic和pro的问题，确实在很多情况下缺乏更加深入的思考，以至于在抛来各个问题的时候有些疲于应对，例如我从改版前的页面中照样搬下来了评星和下载量，但是开发的同学根据自己的习惯觉得这个位置更适合放置下载的button，列举了几个应用市场的例子，然后开始反问这样的数据呈现是否有价值，或者能起到多大的作用？我回答这个大多数时候是一个安慰用户的作用，不至于用户在不了解其他人对应用评价的时候产生迟疑或者不信任；关于下载button的位置，我一开始认为是保证应用能够在查看和之前滚动列表中呈现的下载路径一致，所以没有对下载button进行一个调整。这个时候一位产品就开始表达自己对返回有效路径的理解，首先应该是考虑在一个通畅的流程上完成任务，而不是返回去寻找，这样对用户来说会显得不太自然。再有就是关于这样收集的数据是否能够有效的反馈优化的数据？我这些是不是能够对用户模型有促进作用？我也是很浅显的表达了主动下载是一个正反馈，浏览不下载是一个负反馈，可以根据这个来调整模型的算法。然后开发同学提出来是不是能增加一个“不感兴趣”的button，对负反馈进行细分，点击之后是强负反馈，对模型的调整更加有效。然后针对这个强负反馈，又提及了是不是增加pop筛选负反馈类型，但这个增加了用户的操作成本被ban了，然后模型本身也不通过收集这样的数据进行调整；之后可能因为自己对客户端和H5的理解不够深入，针对下载状态和异常提醒做了无用功，因为像是网络断开，通过H5检测再去唤起本地应用，以及通过浏览器判断应用下载完成的状态这样系统内操作不太能实现，所以ban去了很多的原型。总的感觉是，评审会上的交流会综合起来很多的因素，产品自身的业务目标，和当前已有规范是否冲突，技术评估及日程排期等等。在评审之前，我只是从自己比较狭隘的视野中去窥视到产品的面貌，而在评审中就是将自己所看到的去表达出来，让团队中的其它人也能过看到我的想法，然后再去综合各方面的考量，协调博弈，最终产出一个与各个成员都能够接受的方案。这和在学校里做东西的感觉还是很不一样的，学校里考量的问题深度很低，基本上不会有什么业务压力，涉及到的更多是主要场景，更加自由但是也很粗简。也许这就是与正式工作中的不同吧。思考，交流，再去试着努力看到更前一步的问题，知道是什么，也去了解为什么。

这也算是第一次评审上的收获吧。

谢谢～