交互设计师修炼之道第一招

摘要:曾经听过一首歌歌名叫“死了都要改”。改,也曾经让我心存怨念很久很久,不仅仅因为改这个事情需要花费更多的时间和心力,更加因为内心深处深深感受到的不被认同。

改改更健康

第一招:“改”——适应,并且接受

交互设计师所经历的最痛苦的一件事,莫过于“改”。

曾经听过一首歌歌名叫“死了都要改”。改,也曾经让我心存怨念很久很久,不仅仅因为改这个事情需要花费更多的时间和心力,更加因为内心深处深深感受到的不被认同。

即使如此,我仍然执着的做着设计师,并且一做就是十年。

然而,改,渐渐地变成了我工作的一部分的时候,我又重新审视这个字,也有了新的体会。

为甚么要改?一定是因为分歧,那分歧又是如何产生的呢?

我想说一个自己亲身经历的事情。

这里的领导特指技术部门的领导

我的工作日记

10月18日9:30am

收到一方需求

10月22日 1:30pm

参加了功能点确认会

10月23日-10月30日

收集需求

第一次会议

11月3日

方案一 提交

11月5日 第一稿讨论会议

第二次会议

11月6日方案二产生了!

11月9日带着方案一和方案二再次参加需求讨论会

第三次会议

11月10日

第三稿第四稿

为了能够更快的通过方案,我新做了两稿,并且优化前一稿

11月11日

开发提出异议,希望改成第四稿样式。

11月15日

开发发信至领导

信的内容大致为:无法按期完成现在样式,或者简化方案,或者需要延期。

11月15日2:30pm

领导正式确定要分两期来做中转项目,需要重新调整方案。

11月16日

项目经理正式邮件确定分两期的决定。

pk第一次

11月16日

第五稿

11月16日

开发再次提出异议,希望更精简。

11月16日

项目经理调解,无果,问领导,领导同意开发方案。

11月17日

调整第六稿

PK第二次

11月17日4:30pm

业务提出异议,业务领导要求开会

第四次会议

11月23日

方案七

11月23日

领导质疑方案七强化方案。

11月24日

业务方妥协,最终定稿。

最后一次PK

11月30日

设计评审

12月1日

Final稿确定,而其实final稿就是方案二。