标签归档:产品资源

资源不足的时候,交互设计师应该做的合理选择和取舍

一些刚入职的交互设计同学提到:资源不足的时候,交互设计师应该做的合理选择和取舍,后期规划很重要?

整理些自己的看法,先来看看资源不足的原因:

  1. 从大的环境上看,做产品很少有说资源足够的时候,基本每个产品都可以说是资源不足的,因为每个产品都可以做的更好(交互上,代码上,视觉上),更好就需要投更多的资源,这是个无底洞。
  2. 从资源分配上看,每个PD都背KPI着,虽然资源的分配和保障是按产品的重要性划分优先级的,但一条业务线产品较多时、用户需求较紧迫时,资源就可能被稀释或要求缩减。
  3. 从产品开发过程中看,PD完成FBRD后,各职位评估的工作量总和就是项目需要的总资源(当然有些可以并行),在开发过程中PM的管理不善、或者评估乐观等原因也会导致资源有所紧迫。

这时候PD一般就会选择把产品目标直接相关的功能先做,不能直接与产品目标相关的功能就会选择砍掉,所谓的先有再好。比如AE发布产品的选择类目,最早的时候只有选类目,没有导入类似产品、查找类目、输入名称/拼音首字母,这些提升用户体验的类目选择功能。

BB5AEC68-7BDF-428C-9B6B-A77BBB6C2397 

那我们能做什么呢?相信分析清楚资源不足的原因和PD的心态,能更好的让我们做选择。记得应聘交互设计职位描述中有一点:分析商业需求和技术可行性,在有限的项目资源内,给出双赢的解决方案。

所谓的双赢,我理解就是交互设计师在工作中需要有一种平衡能力,打不不恰当的比方,如果说用户体验和项目目标在天枰的两边,你就是站在中间的那个Controler。

还是回到上面的原因来看:

第一种情况就不说了,大环境。

第二种情况,如果我们能事先感受到某个项目资源很紧,那么在我与PD确认和认同项目目标的情况下,考虑交互方案时就通过大致的线框图先与技术方去沟通可行性和复杂度(不是交互评审哦),只是面对面的抛想法、画勾思,这样的前期沟通达成一致,有利于项目后期平稳的实施,就算在交互评审时也会相对顺利很多。在别人挑战方案时做足功课、应变如牛。

第三种情况,在开发阶段出现资源压缩要砍需求,那就把项目的功能一个个列出来和PD一起来看,哪些是项目目标上必需存在的,哪些是锦上添花的。重要和紧急的筛选方法相信大家都知道。如果出现有双方不认同的地方,也可以找有经验、或者之前接触过这块业务的设计师再来看。

关于产品后期规划(二期、三期实现),个人经验其实我不怎么看好这种方式,指望有人会去实现哪些当初筛选掉的功能,相对还是比较理想化的……原因很简单干完这一票,就有其它的更重要的项目来了、资源被倾斜、产品换人管了,除非产品上线后,你有很充分的理由说明哪些筛选掉功能的必要性。我做法就是一些提升用户体验的功能尽可能的在第一期做上去(这里可能需要一些经验和沟通技巧不细述),当然实在做不上去的,那还是要记录下来,有的可以借一些其它项目的顺风车想办法一起做掉,有些则需要找机会上产品例会去抢资源立项解决,在这个过程最主要的就是耐心和坚持,还是规划完就放在哪里了。当初做产品管理页面的ID搜索功能,等了近一年地有机会做上去;做POST更是记录了一大堆问题,找机会上产品例会,自发项目去解决的。

资源不足的问题会在以后的工作中常常邂逅,除了懂得取舍外,交互设计师还可以尽量控制避免,慢慢学会拿捏得当。