可用性评估建议 - 图1
    为了验证产品的用户可用性,团队常常会开发出较为完整的交互设计稿或者开发出MVP原型供用户测试。往往这时候,团队已经投入了大量精力去设计和开发产品,对于to B的产品而言,产品交付也迫在眉睫。因此,用户测试之后只会对一些较小的页面逻辑和元素进行调整,而不太可能会进行较大的架构变动。即使是这个阶段的用户测试发现产品有严重问题,如由于不可避免的偶然因素导致重要商业流程理解缺失,从而导致的产品逻辑架构不合理,基本也不太可能去修复了。因此,在前期的架构阶段就引入较为全面的可用性评估就显得非常必要。以下是在没有完善的交互模型甚至没有高保真的UI界面时,进行可用性评估的三点建议:

    1. 准备阶段:厘清产品架构,确保不遗漏重要核心功能

      1. 和团队项目负责人一起,向客户高层了解产品商业目的和愿景。这个项目是为了解决什么问题?希望收获什么?有哪些重要的评估和交付节点?产品上线后供哪些用户角色使用?他们分别有什么需求?
      2. 向不同用户角色,如操作者,管理员等了解传统细节工作流,以前是怎么做的?使用哪些工具?与该项任务相关的其他工作有哪些?完成一项任务有什么要求?之前最麻烦的地方在哪里?希望做出的改进有哪些?
      3. 团队各位负责人一起拟定产品核心商业价值,用户角色定位,绘制商业工作流,确定MVP阶段核心功能
    2. 构思阶段:组织专家可用性测试,整合产品功能和架构

      1. 集合多位设计师,在介绍产品商业背景和工作流程之后根据各自的理解分别绘制心智模型和页面架构图,同时抽离出竞品的页面架构图,放在一起分析比对不同方案的优缺点,采用poker card形式甄选整合出最佳页面架构方案
    3. 界面设计阶段:测试页面可理解程度

      1. 寻找不了解商业背景的用户,提供本产品和竞品高保真样稿,测试其理解程度: 觉得这个页面是做什么的?如何理解每一个区域的功能?如何进入下一步?下个页面/操作可能是什么样子的?是否有撤销操作的意愿?有哪些担忧?是否可以找到撤销方式?最喜欢哪个产品的设计稿?为什么?