DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for 7 Best Guidelines for Designing Voice-User Interfaces (VUIs)
Zulfiqar Anees
Zulfiqar Anees

Posted on

7 Best Guidelines for Designing Voice-User Interfaces (VUIs)

To create great voice-user interfaces, keep these important guidelines in mind.

Voice-user interfaces (VUIs) allow users to communicate with machines solely through their voices. To enable users to do some tasks, they use speech recognition and natural-language processing. VUIs have long been a staple of science fiction films, but recent advancements in the field have made them a daily reality.

When it comes to building voice-user interfaces, follows seven key design principles from TechKnowable.

1. Identify essential user responsibilities.

Why should people utilize your product? What are the goals they intend to achieve with it? Those are the two most important concerns to address before beginning to develop your product.

The ultimate goal of VUI design is to produce a product that is meaningfully integrated into the lives of consumers. That's why, early in the design process, you should invest in user research to learn about your target audience's needs. To learn about user behavior, perform user interviews and participant observation. Understand how users currently interact with your product and identify a set of tasks that could be useful for voice interactions.

2. Recognize the usage context

It's crucial to consider not only how, but also where, users will interact with your product. Will it be a personal place, such as a living room, or a public space, such as a hotel lobby? Sound quality (which is a combination of microphone quality, distance from a device, and background noise) and user privacy (users are less likely to divulge private information when speaking in public locations) will have an impact on your product design selections.

3. Create a dialogue flow

A dialog flow is a script that depicts the user's interaction with a voice-based product in the context of the user's specific task. A dialog flow is generally depicted as a tree, with all branches representing various scenarios in which the conversation could take place. Because dialog flow will almost certainly effect your development, you should specify it early in the product design process.

Outlining an example conversation should always be the first step in designing a dialog flow. This dialog depicts a happy route interaction with a system (where everything goes as intended and users achieve their goal) and does not include any branches or back-and-forth scenarios. As you learn new circumstances for your dialog, add more branches.

4. Create interactions that don't require the use of your eyes.

Voice-user interfaces are intended for those who have their eyes and hands occupied with other tasks. Consider a man who is preparing dinner and getting his hands dirty. To learn a recipe, he uses voice UI. For example, a woman driving along a busy street wants to know where the closest parking spot is. Even if your voice-based product has a screen, you should aim to create an app that doesn't require you to look at it.

5. Create a design that reflects how people actually communicate.

A discussion with a robot should not feel like interacting with a voice-user interface. Because users do not need to learn anything new to communicate with a system, the more natural the interaction is, the better the user experience will be.

Here are some ideas to help you create more human conversations:

  • Design with the user's vocabulary in mind. Learn as much as you can about the language that your users use on a regular basis and include it into your product.
  • Think about all the different ways you could say something (how the user phrases a command). It's amazing how many various ways people can beg for something. When we wish to know the weather, for example, some users may question, "How is the weather today?" while others may inquire, "Is it cold outside?"
  • Between inquiries and options, take a breather. When a system asks a user a question and provides them with options, it should pause for half a second after asking the question and then vocalize the options. This aids in the comprehension of information by users.

6. Be clear and concise.

When you compare graphical user interfaces (GUI) and voice user interfaces (VUI), you'll notice a significant difference: GUI allows for multitasking, but VUI is purely linear. Users can't bypass specific UI portions when interacting with VUI; they must listen to the information the system offers. Furthermore, users must remember information received from VUI, and the more information the system provides, the greater the cognitive load on the user. Designers, on the other hand, can improve users' lives by improving the information they receive from the system.

It's critical to limit the amount of data the system gives the user without diminishing its meaning. When a user asks, "How is the weather today?" for example. "The weather in your location, San Francisco, California, today, 20 December 2021, is 12 degrees Celsius, sunny, wind 3 kilometers per hour," the system can remark, or "12 degrees Celsius, it's a touch cold and windy outside, wear a coat." For users, the second response is more concise and clear.

7. Create a brand identity.

In voice-user interfaces, the tone of voice you use has a big impact on the user experience. Users intuit likeability in the initial seconds of hearing a voice when engaging with VUI. It's something that people do unintentionally. A brand persona is a collection of personality qualities and attitudes that your company communicates to its customers. If you don't establish a brand persona yourself, your consumers will, and the persona they generate may not be the same as the one you want to project.

Top comments (0)

Timeless DEV post...

How to write a kickass README

Arguably the single most important piece of documentation for any open source project is the README. A good README not only informs people what the project does and who it is for but also how they use and contribute to it.

If you write a README without sufficient explanation of what your project does or how people can use it then it pretty much defeats the purpose of being open source as other developers are less likely to engage with or contribute towards it.