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

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

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

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

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

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

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

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

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

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

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