没有活动混音器设备可用_案例研究：可用性测试混音器

没有活动混音器设备可用

In a previous blog post, “Testing the Audio Mixer”, the Audio Mixer was discussed from a Software Test Engineering point of view. In this blog post we will pick up where we left off: involving real users in evaluating a system in development.

在以前的博客文章 “测试音频混合器”中 ，从软件测试工程的角度讨论了音频混合器。 在这篇博客文章中，我们将继续讨论：让真正的用户参与评估开发中的系统。

In the Summer and Fall of 2014, we, Stine Kjærbøll (User Experience Team Lead) and Nevin Eronde (User Experience Researcher), ran three rounds of usability testing sessions with audio designers/composers from the local games industry in Copenhagen.

在2014年夏季和秋季，我们分别由StineKjærbøll(用户体验团队负责人)和Nevin Eronde(用户体验研究员)与来自哥本哈根当地游戏行业的音频设计师/作曲家进行了三轮可用性测试。

The users that we recruited for usability testing had backgrounds in games and  art installations. They were:

我们招募来进行可用性测试的用户具有游戏和美术装置的背景。 他们是：

• Audio programmers

  音频程序员

• The “One-Man Army” (programmer/artist/audio designer)

  “一个人的军队”( 程序员/艺术家 /音频设计师)

• Composers

  作曲家

• Sound designers

  声音设计师

• Audio-visual artists

  视听艺术家

大声思考协议–吸引实际用户 (Think Aloud Protocol – Involving real users)

The Think Aloud Protocol is a user research method that involves test subjects thinking aloud as they are performing a set of specified tasks. The test subjects are encouraged to say whatever they are thinking, doing and feeling as they are performing the tasks.

“大声思考协议”是一种用户研究方法，涉及到 大多数 受试者 在执行一组指定任务时大声思考。 鼓励测试对象在执行任务时说出他们的想法，行为和感觉。

We wanted to perform the Think Aloud test was for several reasons:

我们 之所以要执行Think Aloud测试，有几个原因：

• The Audio Mixer is designed for a target audience that ranges from people who are programming experts and people who have never even opened a script. Would those audio designers, who are not comfortable with scripting, be able to use the Audio Mixer without the the help of a programmer? To what extent?

  音频混音器专为目标受众设计，包括编程专家和从未打开过脚本的人们。 那些不习惯脚本编写的音频设计师是否可以在没有程序员帮助的情况下使用音频混音器？ 到什么程度？

• Having an Audio Mixer inside of a game development tool is a new concept in itself. Would users understand the concepts of Snapshots, Ducking Volume, Audio Groups and Audio Sources?

  在游戏开发工具中包含一个混音器本身就是一个新概念。 用户会理解快照，回避音量，音频组和音频源的概念吗？

• Unity editor workflow with references from 3rd party DAW (Digital Audio Workstation) tools. Would the Audio Mixer and its concepts be easy to use for an audio designer that is working with other types of DAWs?

  Unity编辑器工作流程，包含来自第三方DAW(数字音频工作站)工具的参考。 对于与其他类型的DAW一起工作的音频设计师来说，混音器及其概念是否易于使用？

• Would they understand the concept of tweaking audio effects at runtime?

  他们会理解在运行时调整音频效果的概念吗？

All of our user research is confidential, but this Kids React video is pretty close to how a Think Aloud session can look like:

我们所有的用户研究都是机密的，但此Kids React视频非常类似于Think Aloud会话的样子：

演示地址

开发过程中的偏见 (Biases during development)

Another reason why we conducted Think Aloud Protocols was to avoid our own biases. Whenever you are testing, researching and designing a feature, you can not avoid biases, but you can be aware of them.

我们执行“大声思考协议”的另一个原因是为了避免我们自己的偏见。 每当您测试，研究和设计功能时，都无法避免偏差，但是您可以意识到它们。

Some of the biases we were aware of with regards to the Audio Mixer as well as the users that we recruited from the local games industry were:

我们意识到与音频混音器以及我们从本地游戏行业招募的用户有关的一些偏见是：

• Test Subjects were working on smaller computer game productions

  测试对象正在从事较小的计算机游戏产品

• We could not invite audio designers working on large AAA-scale games,since such studios are scarce to come by in the Copenhagen area

  我们不能邀请从事大型AAA级游戏的音频设计师， 因为这样的工作室很少出现在哥本哈根地区

• The QA testing that had been done on the Audio Mixer was with specific DAWs in mind

  在Audio Mixer上进行的QA测试考虑了特定的DAW

• Lastly, our own familiarity  with the Audio Mixer meant that  we were biased with regards to naming conventions and how the system functioned.

  最后，我们对音频混音器的熟悉意味着在命名约定和系统运行方式方面存在偏见。

This is also where usability testing gets interesting! With the above research questions and biases in mind, we started designing the test.

这也是可用性测试变得有趣的地方！ 考虑到以上研究问题和偏见，我们开始设计测试。

设计测试 (Designing the Test)

When designing usability tests, you always have to make a decision whether to go for realism, abstraction or something in between. If we had designed a test that used a large Unity project, such as Bootcamp or Angry Bots, that could count as  a realistic test scenario, but the complexity of the project might be overwhelming for a test subject unfamiliar with the project. S/he would end up spending a lot of time familiarizing themselves with the project instead of focusing on the Audio Mixer. The Audio Mixer itself is an extensive system, so we decided to go for a minimalist test setup, to avoid any added complexity.

在设计可用性测试时，您始终必须决定是否要求实，抽象或介于两者之间。 如果我们设计的测试使用了一个大型的Unity项目，例如Bootcamp或Angry Bots，则可以算作现实的测试方案，但是对于不熟悉该项目的测试对象，该项目的复杂性可能会使其不堪重负。 他/她最终将花费大量时间来熟悉该项目，而不是专注于Audio Mixer。 音频混音器本身是一个扩展系统，因此我们决定采用最低限度的测试设置，以避免增加任何复杂性。

We used a scene with a Red Cube and Blue Cube. All the sound files that were needed were provided in a folder. Not a real life scenario, but the complexity is removed, so the test subject could focus on the tasks.

我们使用了 带有红色立方体和蓝色立方体 的场景 。 文件夹中提供了所有需要的声音文件。 这不是现实生活中的情况，而是消除了复杂性，因此测试对象可以专注于任务。

The tasks of the test subjects were to:

测试对象的任务是：

• Build up an ambience in the scene

  在现场营造氛围

• Trigger Snapshots

  触发快照

• Trigger Ducking Volume

  触发回避音量

• Explore the Audio Mixer effects and Send/Receive units

  探索音频混音器效果和发送/接收单元

大声思考协议期间吸取的教训 (Lessons learned during Think Aloud Protocol)

When conducting Think Aloud Protocols, it is always an interesting study in interaction design. We learned many lessons and below are a few examples:

在进行“大声思考”协议时，它始终是交互设计中有趣的研究。 我们吸取了很多教训，以下是一些示例：

您认为“显而易见”的内容对用户而言并不明显 (What you think is “obvious” is not obvious to the user)

The “Edit in Play Mode” button is a very useful feature for audio designers, as it enables them to tweak and adjust sounds at runtime. In a very eary prototype, the button was labelled as “Edit Snapshots”. Technically, this is what you are doing when enabling the button and adjusting the Audio Mixer settings at runtime. The problem was that the test subjects did not interpret the “Edit Snapshots” button as a natural part of their workflow. They ignored the button, simply because they did not intuitively associate it with the ability to edit the Audio Mixer settings at runtime. The button was then renamed to “Edit in Play mode”. We ran a new round of Think Aloud tests and from those tests we could verify that it was more intuitive for our test subjects to enable the “Edit in Play mode” button, as they now interpreted the button label as a part of their workflow.

“在播放模式下编辑”按钮对于音频设计师来说是非常有用的功能，因为它使他们能够在运行时调整和调整声音。 在非常简单的原型中，该按钮被标记为“编辑快照”。 从技术上讲，这是在运行时启用按钮并调整音频混合器设置时要执行的操作。 问题在于测试对象没有将“编辑快照”按钮解释为他们工作流程的自然组成部分。 他们忽略了按钮，只是因为他们没有在运行时直观地将其与编辑音频混音器设置相关联。 然后将按钮重命名为“在播放模式下编辑”。 我们 进行了新一轮的Think Aloud测试，通过这些测试，我们可以验证测试对象启用“在播放模式下编辑”按钮更为直观，因为他们现在将按钮标签解释为工作流程的一部分。

简单与复杂   (Simplicity versus complexity )

When developing features we often think of how to make the feature simple to use for our users, whether the user is advanced or a new user. One thing we observed during usability testing of the Audio Mixer was that in some cases users wanted the complexity. In the first version of the Ducking Volume, the feature had very few parameters for the user to tweak. The test subjects expressed that “something was missing”. We learned that audio designers are actually used to the complexity of multiple parameters that they can adjust and tweak from the DAWs. A feature with very few parameters was suddenly a complex thing to understand.

在开发功能部件时，我们经常想到如何使该功能部件易于用户使用，无论是高级用户还是新用户。 我们在音频混合器的可用性测试过程中观察到的一件事是，在某些情况下，用户 希望 获得复杂性。 在Ducking Volume的第一个版本中，该功能只有很少的参数可供用户调整。 测试对象表示“缺少某些东西”。 我们了解到，音频设计师实际上已经习惯了可以通过DAW调整和调整的多个参数的复杂性。 具有很少参数的功能突然变得很难理解。

Below is an early design example of the Ducking Volume.

以下是Ducking Volume的早期设计示例。

After the feedback from our test subjects, the Ducking Volume was redesigned to a sidechained compressor with parameters and controls that the test subjects are used to from DAWs.

在我们的测试对象反馈之后 ，将Ducking Volume重新设计为侧链压缩机，其中包含测试对象习惯于DAW的参数和控件。

开始了解你！ (Getting to know you!)

All the feedback that we get from our users is so valuable to us! We, the User Experience Team, want to get closer to you! Meet us at Unite Europe 2015 in Amsterdam and help us make Unity even better!

我们从用户那里获得的所有反馈对我们来说都是如此宝贵！ 我们，用户体验团队，希望与您更加接近！ 在阿姆斯特丹的 2015欧洲团结 大会上与我们会面， 并帮助我们使Unity变得更好！

翻译自: https://blogs.unity3d.com/2015/05/11/case-study-usability-testing-the-audio-mixer/

没有活动混音器设备可用