关于APP开发的可用性设计原则

APP开发或者网站开发，如何才能让用户获得更可用的体验，这就是可用性设计需要思考的问题。下面我们来讨论一下，在移动时代，APP开发如何提高产品的可用性。

让设计团队和潜在用户直接接触，而不是通过中介人或一个综合检查。特别是在第一阶段，要收集用户想要完成什么，什么是没有意义的，以及信息架构和系统导航在多大程度上符合用户期望的信息。关键任务分析是一种有效理解用户在软件或网站上想要完成的关键任务的方法。

 

第一次就把事情做好是一个不错的目标，但经验告诉我们事情并没有听上去那么简单。如果你有测试15个用户的预算，最好是将这15个用户拆分为3组。第一轮测试5个用户，解决那些没有争议或不会造成新问题的问题，然后再次测试。

 

许多研发团队可能遵循了前两条原则但对测量却犹豫不决。从每一轮的测试中得到一些关键的可用性指标能够为你的设计决策提供简单的客观评估。低保真原型和变化任务(changing tasks)并不是不用测量的借口。除了完成率，也有其他用于测量从迭代设计中得到的产品改善的指标。

 

我们在三个月的时间内对一个iPad应用进行了三轮测试。在每轮测试中，我们让5-6名参与者尝试一系列任务。每个任务完成后我们会要求参与者在7点量表上评价任务的困难度(我们会在口头上询问)。在第一轮测试中，原型基本上可用，但我们仍然发现了导航和标签的一些问题。下图显示了在85%的置信度水平上每轮测试的平均分。

 

尽管我们在每轮测试中用到的任务会有所变化，但有三个任务在每轮的测试中是一样的，有5个任务在两轮的测试中式一样的。

 

除了任务层次的测量，你也可以在不同阶段测量对整个APP体验的感知。Bangor等人介绍了一个在每个阶段都是用系统可用性量表(System Usability Scale，SUS)进行测量的迭代设计的例子。下图显示了他们在五轮测试中得到的数据，以及基于以往数据的68分的基准平均得分。

 

如果你不想追踪其他数据，你可以测量每轮测试中发现的可用性问题的频次和严重性。这些也能够衡量产品的改善。我们更关注关键问题相对于全部问题的比率而不是全部问题的大体数量。

 

这样做的原因在于我们经常在每轮测试中发现同样数量的总体问题数量。当界面改善时，问题变得更细微。在一些例子中，当关键问题解决后，用户也能够进一步通过任务来发现更多的问题。

 

总的来说，在APP开发和设计时要提前关注用户和任务、实证测量和迭代设计，这样才能让用户获得更可用的体验，提升APP的可用性。