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