... how do you test how easily accessible your user-interface is?
With usability tests.
Basically, you grab a bunch of your friends (because you won't have any money to encourage strangers to participate) give them the documentation a new user would have and ask them to perform the system's key use cases.
Ideally, you want your test users to have at least some of the qualities of your target users, so if your system is aimed at a technical audience then your classmates will work; however, if your system is aimed at the general public then you're going to want to get your friends in Arts, Human Kinetics, etc. to participate.
So how do you turn that into requirements? You identify your key use cases and stipulate what how usable should they be (walk-up usable, a few minutes with the documentation, real actual training...) and then verify that your test subjects can complete the use cases without too much frustration, with the right amount of training, in a reasonable time.
Try to define usability in terms of "test-able" requirements.
You already gave yourself the answer, because usability can be described in terms of requirements like "an entry should be deleted in less then 100ms after the initial call".
What makes a user interface 86% intuitive? This can’t be answered without some form of measurement. You need to ask what features can make a user interface intuitive. Talk to the customer and the potential future users. Gather features (or better dig for them!), which would make working with the piece of software easier.
Maybe you get a list of features like:
The department’s organization must be shown in a hierarchical tree view.
In this tree view drag & drop must be possible.
The font size must be configurable and saved for each user.
On the top of the screen there must be a list of important links. Each user may configure and save his own personal list.
...
Make requirements out of these features. They are “testable” and thus “measureable”. If in the acceptance tests it turns out that 17 out of 20 features are working, you have 85% success.
EDIT: This works in a project environment, where you need to deliver measurements (like in many commercial projects). If you have a "softer" form of project environment where not everybody is poking on figures, then sticking too much on this formalism may be counterproductive since flexibility and agility may suffer from this.
I would advise you against quantifying usability requirements. The problem is not so much that you can't define metrics. You could say, for instance, that
it should take a person not longer than x seconds to find y on the site, or
the conversion rate of the store has to be higher than z%
etc etc
The problem is rather that you have to spend time and resources on finding acceptable target values for your metrics that you can actually reach. What is an acceptable time to find a piece of content?
发布评论
评论（3）
通过可用性测试。
基本上，你找了一群朋友（因为你没有钱鼓励陌生人参与）给他们新用户将拥有的文档，并要求他们执行系统的关键用例。
理想情况下，您希望您的测试用户至少具有目标用户的某些品质，因此，如果您的系统针对技术受众，那么您的同学就会工作； 但是，如果您的系统面向公众，那么您将希望让艺术、人类动力学等领域的朋友参与其中。
那么如何将其转化为需求呢？ 您确定您的关键用例并规定它们的可用性（直接可用，几分钟的文档，真正的实际培训......），然后验证您的测试对象可以完成用例而不会遇到太多挫折，在合理的时间内进行适量的训练。
With usability tests.
Basically, you grab a bunch of your friends (because you won't have any money to encourage strangers to participate) give them the documentation a new user would have and ask them to perform the system's key use cases.
Ideally, you want your test users to have at least some of the qualities of your target users, so if your system is aimed at a technical audience then your classmates will work; however, if your system is aimed at the general public then you're going to want to get your friends in Arts, Human Kinetics, etc. to participate.
So how do you turn that into requirements? You identify your key use cases and stipulate what how usable should they be (walk-up usable, a few minutes with the documentation, real actual training...) and then verify that your test subjects can complete the use cases without too much frustration, with the right amount of training, in a reasonable time.
尝试根据“可测试”需求来定义可用性。
您已经给了自己答案，因为可用性可以用“在初始调用后 100 毫秒内删除条目”之类的要求来描述。
是什么让用户界面变得 86% 直观？ 如果没有某种形式的测量，就无法回答这个问题。 您需要询问哪些功能可以使用户界面变得直观。 与客户和潜在的未来用户交谈。 收集功能（或者更好地挖掘它们！），这将使该软件的使用变得更容易。
也许您会得到如下功能列表：
显示在分层树视图中。
可能的。
可配置并为每个用户保存。
是重要链接的列表。 每个
用户可以配置并保存自己的
个人名单。
根据这些功能提出要求。 它们是“可测试的”，因此是“可测量的”。 如果在验收测试中 20 个功能中的 17 个功能正常，那么您就成功了 85%。
编辑：这适用于项目环境，您需要在其中提供测量（就像在许多商业项目中一样）。 如果您有一个“较软”形式的项目环境，其中并非每个人都在研究数字，那么过多地坚持这种形式主义可能会适得其反，因为灵活性和敏捷性可能会受到影响。
Try to define usability in terms of "test-able" requirements.
You already gave yourself the answer, because usability can be described in terms of requirements like "an entry should be deleted in less then 100ms after the initial call".
What makes a user interface 86% intuitive? This can’t be answered without some form of measurement. You need to ask what features can make a user interface intuitive. Talk to the customer and the potential future users. Gather features (or better dig for them!), which would make working with the piece of software easier.
Maybe you get a list of features like:
shown in a hierarchical tree view.
possible.
configurable and saved for each user.
be a list of important links. Each
user may configure and save his own
personal list.
Make requirements out of these features. They are “testable” and thus “measureable”. If in the acceptance tests it turns out that 17 out of 20 features are working, you have 85% success.
EDIT: This works in a project environment, where you need to deliver measurements (like in many commercial projects). If you have a "softer" form of project environment where not everybody is poking on figures, then sticking too much on this formalism may be counterproductive since flexibility and agility may suffer from this.
我建议您不要量化可用性需求。 问题不在于您无法定义指标。 例如，您可以说，
问题是您必须花费为您的指标找到实际可以达到的可接受的目标值的时间和资源。 查找内容的可接受时间是多少？
I would advise you against quantifying usability requirements. The problem is not so much that you can't define metrics. You could say, for instance, that
The problem is rather that you have to spend time and resources on finding acceptable target values for your metrics that you can actually reach. What is an acceptable time to find a piece of content?