SAP发布的用户研究趋势是建立在成熟的用研系统之上的趋势分析,面向的读者也必须具备用户研究基本的理论体系,那么在数字产品的体验设计中,用研的目的是什么?它的输出物是什么样子?工作边界又在哪里呢?
要回答上述问题,首先需要了解“用户研究”出现的上下文,在关于交互式系统设计的原理中,普遍被认可和接受的设计过程包括四个阶段:研究问题域;理解用户及其需求;定义解决问题的框架;完善设计细节。这也是以Cooper和Nielsen等为代表的信息设计先驱创立的理论体系的基础。
早期的软件产品之所以晦涩难懂,产生不恰当,不友好的使用体验,很大部分原因是软件的实现模型和用户的心智模型不一致造成的,而软件的实现模型是基于开发商和制造者基于技术原理和科学方法创造的。希望程序员对用户,商业和技术一视同仁是不可能的,所以在产品的实现原型和用户的心智模型之间天然存在鸿沟。为了弥合这种鸿沟,改善产品的使用体验,交互式系统设计应运而生,逐渐发展成为一种新的学科,它的设计过程基本都遵循这上述的四个阶段。
交互式系统设计,或者说产品设计,在上世纪80年代,以Cooper为代表的学者认为“设计基于用户目标、业务需要和技术限制,提供真正意义的产品定义”,这种观点影响了信息设计的发展轨迹,它作为学科的发展,通过理论丰富和社会实践加持,已经完成了自身的进化和体系确立,在当下语境仍然适用。
简而言之,在产品设计中,为了弥合实现模型和心智模型的鸿沟,“用户研究”作为目标导向的设计过程中的一个环节,所代表的宗旨是“以用户为中心”的设计思想。
用户研究的目标是产品定义
新主语在产品设计中,采用的设计方法,理论体系上也是归属于上述范畴。即便是企业已经意识到对创建好的产品来说,用户体验非常重要,但在用户研究和其他设计过程的衔接上仍存在本质上的理解偏差,浩如烟海的调研数据不能轻易地转化为产品需求,无法将用户和最终产品联系在一起的设计过程,就导致了研究结果和最终设计方案之间存在差距。
研究问题域——理解用户及其需求——定义解决问题的框架——完善设计细节
在上述四大阶段中,“用户研究”属于第二个阶段,在这个阶段中涵盖了方法和目的,即通过理解“用户”和“需求”来进行产品定义。它的上游是产品的“问题域”,包含了“业务”“技术限制”“使用场景”等限制和支持产品的基本条件;下游直接面临的是产品的框架设计,也就是我们通俗说的“交互原型设计”,其次再是细节设计,即表层视觉设计。
基于这样的理论模型,我们将设计过程再具像和细分为:
用户研究——交互设计——视觉设计——可用性测试
而今天我们谈到设计中的用户研究,指的就是这个过程中的用户研究。这个模型,如果再进行细分,可行的方法是将“用户研究”拆分为:用户及其问题域研究;用户模型建立和需求定义。由此我们可以先回答问题的一部分,即用户研究的工作边界在“产品定义”的输出。
明确了用户研究的工作边界,还需要再次阐明两个问题:1.用户研究的主体是谁?2.产品定义的标准是什么?
优秀的设计师同时也是用户调研高手
用户研究的主体是谁?也就是谁来执行用户研究?传统的做法是调研者调研,设计师设计,而有效的设计过程中这两个主体是不应该发生变化的,如果在调研结果和设计结果之间缺乏系统的方法进行转换,那就必须要设计师成为调研的高手,否则实现模型和心智模型之间的鸿沟还是无法消除,因为设计表现最终决定着产品的成败。在复杂的交互系统设计中,设计师一旦能提供产品定义,那么设计师将需要承担比传统设计更广泛的责任。即设计为结果负责!
产品定义需要平衡用户要求、业务需求和技术需求
有很多时候,在我们执行的产品设计中,经常会出现如下类似的情景,企业拿出一份格式为excel的功能清单,告诉设计师这是我们的需求,请进行设计;或者直接拿出一份简陋的交互原型(框架定义)要求进行设计。在设计师的角度,这份需求能不能支撑第二阶段的原型设计或者第三阶段的表层设计,是需要评估的,多数时候这样的产品定义都是无效的或者不充分的。这种情况就是对“产品定义”概念不清晰造成的。
有效的产品定义一定是能够直接进行交互框架定义转换的,而且是平衡了用户要求、业务需求和技术需求的。简单的用户要求,局部的业务需求和技术需求或者三者无效的拼凑都不能够进行更高层次的交互框架转化。所以说在上述情况下,设计师拿着企业提供的功能清单进行交互框架转化时,显得无从下手不得不从头开始再次进行用户研究寻找产品定义。
所以即便是企业拿着一份功能清单来进行设计咨询或者要求直接展开设计工作时,设计师也一定要分辨它是不是有效的产品定义。这样说并不是否定企业或者需求方进行产品定义的努力,这个过程还是必要的,只是在这个基础之上,设计师还是需要再次进行用户研究,以便理解,验证,补充更有效地产品定义。
如若转载,请注明出处:https://www.hyqwgl.com/8116.html