Custom Voice
Microsoft Azure Cognitive Service

自定义语音Microsoft Azure 认知服务

PERIOD
Nov 2017 to Feb 2018

MY ROLE
UX & UI Designer

DESIGN PEERS
Yue Huang

Microsoft Cognitive Services (formerly Project Oxford) are AI + Machine Learning projects provided by Microsoft Azure, which are a set of APIs, SDKs, and services available to developers to make their applications more intelligent, engaging, and discoverable.

Custom Voice is one of the most important projects under Cognitive Services. Users can create their own customized voice model by Custom Voice. This is a first-of-a-kind product in the market. And I was very lucky to be involved in this product design process and helped create it from zero to one.

Microsoft Cognitive Services（原 Project Oxford）是 Microsoft Azure 提供的 AI + 机器学习项目，是一组 API、SDK 和服务，可供开发人员使用，使他们的应用程序更加智能、更具吸引力和可发现性。

自定义语音是认知服务下最重要的项目之一。 用户可通过自定义语音创建自己的自定义语音模型。 这是市场上首创的产品。 我很幸运能参与到这个产品设计过程中，并帮助它从零到一创建。

What is Custom Voice? 什么是自定义语音？

A new service that enables users to create their Text-To-Speech (TTS) voice models. It is a first-of-a-kind product in the market. You can upload your recordings with the corresponding script into the platform to help you train your voice model.

这是一项全新的服务，使用户能够创建他们的文本到语音 (TTS) 语音模型。 它是市场上首创的产品。 您可以使用相应的脚本将录音上传到平台，以帮助您训练语音模型。

Why Custom Voice? 为什么要自定义语音？

The existing open-source voice model in the market is minimal, which cannot meet every product’s needs. For example, many companies want a recognizable voice of their own. But creating a customized voice model by a third party costs too much money.

市场上现有的开源语音模型很少，无法满足每个产品的需求。 例如，许多公司想要自己的可识别声音，但是由第三方创建定制的语音模型成本太高。

Target User 目标用户

The teams and companies who are developing the TTS-based product.

开发基于 TTS 的产品的团队和公司。

Product Goal 产品目标

Enable users to smoothly create, train and deploy a good quality voice model quickly to the application.

使用户顺利地创建、训练高质量的语音模型并将其快速部署到应用程序中。

Clear and Simple User Flow
清晰简单的用户流程

It is a brand-new area, and users may not be familiar with the flow. Also, like the material requirement, we want the user to learn it quickly and easily. So It’s important to design a clear and simple flow, so they can get to know the platform faster.

这是一个全新的领域，用户可能并不熟悉流程。 此外，正如要求中说的一样，我们希望用户能够快速轻松地学习。 所以设计一个清晰简单的流程很重要，这样他们才能更快地了解平台。

Understand The Platform 了解平台

Background: Before we get to know the platform, there is an online demo that presents all the functions we have right now and a UX proposal deck from the PM.

Although there is a demo and a proposal from the PM, we find the flow very complex and hard to understand, don’t even think about finding problems. So we need to figure out how to understand the platform faster, and that’s when we started to summarize the main product scenarios.

And that helped a lot! We printed out every step of the flow, then paste them right on the wall to see the whole picture. So we were finally using different columns to classify different scenarios.

Finally, we successfully understood the platform, went through the processes in each scenario, and tried to find out all the problems of the existing platform by all these scenarios, problems of the existing platform by all these scenarios.

背景：在我们了解该平台之前，有一个在线演示，展示了我们现在拥有的所有功能，以及来自 PM 的 UX 提案。

虽然有一个demo和PM的提案，但是我们仍然觉得流程很复杂，很难理解，根本不用考虑找问题。 所以我们需要弄清楚如何更快地了解平台，这就是我们开始总结主要产品场景的时候。

这帮助很大！ 我们打印出流程的每一步，然后将它们贴在墙上以查看整个画面。 所以我们最终使用不同的列来对不同的场景进行分类。

最后，我们成功地了解了平台，把每个场景的流程都做了一遍，并试图通过所有这些场景找出现有平台的所有问题。

Problem Research 问题研究

Since we already have the expected mockup provided by the PM, also, the mockup helped us understand the platform, so we just naturally followed the scenario we divided. We were thinking about how to find all the problems in each system, then perfect the flows.

But soon, it doesn't work well because it's easy to get distracted by many branch flows. Also, when we think in each scenario, it's hard to have holistic thinking of the product. Hard to find if some steps are missing or duplicate.

So we failed to find the problems at this stage. But we soon realized that maybe we don't need to find the issues of the current process but to design a whole new approach based on the product goal.

由于我们已经有了PM提供的预期模型，而且模型也帮助我们了解了平台，所以我们很自然地按照我们划分的场景进行操作。 我们在思考如何找到每个系统中的所有问题，然后完善流程。

但很快就发现它不能很好地工作，因为它很容易被许多分支流分心。 此外，当我们在每个场景中思考时，很难对产品进行整体思考。 很难找到某些步骤是否丢失或重复。

所以我们现阶段没能发现问题。 但我们很快意识到，也许我们不需要找到当前流程的问题，而是根据产品目标设计一种全新的方法。

01 List All Involved Tasks
列出所有涉及的任务

So we changed our direction and get rid of the scenario but list all involved tasks together as the first step of redesigning the whole workflow.

所以我们改变了方向，摆脱了场景，而是将所有涉及的任务一起列出来作为重新设计整个工作流程的第一步。

02 Clear The Main Flow
摸清主线流程

We ignored some low-priority tasks, picked out the essential actions in all the functions, and finally listed the main flow.

我们忽略了一些低优先级的任务，在所有功能中挑出必要的操作，最后列出了主要流程。

03 Highlight All Touchpoints
突出所有关键触点

After we list out the main flow, we highlighted the touchpoints to see any duplicated or redundant steps.

在列出主要流程后，我们突出显示了关键触点，以查看是否有任何重复或冗余的步骤。

04 Summarize Workflow
总结工作流程

Finally, we lock down the main workflow and summarize all the paper mockup information into the computer.

最后，我们锁定主要工作流程，然后将所有纸样模型信息汇总到计算机中。

Quick Lo-fi Prototype Iteration

快速低保真原型迭代

An efficient design tool can help a lot in this part. We used Balsamiq as the lo-fi creator, then import images into InVision to do the prototype. The cost is meager so that the iteration could be straightforward and fast, so we could learn quickly and leap forward. Also, it’s very convenient for us to communicate with PM, devs, and two test users that we invited. After several versions of the lo-fi test and iteration, we finally lock down the lo-fi mockup.

一个高效的设计工具可以在这部分提供很多帮助。 我们使用 Balsamiq 作为 lo-fi 创建者，然后将图像导入 InVision 来做原型。 成本微薄，因此迭代可以直接快速，因此我们可以快速学习并实现飞跃。 此外，我们与 PM、开发人员和我们邀请的两个测试用户交流非常方便。 经过几个版本的低保真测试和迭代，我们终于锁定了低保真模型。

Hi-fi

高保真

We started thinking about the visual style while designing the first version of lo-fi, came up with several proposals, then decided on the visual direction. After we locked down the lo-fi mockup, we started to conclude the most-used components in the mockup and then created the pattern library first in Sketch to faster the hi-fi process.

After the first version of the hi-fi design, we instantly created the new prototype and delivered it to our internal team to see the reaction. Well, we sure got a lot of helpful feedback from our colleagues. So then, we shifted the second design to the test users. And based on all the feedback, we did several other iterations on the visual design and finally lockdown.

我们在设计 lo-fi 的第一个版本时就开始考虑视觉风格，提出了几个建议，然后决定了视觉方向。 在我们锁定 lo-fi 模型后，我们开始总结模型中最常用的组件，然后首先在 Sketch 中创建模式库以加快 hi-fi 过程。

在 Hi-Fi 设计的第一个版本之后，我们立即创建了新原型并将其交付给我们的内部团队以查看反应。 嗯，我们确实从同事那里得到了很多有用的反馈。 因此，我们将第二个设计转移给了测试用户。 根据所有反馈，我们对视觉设计进行了几次其他迭代，最终锁定。

Learning

经验总结

Focus on the main task 专注于主要任务

After understanding the scenario, we started to think about how to improve flow in each design. Soon, we found it doesn't work well because it's easy to get distracted by many branch flows. For example, when we think about the flow in the "Uploading scenario," we are stuck a long time bulking multiple files and indicating to users if they upload the wrong file type. Indeed, they are the case we should consider, but it's too early to think about all matters at an early stage.

So we change our direction and get rid of the scenario but list all tasks together. Then we can list the main functions and rearrange everything, get rid of the duplicated.

在了解了场景之后，我们开始思考如何在每个设计中改进流程。 很快，我们发现它不能很好地工作，因为它很容易被许多分支流分心。 例如，当我们考虑“上传场景”中的流程时，我们被困了很长时间批量处理多个文件并向用户指示他们是否上传了错误的文件类型。 的确，它们是我们应该考虑的情况，但是在早期阶段考虑所有问题还为时过早。

因此，我们改变了方向并摆脱了场景，但将所有任务一起列出。 然后我们可以列出主要功能并重新排列所有内容，摆脱重复。

Prototype faster, feedback faster, design better
原型更快，反馈更快，更好的设计

Our first mockup started from the “paper and pen sketch,” The first time we presented our prototype to our colleagues was the first version of the lo-fi design. The flow still needs to be polished, and the mockup looks very rough. But we can’t just sit there and guess about the result. We want to build the habit of testing, give to other people as soon as possible, and get feedback faster to lead us to the next design step.

Another benefit about prototyping faster is that we can spot problems quickly and fix them. The earlier you find the problem, the easier it is to change it. Accurate pixels are not easy to get. Imagine if we wait until the hi-fi mockup came up then give it to the actual customers, it will be tough to change anything by that time.

我们的第一个模型从“纸笔草图”开始，我们第一次向同事展示我们的原型是低保真设计的第一个版本。 流程还需要打磨，样机看起来很粗糙。 但我们不能只是坐在那里猜测结果。 我们希望养成测试的习惯，尽快提供给其他人，并更快地获得反馈以引导我们进入下一个设计步骤。

更快地进行原型设计的另一个好处是我们可以快速发现问题并修复它们。 越早发现问题，就越容易改变。 准确的像素不容易获得。 想象一下，如果我们等到高保真模型出现后再将其提供给实际客户，到那时将很难改变任何东西。