我想大概文章会分两类：一类偏“术”，是做了什么、怎么做相关的，都是互联网同行的应该很熟悉，仅作我个人的流水账吧；另一类偏“道”，尝试说说自己工作中的一些思考，工作总是繁忙，生活诱惑太多，只能这样逼自己做一些总结。

说的是干点啥，也就是平时做的东西啦

一、作为交互设计师（我更愿意称呼为用户体验设计师），首要的是先了解自己产品的目标用户。我们会通过做用户调研来了解自己的用户或潜在用户，虽然名头是交互设计师，但是还是会帮着我们用研去做一些相关的调研以及后续的数据分析（我说我其实是为了去调戏用户妹子你信么）。有定量分析（问卷）也有定性分析（访谈），都蛮有意思。

一个有趣的现象是：非设计部门的同事大多会偏向两个极端：一种基本不相信用户研究得到结论，认为需求是无法通过询问用户得到的，最经典提到的是“福特&更快的马”的梗；另一种则认为用研结果及数据可以指导产品方向，以定量调研数据结果为导向直接进行改动。

这些都并非较好的看待用户研究这项工作的视角，我会找一段时间写写我自己和我看同事做调研的事情，让人们更好的了解用研到底是在做什么，不要再抱着用研就是“去做做问卷、抓个人到房间里问问我们哪里好哪里不好”这种诡异的想法了

二、交互设计的工作和项目进度是需要紧密相关的，因此日常工作的开头会从一个新项目启动，收到由产品经理提供的项目需求开始。可能是一个新增功能，也可能是功能的拓展，也可能只是旧有功能的优化，一般情况下我们会需要产品 or 运营提供对功能的简单说明、描述用户如何使用、期望达到什么效果。

当然，我会更多的从希望达到的结果/效果出发，反过去推应该如何满足用户的需求，与产品的考虑互相印证，是真的需要新增功能，还是我们对现有功能做一些优化即可满足。

另一方面，我们都会维护一份对自己负责的产品（基本每个交互会“供应”给某个主要跟进的项目，方便积累，如我这种什么都干过的是奇葩哈哈哈）的优化列表，里面会包含我们认为在体验上能够更加优化的点，在每个版本的收集需求阶段提供给产品：“大哥做这个呗~”虽然经常会被因为工作量的原因而砍掉一下，汗。

于是，我就会知道接下来大概一个月，我眼前需要的任务大概是哪些了。

三、在收到&确认需求后，我们会对提出针对性的交互和体验方案，会包含一些主要的可能界面以及主要的交互流程。过程中我们会从白纸/白板上画、快速讨论然后慢慢移动电脑软件上，制作一些简单的线框图，最后可能会产出约2、3个方案，视时间和项目优先级而调整。

方案会直接的体现用户是如何直接的使用这个功能和他/她获得的体验，在过程中我会不断的抱着白本或者电脑去骚扰产品经理以及研发，确认能达到产品经理的要求、现有开发技术能够满足、获得新灵感等等。

四、在基本完成所谓的“概念设计”后，对这个功能（或优化点）将以何种形态加入产品中，如何满足用户需求有比较明确的方案了，几个交互或视觉设计师会先聚起来进行讨论，通过不同方面去审视方案，集思广益。产品经理通常也会被我拉着在这个阶段参与进来，进行最后的确认。一个设计方案，一定不能自己好像憋大招一样，在最后的项目全组评审会议上才第一次露面，那下场太美我不敢看。

五、完善方案，将最后确定的主要方案进行细化，细节交互设计的方法我就不说了，考虑周全，这时会跟研发&测试同事更多的讨论确认，一方面用他们更加理性严谨、考虑程序实现的思维来审视方案的合理性以及可行性，另一方面也是给他们交底，对我期望做的事情有更好的预期。一些同事偶尔还会提出更加有效的解决办法，帮助完善方案，我们的研发小哥都棒棒哒！

细节设计的过程中，偶尔会设计一些不同的原型来进行对比测试，来得到最佳的交互流程方案，比如放一些不同的图到手机、甚至用flash做一些可交互的demo（向经常被我骚扰的前台和人力妹子们道歉！没有你们就没有我的今天！好像哪里不对...）。

六、接下来就是丧心病狂的需求评审了！整个项目组都会聚集起来听我宣讲方案。

其实如果在设计的整个前期过程都做的比较好，各方都对我的设计方案有一个大概的了解，需求评审只是相当于最后一个整体的宣讲以及确认会。如果没有在一开始就和大家沟通好，方案会在评审会上受到大量的judge，出现口水横飞的情况，既浪费了时间降低了工作效率，也不利于设计方案的推动。

七、接下来比较无趣的事情就出现了，在研发开始实现设计方案时，需要不断的进行跟进、确认效果，确认自己的方案能够完好无损的实现出来，这方面琐碎事很多，就不细写了。

一个设计的方案从收到需求、设计、实现、跟进、发布一直到用户手上都是全程处于提心吊胆的状态，生怕用户开喷需要发紧急版本去修复。当然也跟刚开始做交互没底气有关系，后面好多了，当偶尔能看到用户好评或者知道产品数据提升的时候还是很激动的，有种“我的努力让这么多人的生活更美好了那么一丢丢”的想法。这大概也是设计的魅力之一吧。