一、什么是业务?设计师为什么学业务?学到什么程度?

业务=行业+事务,或商业+任务。即为了达成某一商业目标需要执行的任务或工作项。业务是SE的专项看家本领,那么设计师为什么学习业务?设计的本质是为了更好的解决问题,我们通过调研了解用户,经过设计后优化解决方案。比如不了解业务调研,无从设置访谈脚本,受访者的问题也很难回答,我初次外出调研访谈,用户多问几个问题我就懵了。实地观察时难看全用户操作,而了解业务后,用户每一步操作都很清楚,可以马上记录多余的行为。另,UCD设计师如何能迅速赢得SE和开发的尊重,个人以为想要赢得尊重就在对方擅长的领域比他更擅长,帮助他们解决难题,至少与SE、开发在同一对话频率上,便于推行设计方案。总而言之,了解业务是解决问题的基础,也是沟通顺畅的利器。

业务学习的三个层次

如业务是地基,那么设计师学业务需要跟SE一样吗?术业有专攻个人认为分几个层次,单页面级业务流程落实到每个字段与按钮的细节上,系统级的理解到角色与信息架构级,每个功能的网状联系,是否便捷,有没有更好的方法。行业级的更多是战略层,不具备行业级业务知识也可以搬好份内砖。假若体验成熟度需攀升,设计师需多了解行业动态。

二、怎么学业务?

方法一:角色场景法

UCD方法论

设计师学业务无非是为了帮助用户解决问题,那么前提是了解用户,明白什么人,什么时候什么地点他在想什么,他完成业务目标的时候有什么诉求,目前还有什么痛点。一般应用于系统改造项目组提供调研资源时,此时有机会接触真实用户,绘制用户体验地图更真实。

方法二:看问画结

业务学习四法宝

(1)看

观察系统,导航结构、界面布局、文字字段。有哪些菜单?不同用户角色是否有不同界面布局?有什么字段,哪些字段最重要,字段显示顺序是否体现了重要等级(B端旧系统很难通过界面体现这点)?这界面在表达什么内容。每个字段直接是否有联系,操作选项是否明显?

(2)问

问自己,用户拿到这些信息后会怎么想?根据这个页面提供的信息是否足够用户做决策判断?顺序是否表达正确?用户使用该业务时处于什么环境中?问SE/开发/专家,日常版本SE获取第一手需求,他们是最清楚用户的人,如何能让SE传达更真切,建议面聊。比如需求文档写场景背景:“领导要求做x功能,为了集中化管理开发这功能”。这冰冷的文字很难让你理解用户如何工作,文字询问SE具体场景,更容易得到:“看需求文档,没什么特别的,客户只说要这功能,其他我也不知道”。而面聊效果则会变成:“客户就坐在客户经理边上,填完单据马上联系审核人审核,快速填单后马上签协议。”SE经验丰富熟悉业务,在他看来功能如何搭建最重要,需求文档少有细节描述,闲聊两句说出来比组织文字容易的多。而对于UCD来说,用户环境是用户如何使用系统至关重要的信息。

(3)画

梳理人物场景用户故事,将自己理解人物形象与诉求简单的画出来列出来,处理多角色交互系统时更清晰,个人习惯使用axure画,便于与原型对应,通常与原型一起展示,方案讲解时更有说服力。

简易线框分析

画流程图,需求文档都有业务流程图通常包括业务与后台数据交互流程,我更多以用户操作流为主重新画流程。若设计到流程优化会将前后两流程一起比较优劣。当业务过程复杂时,画流程图是梳理的最好方法。学习业务与优化业务流程同步进行。

(4)总结

将复杂的业务用其他生活场景类比,也可以理解为是找概念模型。或以自己的话来阐述业务。用三句话阐述,再甚用一句话精炼总结。

方法三:其他提升业务思考的方式

一些小心得:

体验真实系统,找到专家询问,抓住任何机会去实地调研,根据以上方法整理总结。不管哪种方法都脱离不了,他是谁,他在哪,他去哪,5w1h刨根问底的问,形成习惯日积月累,渐渐的我们设计师也可以学会业务。自己琢磨琢磨业务比较耗时,如果与专家们打成一片,找到项目总结文档或面基10分钟,会事半功倍哦。

三、不同行业学习方法有什么差别?

财务类、建筑类、税务类、运营商任务类、B端与C端,每一类业务都有他自己的注意事项。我理解法律法规与日常劳作类业务存在差别,比如法律法规不可变更,日常任务类可以创新。有些业务效率至上,有些安全至上,有些准确至上,而C端体验至上。

我把这些都理解为产品姿态,可以看作行业潜规则,学习业务试着去找这些潜规则,从整体上把握业务的调性。设计师和工程师一样像个螺丝钉可以装订到不同的行业中,适应性佳。但需做个不可或缺的螺丝钉或许可选择在某个行业深耕。