时间: 2021-07-30 09:50:30 人气: 8 评论: 0
上篇《B端与C端的设计价值差异分析》写到如何串联业务流程解决实际问题是B端设计重点。进入新项目组4个月被开发经理称**为业务专家，在各类面向客户的培训演讲中，以业务专家角色在现场解答问题。那么设计师应该怎么学习业务？
业务=行业+事务，或商业+任务。即为了达成某一商业目标需要执行的任务或工作项。业务是SE的专项看家本领，那么设计师为什么学习业务？设计的本质是为了更好的解决问题，我们通过调研了解用户，经过设计后优化解决方案。比如不了解业务调研，无从设置访谈脚本，受访者的问题也很难回答，我初次外出调研访谈，用户多问几个问题我就懵了。实地观察时难看全用户操作，而了解业务后，用户每一步操作都很清楚，可以马上记录多余的行为。另，UCD设计师如何能迅速赢得SE和开发的尊重，个人以为想要赢得尊重就在对方擅长的领域比他更擅长，帮助他们解决难题，至少与SE、开发在同一对话频率上，便于推行设计方案。总而言之，了解业务是解决问题的基础，也是沟通顺畅的利器。
业务学习的三个层次
如业务是地基，那么设计师学业务需要跟SE一样吗？术业有专攻个人认为分几个层次，单页面级业务流程落实到每个字段与按钮的细节上，系统级的理解到角色与信息架构级，每个功能的网状联系，是否便捷，有没有更好的方法。行业级的更多是战略层，不具备行业级业务知识也可以搬好份内**。假若体验成熟度需攀升，设计师需多了解行业动态。
UCD方法论
设计师学业务无非是为了帮助用户解决问题，那么前提是了解用户，明白什么人，什么时候什么地点他在想什么，他完成业务目标的时候有什么诉求，目前还有什么痛点。一般应用于系统改造项目组提供调研资源时，此时有机**接触真实用户，绘制用户体验地图更真实。
业务学习四法宝
（1）看
观察系统，导航结构、界面布局、文字字段。有哪些菜单？不同用户角色是否有不同界面布局？有什么字段，哪些字段最重要，字段显示顺序是否体现了重要等级（B端旧系统很难通过界面体现这点）？这界面在表达什么内容。每个字段直接是否有联系，操作选项是否明显？
（2）问
问自己，用户拿到这些信息后**怎么想？根据这个页面提供的信息是否足够用户做决策判断？顺序是否表达正确？用户使用该业务时处于什么环境中？问SE/开发/专家，日常版本SE获取第一手需求，他们是最清楚用户的人，如何能让SE传达更真切，建议面聊。比如需求文档写场景背景：“领导要求做x功能，为了集中化管理开发这功能”。这冰冷的文字很难让你理解用户如何工作，文字询问SE具体场景，更容易得到：“看需求文档，没什么特别的，客户只说要这功能，其他我也不知道”。而面聊效果则**变成：“客户就坐在客户经理边上，填完单据马上联系审核人审核，快速填单后马上签协议。”SE经验丰富熟悉业务，在他看来功能如何搭建最重要，需求文档少有细节描述，闲聊两句说出来比组织文字容易的多。而对于UCD来说，用户环境是用户如何使用系统至关重要的信息。
（3）画
梳理人物场景用户故事，将自己理解人物形象与诉求简单的画出来列出来，处理多角色交互系统时更清晰，个人习惯使用axure画，便于与原型对应，通常与原型一起展示，方案讲解时更有说服力。
简易线框分析
画流程图，需求文档都有业务流程图通常包括业务与后台数据交互流程，我更多以用户操作流为主重新画流程。若设计到流程优化**将前后两流程一起比较优劣。当业务过程复杂时，画流程图是梳理的最好方法。学习业务与优化业务流程同步进行。
（4）总结
将复杂的业务用其他生活场景类比，也可以理解为是找概念模型。或以自己的话来阐述业务。用三句话阐述，再甚用一句话精炼总结。
一些小心得：
体验真实系统，找到专家询问，抓住任何机**去实地调研，根据以上方法整理总结。不管哪种方法都脱离不了，他是谁，他在哪，他去哪，5w1h刨根问底的问，形成习惯日积月累，渐渐的我们设计师也可以学**业务。自己琢磨琢磨业务比较耗时，如果与专家们打成一**，找到项目总结文档或面基10分钟，**事半功倍哦。
财务类、建筑类、税务类、运营商任务类、B端与C端，每一类业务都有他自己的注意事项。我理解法律法规与日常劳作类业务存在差别，比如法律法规不可变更，日常任务类可以创新。有些业务效率至上，有些安全至上，有些准确至上，而C端体验至上。
我把这些都理解为产品姿态，可以看作行业潜规则，学习业务试着去找这些潜规则，从整体上把握业务的调性。设计师和工程师一样像个螺丝钉可以装订到不同的行业中，适应性佳。但需做个不可或缺的螺丝钉或许可选择在某个行业深耕。
作者：兰哥2018
来源：https://www.jianshu.com/p/fa0da2d625b4
本文由 @兰哥2018 授权发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自 Pexels，基于 CC0 协议
