编辑导语：B端的走查过程需要看各项指标数据以及业务、组件等是否搭配得当，同时也是对许久为参与的项目产品进行一致性的修改，并整理出一套可行并且规范的标准，用于应对后续新的设计。本文对设计走查过程进行了一个详细的梳理，一起来看看。
前言：B端的走查过程和C端差异的比较明显，看数据、看业务、看操作，看组件是否搭配得当。从设计角度来看，结合交互，结合部分的业务需求、业务场景去来完成这个过程。
需要对长久未参与的项目产品进行一致性的修改。也借此做一次设计走查，整理出一套合适的规范标准需要设计、开发遵循，来应对新的需求。
搞清楚几个问题：
以真实内容说明这个问题。
参与的项目，开发到现在两年了，持续迭代中，目前阶段处于平稳迭代中。平稳期间开始做走查任务。
原因：初期项目开发，业务复杂，场景变化多，现成的前端框架能够满足需求，后续的项目推进，加入更多的场景，更多的需求，前端被迫忽略了组件规范要求。
目前：操作上出现的问题也越来越多，控件套用，体验上的问题也显著出现。比如说标签导航，也用作按钮功能；切换筛查标签也当作按钮使用了
对小公司来说，做走查不是件容易的事，所以只能边走边看，边修改边完善。
通过和产品进行一个小时的讨论，主要有以下几点：
希望设计给出一个标准化的规范指导界限，明确哪些内容应该怎么做，做到什么程度。尽可能避免一些操作上的问题。
所见即所得，引起大家共识，明白哪里的问题。
把所有不合适的，不准确的页面截图，找出来，合集到一块，再对这些截图进行分类，并配相应的文字说明。
一定要找全类型问题，一定要，一定要，重要事说三遍。
只有问题找全才能更全面解决好问题。
找问题的方式，等同于设计组件前期的对所有问题组件的归纳分类。
找完问题后需要对这些问题进行分类，从两个角度考虑：
一是从数据组件的分级（即组件的应用）；二是从业务的核心度，将涉及主流业务打上标签，便于优先处理；三是考虑扩展性，数据是动态的，所以在边走查边考量扩展性。
这里不对数据组件进行特别的说明，组件从设计规范的时候就已经有完整的交互样式了，但在走查表中也要标识出来。组件不能满足的业务需要的才会增加新的组件。
走查主要从操作业务流程出发，检查组件应用的合理性，即组件是否满足场景需求。
带着业务场景去操作一遍，通用的方式，了解主流程，操作分流程，分流程完成了，主流程不会断。
整理操作依据表（业务相关的，还是由产品出）。
对于查找出的问题，也将其区分等级：
紧急：数据丢失、缺失，功能不可用，按钮点击无反应；
严重：功能设计与需求严重不符，数据结果错误，程序接口调用错误等；
一般：功能未实现但不影响使用，操作时间长，数据字段过长，页面样式（页面布局不规范、显示重叠、不该显示不隐藏、描述不清，晦涩难懂未注释、默认提示不准确、文字排列不对齐、光标图标寓意不正确）；
次要：建议问题，不影响使用，只是体验差点；
与之相对应的处理等级是紧急处理、优先处理、一般处理、暂不处理。
找茬小分队的人员分配。
产品主要找紧急与严重等级的，设计主要找一般和次要的以及部分严重等级的。其他人根据上边的表格查找流程的问题。将体验出的问题以表格内容记录下来，并给这些问题标记路径、等级和处理等级，以及修改建议。并将重复内容合并。
之后将开发（前端+后端）也拉出来，展开一次会议讨论，将问题处理人指派到人。
建立一套规范切切实实的让组成员遵守规则。也通过每一次的总结，将每一次的任务内容沉淀下来。
本文由 @Ychen（啊呜計） 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于 CC0 协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。