步盖房法端产品设计调研攻略

　　如果说把 ToB 系统的设计过程比喻成盖房子，那么我们需要几个大步骤呢？
　　作者：Yeriss
　　公众号：UXRen
　　设计师接手新的 ToB 类产品时，面对陌生的业务、大量信息，服务对象从＂用户＂转变到＂客户＂等问题，往往在一开始感到无从下手。
　　究竟应该从哪里入手呢？怎样剥茧抽丝地了解业务，发现问题，做到有据可循的设计呢？
　　如果说把 ToB 系统的设计过程比喻成盖房子，那么我们需要几个大步骤：
　　勘测环境：理解业务实质
　　绘制蓝图：找准当期项目目标
　　准备建材：调研搜集素材
　　打好地基：鉴别信息、发现关联和痛点
　　搭建筋骨：信息架构
　　建设动线和空间：主任务流、关键页面
　　完善细节：界面打磨
　　一、环境：理解业务实质
　　为什么有必要理解业务？
　　不懂业务会出现两大问题：
　　首先，影响沟通。项目调研和设计执行过程中，都需要和业务方需求方大量沟通。不懂业务，自然会遇到障碍，甚至影响客户或业务方对设计师专业性和设计能力的评价。
　　其次，不理解业务的情况下，制定出来的设计目标，可能不贴合业务，隔靴搔痒。项目做完，有可能发现设计关注点和业务关注点靠不上，局限在设计语境一亩三分地里面做优化，有时候在业务方看来，这就是做了＂无用功＂。
　　为了避免脱离业务做设计，我们究竟应该了解哪些信息呢？
　　理解业务，需要看什么？
　　该业务是为了解决什么问题而存在的；
　　关键衡量指标；
　　主要知识框架。
　　了解知识框架不是为了全都学懂学通，后面第四步，我们会介绍如何在有限的时间内，把握信息颗粒度。
　　还可以看什么？
　　行业里面有哪些参与方或角色
　　不同角色提供的价值是什么
　　资金、产品、信息流向的链条
　　为了达成自身业务目标关键资源和能力
　　通过理解业务，我们可能从中得到什么？
　　可能是＂数据看板＂页面一个报表
　　可能是＂表单＂页面信息优先级设计依据
　　可能是系统的评估指标
　　可能是对关键操作角色KPI的理解
　　可能是整个系统设计导向的依据
　　怎么做？
　　通过搜索引擎、专业书籍阅读、行业专家、内行人的交流，可以获得以上信息。也可以向团队内业务岗位同事交流请教。
　　如果是与外部客户合作，不一定有条件充分的沟通。这时可以利用项目前期沟通的机会，在对方做项目背景介绍时，记下关键问题，或找合适的场合少量提问。
　　二、制蓝图：找准当期项目目标
　　第二步，是考虑当期项目的主要目标，也就是要解决的主要问题；划定设计范围，可以业务模块层面拆分；还需要尝试寻找具体切入点，可能是业务链中的某个小环节。
　　另外，还需要注意项目目标和范围要和需求方、业务方讨论核对。
　　为什么要和需求方、业务方核对目标？
　　一方面，和需求方核对目标和范围，有助于控制预期，增加设计参与感。另一方面，尽量让目标贴合实际业务，不局限于设计语境。
　　为什么有必要圈定范围？
　　遇到人力有限，时间有限是项目的常态，尤其 ToB 业务通常业务链比较复杂，任务繁重。如果是从零到一的项目，初立项项目，还会同时面临开发资源平衡、团队磨合、客户信任的问题。
　　理想化的设计路径里面，当然没有这些障碍或意外，然而现实中的意外总比剧本还更有想象力。分拆小模块限定设计范围的做法，无论是试水合作、分工任务、还是减少早期信息的压力都会有帮助。
　　怎么做？
　　梳理清楚全局业务模块
　　搞清楚当前业务方预期
　　粗颗粒度评估各个模块、痛点优先级
　　沟通并圈定设计范围
　　不能做到明确限定设计范围的时候，也一定要能尽量分拆。分拆从粗到细，从大颗粒度的业务模块分拆，到可独立出来的小功能集群的分拆。
　　三、备建材：调研搜集素材
　　在 ToB 项目中，我们作为＂外行＂＂新手＂，很有必要通过定性研究的手段，去做一轮信息搜集，解决一些＂是什么＂和＂为什么＂的问题。
　　这时候，访谈或其他方式的定性研究应该怎么做呢？
　　访谈对象，应该了解谁？
　　系统管理和负责人；
　　业务参与角色（直接操作系统/不操作）；
　　价值决策者。
　　首先，对系统负责人、用户反馈负责人、系统专家这类角色访谈，能快速帮我们了解系统的操作方法，历史问题，关键角色等等。
　　我们可以基于这类＂经验用户＂、＂专家＂访谈对要设计的系统有一个大致的认识，尽量建立起来一个整体的框架。
　　接下来，对业务中各类角色进行的访谈。需要注意的是，尽量覆盖业务流转中的各类参与角色，按业务环节选择被访角色，无论操作系统与否（当然，不直接操作系统的角色，访谈用户量可以酌情减少）。因为我们一开始要做的，是对整个业务链有所了解。具体的，我们了解他们的工作场景，任务，操作细节，观念态度等等，和 ToC 的访谈其实差异也不算太大。
　　另外，对价值决策者的访谈，不一定有机会直接聊。对于这个角色，我们访谈的目的，主要还是为了验证确认 STEP1 当中，我们了解到的关键价值，是否和决策者心中预期相符，避免在设计优化方向上跑偏太远。
　　常规且必要的访谈主题有哪些？
　　组织结构；
　　每个角色的工作目标；
　　工作主线任务链；
　　系统内主线任务链；
　　关键表单信息分组、优先级；
　　细节专题访谈。
　　和 C 端项目的差异之处在于，End-user 的行动动机一部分来自于组织运作目标。因此，B 类系统业务所涉及任务链当中的关键业务组织的结构、运作方式、合作关系、业务目标，是早期访谈中的首要关注问题。不见得占访谈多大篇幅，但这部分内容能帮我们解释，在这个组织中各种角色行为的动机。
　　接下来需要了解每个角色的工作目标，日常任务，如以每年、每季度、每月、每周、每天为单位，在用户心目中工作分为哪些模块，工作量如何，面对什么类型的任务……换句话说，是了解用户的工作心理模型，他如何描述、划分、解释他所面对的任务，关心什么样的事情，有什么KPI。
　　还需对关键业务活动更具体的了解，可以是按照线性、时间关系、因果关系的一系列描述。尤其注意，此处了解不应局限于系统内的活动，应该是顺着工作任务出发去了解。
　　在这个环节，最开始可能我们的访谈像是在跟访谈对象＂学习业务＂，逐渐熟悉之后，才能慢慢的找出规律，澄清，简化，解读，描述用户视角里面的工作任务链。
　　关于用户和软件或系统互动方面，了解系统内的主线任务历程，相关的分工方式，信息传递，决策点，评价方式。另外，还有有必要了解系统在用户工作中所占重要性和比例，了解系统的整体感受，遇到问题，尤其还需要关注，替代物和辅助工具使用，它们会反映界面信息展示和功能设计问题。
　　接着是关键页面中的信息分组和优先级问题，这里需要了解在一些关键页面的用户对信息使用和展示需求。了解的方式，既可以是在任务链中穿插了解任务中的信息诉求，也可能是专题的做卡片分类，从用户角度看这些信息分组和使用的方式。
　　最后是一些设计专题的问题，例如复杂的信息传递需求，特殊的展示页面，新的一些功能或设计设想的验证。以及需求方附带希望了解的，在前面访谈主线中没有覆盖到的问题。
　　需要注意的是，这些访谈主题并非针对所有用户在访谈中平均出现，而是在早期访谈中，可以先了解组织架构，工作职责等，后续对任务操作，设计细节多安排一些。
　　其他需要同步调研/讨论的常规课题：
　　信息架构的调研涉及导航设计
　　信息对象的分类和范围问题涉及信息分类、筛选功能、查询功能设计
　　功能命名澄清涉及界面信息可理解性优化
　　设计专题一些难点设计环节的专题讨论
　　Tips（一些容易出现的问题）：
　　（1）误以为自己了解用户如何使用产品
　　最容易出现的是，大家并未充分理解用户任务，或产品功能，却已经陷入设计争论。比如我所经历的产品优化项目，菜单已经超过几百个，包括产品经理，都没办法说清楚每个功能大概是做什么的，这种情况下我们一上来就考虑菜单怎么排布优化思路，是不解决问题的。
　　（2）害怕了解专业术语，认为学习成本高
　　这里提供一个技巧。其实我们理解业务的目的只是为了做界面设计，支撑好用户的操作需要和信息需要，而不是代替用户工作。那么我们对用户专业知识的掌握程度，可以先达到对＂操作＂的理解，在早期可能就已经够用了。我举一些例子，你可能就明白到底如何达到对操作的理解。
　　我们尝试这样＂解读＂业务行为：用户现在在做什么？
　　他查找某个信息，还是比对、判断、传递、发送、检查、选择、创作录入内容、登记信息、打开文档、切换文档、寻找信息、等待、获知。比起用户做＂预算方案＂，＂诊断病人病情＂这样的任务描述，更加通识的、操作化的描述，更容易让我们了解用户的＂操作需要＂，也更容易和各种背景的团队成员形成讨论。
　　当然，业务化的描述更容易让人理解前后逻辑，操作化描述则是对于我们做行动、任务、操作需要的分析和设计有一点帮助。
　　（3）信息量大，头疼
　　ToB 业务特点除了＂专业性强＂之外，还常常伴有＂信息量大＂的特点。这个时候我们能做的一种朴素的应对方式，是分类和分组，是运用金字塔原则，是概括和简化。比如：某几十个信息点，是用户用来做＂决策＂的＂参考信息＂，另一些几十个，是需要＂传递＂给下一步操作角色的业务信息。如果有必要，也可以再往下继续分层分组的去梳理。
　　（4）颗粒度问题
　　无论是描述任务，信息分层我们都面临＂颗粒度＂把握问题，这个问题没有一概而论的方法和答案，我这里暂且提供几个思路。例如，从＂分类原则＂出发，尽量运用MECE原则，多做尝试；借鉴业务颗粒度，业务本身有既定的信息逻辑，它的分类颗粒度有借鉴意义；还可以考虑，按应用场景需要来掌握颗粒度。
　　看分类好的信息是用来做导航设计，还是主任务链设计，还是表单信息设计。需要注意的是，要区分究竟是颗粒度出了问题，还是信息块的命名本身就不精准，存在理解问题。语义理解出了问题，再怎么挪腾信息块的位置，结果也可想而知。
　　（5）无法直接访谈，缺少访谈资源和渠道
　　例如遇到高层角色访谈约不到，可以从项目的负责人侧面了解观点，或参与项目时间较长的同事有时候也能提供一些信息。另外，有一些我们需要的信息，在项目以往的规划、介绍文档中，可以尝试从这里了解。
　　（6）关于业务的访谈，很难开口，担心显得自己外行
　　访谈对话关系中其实有很多种，面对＂业务专家＂的访谈姿态本身就可以采取＂请教＂的姿态。另外，为了避免自己过于外行导致话题进行不下去，所以前面几步的准备工作和访谈框架的建立和随时调整也很重要。（访谈课题和因素框架怎么调整，也是个挺有意思的话题，有机会我们再展开聊。）
　　（7）平均安排所有的内容在每个访谈里
　　如果这么做，你会发现你的访谈无限的被拉长。另外，有一些问题并不适合询问所有角色，甚至不适宜以访谈的方式获得。用户可能负责不同的业务模块，所以访谈的内容会有差异和侧重。如果时间充分，你可以每类角色都安排够最小样本量，但通常情况下时间、样本资源都有限，只能做些取舍。
　　四、打地基：鉴别信息、发现关联和痛点
　　在前面几步过程中，我们实际上一直都在获取各式各样的信息，这时我们需要清晰的展示搜集到的关键信息，尽量简要的澄清它们之间的关联。如：
　　业务构成/关系图，展示业务模块关系；
　　工作流程图，展示用户工作历程；
　　体验地图，呈现用户具体任务/行动过程；
　　利益人关系图，呈现用户组织关系/相关系统关系；
　　业务指标澄清；
　　系统和关联系统的配合关系。
　　还需要进一步澄清细化目标、痛点，找切入点，也就是搞清楚问题、冲突、未被满足的需求的所在：
　　对业务痛点的澄清；
　　对当期改进目标的不同角色不同观点澄清；
　　用户使用历程中的阶段感受；
　　用户的痛点、未满足目的需要、操作需要；
　　澄清相关影响因素。
　　实际工作中，这一步鉴别信息发现关联，和前面三步不是割裂的，而是在前面几步工作当中持续进行的。我们不断构建对业务认知的同时，也以相对结构化和图形化的形式澄清这些内容，帮助我们在接下来的工作中，更好的和团队中的其他人一起理解用户，讨论方案。
　　通过这种方式，对搜集到的信息简化概括，不断更新对项目的认知，阶段输出调研产出物。
　　这里再介绍一个小技巧，可以用PPT，一页列一个主题，从调研开始到最后，持续更新，复盘自己对信息掌握的程度，随时调整，有的放矢。这也会减少漫无边际发散，一定程度上控制重复调研，能提升调研效率。
　　有了前面1-4步的工作，实际上传统意义的用研工作算是告一段落。下面的步骤里，设计工作比重大量增加，我也尽量以自己有限的经验来尝试说明前面用研工作结果在后续设计过程里的落脚点。
　　五、筋骨：信息架构设计或优化
　　我们已经在前面的研究中尝试分析的系统的分类方式和范畴，具体到系统信息结构设计，这里介绍一些补充的经验工具。
　　一般而言，我们有几种组织信息，拆分一个系统的方式。按业务范畴拆分，按任务历程，按功能模组拆分系统，按不同角色拆分系统。不同的情形可能需要选择和组合不同的信息架构组织方式。
　　常见的拆分的优先顺序经验是：业务范畴>核心任务历程>功能模组。按用户角色拆分前台页面的信息架构要视情况而定，从系统复杂度和维护难度考虑，一些情况并不推荐这种划分。
　　如果是局部优化项目，不涉及整体的信息架构调整，只需要为新的功能在信息架构中找到合适的归宿。
　　如果是改版项目，我们可以用几个简单快速的方式入手。首先，试着从业务的角度尝试对过去的菜单做信息分类，某个菜单是属于＂xxxx＂任务里面的里一个子功能，还是＂xxxx＂工作里面的一个信息入口。找到归属与错误范畴的信息，是可做的调整的第一步。
　　其次，是看功能菜单的使用频率，还有用户的关注和使用情况。
　　在用户心目中，一些功能菜单意味着什么，某个菜单条目，是他闭着眼睛都会点进去的，还是打入冷宫从没想着要用一次的，或是他压根看不懂的？打开从用户视角的聚光灯，去观察哪些条目被聚焦，哪些已经在无数的迭代中被遗忘蒙尘，它们很可能就是用户定位功能时候的干扰信息。
　　六、空间：主线任务、关键页面
　　对用户任务链条的澄清，需要有几个方面的充分描述，用户建立任务的动机和预期获得的结果，用户规划的行动路径，用户执行任务的具体操作，和用户评估行为效果的参考依据。这是用户的行动模型。
　　再用户行动过程中，每个步骤需要的操作需要和信息引导，以及后续的反馈是否充分，影响了用户行动是否能够顺利完成，以及过程中是否出错。
　　关键页面的信息展示设计，重点是满足用户的信息块的认知需要，减少用户认知负担，减少歧义。
　　通过前面的调研过程，以上信息都应该得到搜集，图形化产出，或是设计师直接参与调研有了更丰富的细节感知。理想情况下，我们对整体业务目标，还是用户任务链条、操作目标、痛点，都有了充分的了解。如果你拿不准具体的调研问题应该问什么，可以再从这里找找思路。
　　七、界面打磨和专题讨论
　　在设计中，总会遇到各式各样的问题。可能是宏观颗粒度的任务流程问题，也可能是权限拆分问题，或是具体的某个页面展示空间不足。
　　如果前期从任务，操作需求，信息诉求教的研究仍然不充分，还有可能在细节设计阶段补充调查，比如对某个特殊设计页面的方案选择和试用体验。此时，可能是短平快的可用性测试，原型程度的A/B Test。
　　最后
　　要得到好的调研产出，还会遇到种种问题和情况，简单罗列几个。
　　基础分析能力出了问题？虽然看清楚了上面的步骤，但是仍然做不出东西，或者感觉混乱，可能是分析能力不足，需要专门做训练或学习，还可能需要想办法更熟悉假设、验证是怎么做的。
　　业务分析出了问题？如果不知道价值，业务分析怎么做，应该补充一些商科知识，市场营销，运营管理、企业战略、财务等。同时，也可以看一些市场分析报告，行业报告。
　　业务设计与规划问题？如果调研一番后，发现业务本身出了问题，有的情况超出了设计角色能工作的范围，通常情况下，一两个设计师的声音难以推动巨大改变。这时候最好是智取、取巧，项目从一两个关键的问题页面出发，做相对独立的功能或小模块优化，解决一两个实际问题。建立信任后再找机会逐步分析和澄清问题，解决问题。
　　项目中，任何问题都有可能出现，很多问题都有可能导致项目的失败。我们也需要建立的预期是，不是调研做充分了，项目就一定能成功，客观的心态去看清楚面对的问题究竟是什么，才更有可能好好的面对、解决。
　　回顾一下七个调研设计步骤：
　　勘测环境：理解业务实质
　　绘制蓝图：找准当期项目目标
　　准备建材：调研搜集素材
　　打好地基：鉴别信息、发现关联和痛点
　　搭建筋骨：信息架构
　　设计动线和空间：主任务流、关键页面
　　完善细节：界面打磨和专题讨论
　　以上就是我在ToB设计调研中的一些工作经验。通过这样一轮信息搜集、倾听、分析、梳理，无论用研来支持设计师执行，还是设计师自己执行，它都让我们在做设计决定时心里更踏实，更有把握，感到有源可据。在我的工作之中，ToB调研设计不是难啃枯燥的硬骨头，而是不断解密、拼图的有趣过程，也是富有艺术和挑战＂建筑＂之旅。
　　本文仅是个人经验之谈，错漏之处请不吝赐教。我相信真正有价值的洞察来自于实际工作体会，也来自于不断交流迭代。