在交互设计的工作中，我们常常谈到往前走一步：参与到产品idea的讨论当中去，这助于更好的了解设计产品的原因和目标，好处就不多说了。但如何去做到呢？

很多交互新人进来，工作经验少的同学，他们刚开始可能就不一定适合去做上面提到的要求，他们一开始更多的应该是去了解熟悉自己所要接手的业务线，包括岗位工作流程，对口业务线（运营/PD/视觉/前端/开发/测试/）、网站，产品，用户，还有各种数据，最简单的：主要让你的导师带自己去认识下将来对口业务线（各部门）的相关负责人和leader？等到熟悉甚至了然于胸业务线情况是有能力参与到产品设计更核心阶段当中去的基础之一。试想都不清楚网站有哪几类用户？每天网站新注册用户的转化率多少？转化不成功的原因分哪些？如何能更有效的一起去参与讨论，给出合理的否定理由和有意义的建议。而且和相关业务部门去讨论，其实也是自己在那个圈子里建立口碑和人品的重要过程，这种映像的正向建立到后来你会发现：你从一开始主动要求参与产品核心阶段的讨论到后来相关方主动邀请你去讨论。

根据自己的清楚可以分分阶段，1.新人 > 2.能做事 > 3.事做好。我觉的有能力参与产品idea的讨论中应该是第三个阶段了。记得自己刚进公司做新人，虽然之前已经有工作经验，但那些东西对于来到一家新公司的我来说，很多东西也需要重新开始。第一个阶段要知道公司的交互岗位cover的范围、工作的流程，打好上下游之间的关系，这些是为了便于之后能较顺利的展开工作。这个阶段比较容易渡过。第二个阶段开始了解清楚业务，接手项目，出方案，跟踪落实方案。这个阶段就需要设计师了解的更仔细，比如网站有几种类型的会员？会员账号又有哪几种类型？哪些等级？账号类型等级不同对后台的操作权限有什么不同？不同的产品、模块是否需要中英繁支持？以及它们出现的原因？这些最基础的东西，接手项目的时候理解清楚项目，一般都会有：现状和分析，机会和利益，目标和范围。一开始先别急着就去挑战他们的需分，我相信他们大多在这里待的时间比我久，发起项目也是过过他们的leader，推敲过，不然也不会随便拿出来做BRD评审。而我这个阶段最需要保障的就是评估准工作量，准时给出可行的方案。别因为我延误项目的总体进度，更好的话能保证质量的同时提早交付方案，这样做先给合作方带来些加分印象：认真、踏实。跟踪落实方案也不是小事，从交互稿交付到上线，要经过多个部门，这中间的时间也较久，视觉评审，html评审，功能预演、预发布测试都要参与，特别是html评审会有些实现细节上的变动，外部环境上也会因为资源问题、上线时间要求导致原本的一些设计需优化，变更。有时候项目owner也会为了自行方便改了方案不告而上。这些过程的把控都需要一定经验和方法，而且还要日常工作中去维护这种氛围，这时候就很需要重在执行流程，这是每个人必经的阶段。巩固好上面这些，第三个阶段就想的不光光是做好本职工作了，对那些的驾轻就熟才会想着去影响别人，特别对于业务方，不希望自己只是个工具。还是基于有上面这些扎实的基础，自然而然的会发现在与业务方会议、头脑风暴时，渐渐会有想法，看待问题也会有自己的不同角度，判断他们逻辑推理的合理性，进行有理由的反驳并给出建设性的意见。再有能力，自己去发现问题，整理问题，找机会去推动、去发起项目，解决问题，Review时得到别人的肯定，在后续去调研用户、论坛、群等各种渠道得到用户的反馈、迭代产品。

上面说的三个阶段，大致一个过程

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

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

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

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

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

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

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

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

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

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

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

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