I have been working as a UX/UI Designer for almost 4 years now. One of my major duties in this role is running discovery workshops with clients. These workshops are an important part of the initial definition and planning phase when creating a digital product in every top software development company.
As you may know, there are numerous different types of workshops. Designers usually utilise well-known, common tools, designed to improve communications with various stakeholders. However, there are certain cases when a designer has to adjust workshop techniques to a specific product, in line with specific requirements, or even create new workshops. Here is a short story of how I once created and developed such a workshop tool from the ground up. A short story about a voice assistant.
Some time ago, I was asked to create a workshop tool that would enable comprehensive high-level communication with stakeholders, with the goal of defining a design scope for a voice assistant. The major challenge was to make sure that the tool was relatively simple to use by non-technical people. Our client, one of the largest insurance companies in Poland, requested a voice assistant whose main job was to sell insurance products to potential customers. As I soon found out, this solution was the first one of that kind on the Polish insurance market. Quite a challenge!
Assumptions
I got down to work and made some major assumptions:
- First of all, the tool that I was about to build had to facilitate communication between a client and a designer, so that they both felt they were on the same page during the workshop. When stakeholders realise that you are competent in your field, then the value of your service increases tenfold. It was crucial for me to design a tool that would prove I had the necessary skill set to design a voice assistant, and fulfill the client’s requirements.
- Visual interfaces and voice interfaces differ substantially. Voice conveys emotions and can tell us a lot about one’s personality. It evokes interaction and delivers additional information through tone, level of directness, and choice of words. Furthermore, due to the nature of the business (insurance), both written and spoken communication (known as “the tone of voice”) played a crucial role.
- Last but not least, the main goal when designing a voice assistant is to adjust its parameters to a potential customer’s requirements. Luckily, our client already knew and described such parameters in detail.
How could we accomplish all this with a simple, easy-to-use workshop tool? Well, I believed that VUI Canvas was the answer.
VUI Canvas
VUI Canvas is a tool that can be used for high-level design of a voice assistant. Canvas helps ask fundamental questions in a certain order, with the aim of figuring out the necessary requirements, before getting into the design and development phase.
Lets elaborate a bit on each of the fields that comprise the VUI canvas – starting with the name field.
Who am I?
Although it may not seem like the most essential component of the VUI canvas, the name field helps to build empathy towards your assistant. Let’s say we name our assistant George (I bet that just made you smile). You’d never imagine George as a heartless software agent powered by artificial intelligence, would you?
In this section, you should also define George’s age. Keep in mind that an agent’s voice can build trust, especially when we believe that the agent speaking with us is wise and experienced enough to provide sound advice.
What are the 3 reasons to have me?
When thinking about how George will interact with people, we have to take into account our potential customers’ expectations and needs. In this field, we should focus mostly on the value that George will bring to our users. Think about the goal that the end customers want to achieve or the tasks they need to accomplish. What kinds of problems do they have? How can we provide a solution for them?
What are the 3 reasons NOT to have me?
The last couple of years have utterly transformed voice technology. Yet, people’s mindsets do not evolve as fast; there are many users still unsure how to use voice assistants and prefer well-known solutions instead. While fighting old habits is pointless, we can at least try to encourage people to use voice assistants.
Therefore, in this field, we should list all the pain points, such as technical barriers or habits that our customers may have. Doing so makes it easier for us to build a proper and safe user experience solution for such users. Also, think about what happens if the assistant fails. What if he does not understand the user’s intention? Who would take over? Are there any backup solutions to this interaction?
The three questions above are related to potential users and focused on user expectations and goals. Now let’s go through the fields that will help set some requirements relating to George, our handy voice assistant.
Personality
This field doesn’t actually require much explanation. Here we should decide whether George is our friend, guide, salesman, or maybe an authority in a certain field? Think about the relationship he is going to have with customers. How often will they interact? Does George need to store information about each customer? How will he greet a customer every time they start a conversation?
Goals
Most of us have daily to-do lists to accomplish and so does our voice assistant! In this field, we need to define tasks and goals that George has to accomplish as an assistant. Let’s think about the complexity of his expertise – such as selling particular insurance policies, or redirecting the user to an agent in the right help center when needed.
Features
Sometimes it’s nice to feel that your professional skills can also be useful after working hours. Our voice assistant may feel the same. That’s why when designing George, we should think about behaviours that he can demonstrate outside his professional scope. Maybe it would be nice if he could also tell what time it is? Or how long would it take us to get to the office during the morning rush hours? Or perhaps advise us if we should take an umbrella when leaving home?
Additionally, the Features field lets us specify devices users can have access to, brand identification guidelines, and so on.
Barriers
Unfortunately, nobody’s perfect! There are certain cases when a voice assistant won’t be able to help. It may be due to certain technical barriers, budgetary constraints, or simply due to the limits of the design. Here we should list all the potential technical constraints such as data storage, third party channels, etc. and of course think about how to deal with them!
My dreams
I know. Voice assistants don’t have dreams. But since we are their creators, we should think about their development and future tasks. Use this space to define all ideas for the future. Think about features, devices, scope, and additional skills needed in the future.
Summary
That’s it! You can apply these 8 basic steps to quickly answer the most pertinent questions and get started on designing your voice assistant for your client. Those marked in red are related more to user needs and motivations, whilst those marked in blue are focused on the voice assistant’s features. Once all the questions have been answered, we can look at the full picture, and know how to develop a solid voice assistant experience for our client.
Use this canvas during the initial workshop and for best results, make sure the entire design and development team as well as all other stakeholders are involved. This should give you some very basic clues on how to build a voice assistant that will meet user expectations and client requirements at the same time.
This is the first version of the canvas so please do not hesitate to test it, adjust it to your design process, and of course let me know what you think about it!
