前段日子团队在做A项目，产品给出需求后，交互根据PRD设计出demo，最后与开发团队评审时，开发提出：这个项目与之前一个B项目的功能点类似，且目前开发团队正在进行代码整合的工作，因此要求产品按照B项目现有框架重新整理需求并重新设计。
当时三方争执不下：
产品方：你不能因为要整合你的代码框架而篡改我的需求，需求是市场考量后提的，都是用户需要的功能点。
开发方：在功能点相同的情况下，且考虑到代码的复用性，必须将现有需求嵌套到之前的项目框架中。而且，功能不搭边的，可以往原有的框架上面靠啊！
设计方：需求是产品给到大家评审的，一开始在设计前，如果开发有特殊需求，要复用项目框架，为什么不一开始就和产品、设计强调这个事情？现在都已经设计完了，又要重新来过不是浪费人力吗？况且，AB两个项目的最终用户还是有区别的，嵌套了B的框架，A的某些功能将会弱化，这样的产品是否真正是用户需要的？
开发方：你怎么知道用户需要不需要？你能代表用户吗？谁能代表用户？我们谁都不能代表用户！我们推出B项目的时候，没有用户反馈不好用啊！所以不管怎么样，先用同一套框架，等用户提出意见，反馈了哪里不好的时候，再进行修改！
当时场面死寂一片，众人相顾无言。
看，我们甚至都不知道我们的用户究竟是何许人也，就一腔热血地做这做那，而我们做的这些最后是否能抓住用户的心，在我们不好好了解用户之前，我们一无所知。
再举个通俗的例子，C君告诉室友们自己爱慕一个在图书馆认真学习的妹子，于是男同胞们纷纷出招，每天要去图书馆为妹子占座，带早饭，陪她一起做试卷，上自习，C君为与妹子一起争取奖学金获得荣耀熬的双眼通红，最终妹子与一个长相帅气的男孩子牵手成功了。好好学习重要吗？重要啊！但是妹子喜欢的是啥？划重点：妹子喜欢美男子啊！所以，不懂女孩的心思，怎么可能追上女孩呢？
作为一个设计师，在设计过程中或多或少地会考虑如下问题：用户是谁？用户究竟想要什么？如何设计出为用户所用的产品？他们企图去了解用户，然而大多数设计出来的产品，最终往往会抛弃用户，而是变成了老板心里想要的产品。
为什么？
1.产品设计前有市场来给出产品的需求，市场根据其敏锐的“嗅觉”对产品定位，设想出一款能迅速在市场推动，且创造最大的利润的产品。根据他们经过市场调查后，根据猜测与总结。然而事实上，在调研时，他们更注重产品的功能细节或者是否有需要弥补功能缺陷的地方。而且，用户往往反馈的是，他们要买什么样的产品，并未阐明他们如何使用，或者是否会使用这种产品，很少有用户能够清晰地描述自己的需求。
2.产品从需求到落地的最终过程，不可缺少的中流砥柱是开发人员，他们负责产品的构造过程，决定了最终会构造出怎样的产品。但是整个项目对开发人员的评判标准，在于他们是否能解决技术难题，是否如期完成任务。他们需要在易于编程和易于使用之间做出决定。而且，他们往往收到不完整的指示，缺乏远见，甚至自相矛盾的，在时间有限的要求下，他们被迫做出事关用户体验的重要决定——砍去某些功能或选择更快捷的实现方式。
3.我们往往忽视真实的用户，不过好在，现在绝大部分产品都是在不太了解用户的情况下制造出来的。所以，把握用户心理，知道他们为什么会选择我们的产品而非竞争对手的，取悦他们，抓住他们的心，尤为重要。我们会设计出又漂亮又时尚的篮子，却没有意识到他们只想要一个买菜的菜篮。
所以在设计之前，大家只是去臆想自己的用户，而缺乏对用户真正的了解与研究，甚至会为了追求效率，开发出用户理解、使用起来费劲不已的产品，这样设计的产品始终不具竞争力。
因此，研究你的目标用户至关重要，并在合适的时机（开发周期的合适阶段）采取合适的手段（技术），既能避免时间浪费、资源浪费，而最终产品将能最高程度地达到用户预期值和满足开发组织需求。
最近在读《交互设计精髓 4》，有一种相见恨晚的感觉。在不断学习的过程对工作中遇到的问题进行思考总结，让自己不断进步起来的同时，让自己更加专业。
