 Yeah, thank you so much. Hi, good afternoon. I see a couple of familiar faces who are there for the workshop yesterday. So let me introduce myself again. My name is Sohan. I work in Amazon as an Alexa evangelist. My job involves helping developers build skills for Alexa. And part of that involves talking about voice design. Now, a lot of people ask me what, you know, give me some tips about what, I mean, building skills or what are the key components of building a skill. And what I usually say is the tech part is easy. We just did that in a workshop yesterday. But the tricky part is actually designing for voice, because it's very different from what we've been used to, which is essentially designing for screens. We have used to, you know, designing for web or mobile. And I'm sure you guys have done that. So let's talk a little bit about voice user interfaces and how it differs when you're designing for the year as opposed to designing for the eye. I'll give you a small, you know, I'll set some context first and look at how we have interacted with tech so far. And we've started in the 70s with character mode, which was when the era of the person computing really started. And we went from character mode, which is essentially small black and white monitors with keyboards attached where you enter text commands. We went from there to the era of GUI, like graphical user interfaces, which still exists, of course, but it first started in the mid 80s where you essentially had operating systems that were visual in nature. So you could see a file on the desktop or you could move this piece of hardware around that would translate onto the screen. And remnants of that still exists today, of course, you know, with your macOS and your windows and your Linux and stuff like that, but that was for the first time in the mid 80s. In the mid 90s, things changed to the era of the web and to access websites for the first time, you could get information on your fingertips and to really access that information, you had to use this thing called a browser, right? And when we first started using browsers, we were introduced to so many new elements and new ways to actually get information. In the mid 2000s, I think something we're all familiar with the era of the mobile, right? Where essentially we went from really basic phones with small screens and keepers that were fairly clunky to the advanced smartphones that we have today. And think of the sort of interactions that you have on your phone today, right? Like a swipe right or pull to refresh or how you zoom a page by pinching in. Those are some of the interactions that didn't exist before, but thanks to the advancements in tech and thanks to how tech has really evolved, how we interact with tech has also evolved. So if you see every 10 years or so, there's a change in how we have really interacted in tech and as if on time, sometimes in the present, in the 2010s, mid 2010s, we finally move to the era of a voice user interface. Now you might think as humans, voice is something that comes naturally to all of us. We communicate via voice and language. Why did it take so long, right? If you've seen a lot of science fiction in the early 1900s, if you've read a lot of science fiction in the early 1900s, having like these robots that talk was like the sort of fever dream, right? That was that and flying cars. And I think we're working on both right now. So why now you think? The reason is it wasn't so simple, but only now we finally have the speech to tech's capabilities. We have the data, we have the data processing power, we have the network power. So all of this has finally sort of come along for us to be able to talk to machines and hear an intelligent response, right? So at Amazon, we sort of believe that voice represents the next major disruption, which means that we will be talking with machines. We will be interacting with machines via voice a lot more at home, at your workplace, at your university, in your car, and so on, right? So I promise this is the only marketing slide, but this is the Amazon Echo. Essentially, it's a device that lets you voice control your world. And yeah, it's a great device, if you want one, you'd probably use it already. On the Echo, there are a lot of things you can do built in, you know, you can ask the weather, control your smart home, lights do like household reminders, set alarms, all these typical sort of things, but you can really enhance the capabilities of an Echo device by using something called a skill. A skill on an Alexa-enabled device or an Echo device is like an app on your phone, right? How on your phone, you can do a few things, but you download apps to do a few more things, right? So that is just to set some context about what a skill is, what an Echo device is, what Alexa is, and so on. So let's get into the meat of things, right? So we all have been designing for different platforms for a while now. Of course, few of you might have started with desktop. Most of us probably started on the web or on mobile. So we've sort of got an idea of what designing really means. But like I said, so far, we have been designing for tech which included screens, right? And one thing we can take away is that when you focus on the user and when you focus on the platform, you sort of get like a good user experience. But it takes a lot of effort, right? When the web first came around, it wasn't always pretty like it is now. I don't know if it seems like a fairly young crowd, but the early days of the internet websites really sucked. It was terrible, right? Basically, people had no idea of what to do, so they just put in as much, you know, as many like logos and flashing GIFs and mark we text on it as they could, right? And honestly, I know there's a government thing happening next to it, but a lot of our government sites look like that in the early days, which was a little embarrassing. But of course now it's a lot better, right? Because we finally had, we finally had like templates and block templates and people finally understood the web. We went through the same thing when we moved from web to mobile, right? When I don't know if you guys remember surfing a website on your mobile when smartphones just became a thing, but you had to like zoom in like 300 times to read like one line of text because responsive design wasn't the thing back then. It took a lot of people to think about design and to really think about the sort of paradigms that would work, not just on mobile, but also on your laptop and desktop. And then people thought, hey, we should probably, you know, have a uniform sort of experience. And then they came out with responsive design. So now reading a website on your phone, assuming, you know, it is mobile responsive is a fairly easy task. It's the same with voice though. When voice was launched like few years ago, people just sort of, A, they either assumed like it could do everything. There are of course limitations in tech, when in natural language understanding and so on. But they also still sort of thought, hey, let's port the sort of experiences that we have had on mobile and web, right? Just take the same thing. I want to be the first in the space, you know, like first prime mover advantage and that sort of thing. And they sort of ported those real experiences without thinking about the fact that it's a different platform altogether, right? You're designing for the year and not for the eyes. So things change. So we're still at this phase, I think, where, similarly, how people used to zoom in on mobile, where we're still at that phase with voice design, right? And it's going to take a lot of design thinking from people such as us to really sort of nail the voice experience on voice user interfaces. But that's what we're here to do. So let's talk about some differences when you're actually designing for voice versus designing, you know, for the eye. I think the biggest sort of difference is this, where with your eye, you expect uniformity, but your ear really expects variety. How we really look at graphical user interfaces is we sort of teach ourselves what something does, yeah? So if you go to a website or you go to an app, you sort of want a uniform experience there. If, for instance, like an Amazon or like a Google decides to change how their website looks and you go to that website, you've been using Google search for the last 20 years. Suddenly that search bar isn't there anymore, right? They've added like another button that leads to a search bar. We're all going to be very disoriented for a while because we're so used to it being that. We sort of teach ourselves that, okay, this button does this. Just as an experiment, if you want to, you know, sort of, if you don't believe me, take out your phones and look at the location of the app that you use the most, right? And change it around. Change the location of, I'm guessing it's either WhatsApp or, you know, Snapchat or Instagram or whatever. Change the location of that app. You will see that the next time you want to use the app, you'll go to where it previously was because you sort of trained ourselves for that app to be there. That's how we learn user interfaces when it comes to screens. With voice though, it's not quite the same. The year, for some reason, it's designed that way but doesn't like reputation as much, right? You want a lot of variety. So you really sort of need to keep that in mind while designing your voice user interface. With GUI, like I said, again, there is a defined happy part. If I go to an Amazon or Flipkart, I know that clicking on these four buttons will take me to a page that says buy and clicking on the buy button is done, right? So there is a defined happy part to do something. If I go to a travel website, I know that first I have to enter the details of where I want to go. Then, you know, I enter my personal details and then I pay and it's done. I can't do much outside of what the website really provides me. There are buttons, there are menus, there's a search bar but that's pretty much it. So there's a defined happy part to do something. Again, with voice, there is no such guidance. You can hint at the user to do something but at the end of the day, the user can say whatever they want, right? So it's really up to you to sort of figure out what to do. Also, again, all the words that you see on a graphical user interface are designed for writing, right? Or, you know, reading. And on voice, though, you're designing it for speaking. Yeah, a good example, I think, outside of tech is the Harry Potter movies. Has anyone read the books and seen the movies? I'm guessing most of them, right? So you'll actually notice that the dialogues in the books are a lot different from what you hear in the movies because how we read a dialogue versus what is said in a movie or in a cinematic visual experience is a lot different. Yeah, so there is like a sort of slight difference there as well. And finally, and this might not be in every case but largely, you know, when you interact with a screen-based device, especially a mobile phone, it's a very individual interaction, right? You're largely like talking or, you know, interacting with that mobile phone just by yourself. So even at a social gathering, if someone, if there's a question about say, hey, does Virat Kohli have like the most ODI hundreds now? Let's find out. People pull out their phones but that interaction you're checking it's still an individual sort of interaction. Whereas voice is a far more communal sort of interaction. The way at least Alexa and all the other smarts because they're designed, it's meant to be like either in your home or at your workplace where other people are around and they can also hear what's happening. So it's a fairly communal sort of experience. So these are the fundamental like differences I'd say between a VUI and a GUI, right? So keeping that in mind, we have come up with four voice design patterns that you'll, that you probably need to think of if you're building for voice. So let's just get right to it. Before that though, this is the sort of core interaction of any voice, you know, any like voice user interface where first the user says something and that's called an utterance and utterance is what a user says. So if I say something like Alexa, what's the weather? What's the weather is the utterance. So the user says something like what's the weather and that's the utterance. All voice interactions are very, very situation specific, right, which why you see in the core interaction there's this huge thing that says situation because the response that you need to hear from Alexa is based on that situation. And I'll go into that a little later on. And that's the response you hear. And sometimes you have like a prompt from Alexa as well, you know, if a user hasn't said something and there's a reminder. So we'll get straight into it and talk about the four voice design patterns. All right, so the first one is called being adaptable, which is letting users speak in their own words. Now, again, as designers in the crowd, when you're designing for GUI, right, when you're designing for a screen, it's really you guys who decide what the user sees. So you guys say, hey, if we change the color of this button to orange and instead of, okay, we type the words by, there's like a 30% chance a user is going to click on it. So let's do that. That's typically what we do as a designer. And y'all are really deciding saying, hey, let's put all this information here and then the next button make this button this color and then this what the user sees. So you're really deciding what the user sees and the user has to sort of learn that interface to get something done. Yeah, that's what we do as a designer. With voice though, it's the opposite because the user sort of is going to say whatever they want. Yeah, and it's really up to you as the designer or the developer of the skill to be adaptable to what the user said. Yeah, and for that, there is a lot of tech, of course, but a lot of design as well goes into it. So for instance, let's, before that though, let's talk a little bit about something called an affordance. Does anyone here familiar with the concept of an affordance? An affordance is essentially something that lets you know how to use something by design. Yeah, for instance, a sign that says push the door in next door door handle is an affordance because it's letting you know how to use that door handle. Yeah, so there are roughly three types of affordances. One is explicit. Like I said, the push sign is an affordance. Something like a pattern is something that you see everywhere worldwide, maybe a convention, like the save icon on your system. The floppy disk is a pattern that you see everywhere. It's the universal symbol for a save icon or the Wi-Fi symbol. So even if you go to a foreign country where you don't know the language and you can't read anything, you see that Wi-Fi symbol, you know, okay, that's what Wi-Fi means, so it's an affordance. And there are also negative affordances, which is essentially when, okay, like in a form, right? And when you disable a button and then the user automatically knows that something they're filled in is either wrong or incomplete, it's a negative affordance because that way by design, you're telling the user that, hey, there's something wrong with what you're filled. Yeah, so it's something that lets you know what to do. So that's an affordance. On screen-based devices, we had to sort of evolve from going from, you know, modeling how things looked in real life to, you know, flat design. So in the early days of the internet and in the early days of mobile, we had like skewomorphism was a huge thing, right? Where we sort of took real life objects. So this was how a volume control looked on both web and, you know, mobile, essentially because this is how a volume knob looks in real life. So you'll see like a drop shadow, it'll look little 3D, it looks like I can actually feel it and I have to move it, but you're actually moving a mouse or using touch screen to move the volume up and down. Then when people actually got a little used to something like this, we went to like flat design. And I'm sure you guys remember the whole flat design shift in iOS, you know, the whole thing, where designers basically said, okay, I think users know what to do, we can move to flat design. So the users know that if I move my finger across this bar, the volume will increase or decrease. Yeah, so that is the affordance basically. In voice, again, there is no screen. So you'll have to say something out loud to increase or decrease the volume, right? So you can say something like turn up the volume. So the intention or the meaning or what we call an intent behind what the user said is the affordance in voice, right? So when you say something like turn up the volume, that becomes your intent. You want the volume to increase. So that's the affordance. The problem with voice is this, right? You can get your users to say something like turn up the volume. It's fairly standard way of saying this, but most users will say things differently. Again, remember, you know, it's a voice user interface. So people can say something like volume up, louder, make it louder, turn it down, set the volume to six and so on, yeah? So these are different utterances that you can have that need to match to your intent, which is the affordance. So having just turned up the volume work won't really work. I mean, you know, you're really limiting your user to say just that you want your users to speak naturally at the end of the day. So you should write your design or your skills such that it can take any of these and actually do that action. This is another example. So these are different utterances to basically get the name of a college, right? It's a skill that gets your college. So I can say something like, you know, let's assume the name of the skill is college finder. So ask college finder for the best colleges, for the best colleges in Bangalore, for the colleges with the computer science program or for colleges with the computer science program in Bangalore, right? These are different ways of saying the same thing, which is to find a college, right? We're trying to be adaptable to what the user can say. All these will match to an intent that you as a designer or a developer will define, which is called like, let's call it refine search. You can call it whatever. So it's really up to you to define these different types of utterances to match to that intent, yeah? Also, you'll notice that there are some words in blue, right? And those are essentially what is called an entity or a slot, which are variables within an utterance, right? Anything in an utterance that can change. So in the second one here, this name of the city can change because I can easily, another user can say something like, ask college finder for the best colleges in Chennai or Delhi or, you know, Mumbai. Also in this example, the type of degree is, can change, right? Because I can easily say, for colleges with the electronics program for an economics program and so on, yeah? So things that can change within an utterance is called a slot, right? And essentially, this is what it is. You have like a degree or a location. Your utterances should match to an intent that's defined and also have slot value. So you have like a degree and a location. What the use of all of this is, is essentially this is how you'd be developing your skill, right? Where you give training data like different utterances matching to an intent and then there are natural language understanding algorithms, right? And I'm going a little technical, but what the NLU algorithms do is sort of take what the user said and it matches it, you know, with an intent. And that's how you know the intention or the meaning or the affordance behind what the user has actually said. There are sometimes though, why you might want to use synonyms as well, right? Sometimes your slot values can have synonyms because assuming you have a skill which has four different slot values, which is size, right? Like tiny, small, medium, large. Again, not all of your users will use the words tiny, small, medium, large. And the reason is someone might not know how tiny is tiny or they might just use a different word. Who knows, right? So instead of tiny, they might say like minuscule or little instead of medium, they might say average, middle, or in between. Instead of small, they might say little again. Yeah, so it's really up to you to sort of design your skill in such a way that it takes all of these synonyms as well. And you know, sort of you're adaptable to what the user is really saying. Yeah, so that's why you really need to be adaptable while building a skill. Okay, we'll talk about the second voice design pattern which is to be personal, right? And which is essentially talks about interactions in context. I think the great thing about conversational interfaces in general, you know, chatbots and Alexa skills and so on is, and I like to use this line a lot, right? So far we've been forcing humans to think like computers. Humans shouldn't be thinking in terms of a radio button, drop down menu, swipe right, et cetera. Those are not natural interactions. But now we're actually forcing computers to think like humans, right? So with conversational interfaces, you can actually have like personalization and contextualization in your skill. And that means a bunch of things. One is you can really tailor and change your skill and evolve your skill over time. Yeah, the first time a user logs into a skill, you can say something like, hey, welcome to this skill. Here's how I can help you. This is what I do and so on, right? Maybe the second time you say the same thing. The third time you say the same thing, but you don't want to say that exact same message the 20th time the user is logging into your skill. They already know how to use your skill, right? But on the other hand on phones, you're going to see the exact same UI every time you go there, which is a good thing. You don't want your UI to change. You want it to be uniform and you want to have that consistent experience, right? So with a screen-based device, you like it to have that uniform, consistent experience, but with voice design, you know, you sort of need to tailor your experience and change things around quickly, right? So really have your skill evolve. You also need to think of the sort of roles that your skill plays with the user, right? So we roughly look at it as three different type of roles. The first one, you know, is like the dog sort of fetching. It's about giving information immediately. Like a good example is a weather skill where I say something like Alexa, what's the weather? And Alexa says the weather in Bangalore, so and so. You really want to be quick and precise and concise. When I say something like, what's the weather? I don't hear, hey, welcome, I'm your weather skill. I can help you with this, like my Facebook page to know more, et cetera, right? Because it's a very informational, it's a very transactional sort of skill. So giving a quick response back with like a concise amount of information is what you really want. Another type of skill is a concierge, right? Like the guy helping out the lady there. It's a type of concierge. So think of like a travel planning skill and I'll show you an example later where you'd call up your travel agent and then there's a lot of back and forth between the two, right? There's a lot of back and forth between the two and you're really sort of guiding the user and helping the user by asking questions and you're not getting something done for the user. You're really like a support, like a concierge. So based on that, the responses will be very different, right? You'd really personalize and contextualize your skill based on that particular role. And the last one is a sort of entertainment type of skill. It could be a game. It could be a choose your own adventure that's very popular on voice interfaces where you say something like when the skill says, hey, you've entered this dark room and there are two doors. Which one do you enter? The left or right, you know? A different adventure happens on each. Maybe it's just like a fun podcast type thing. So it's an entertainment skill. So you have to tailor your response a lot more. Maybe add more jingles, add more sound effects. You know, add... There are these things called speech cons which are local lingo words that Alexa can say. So you can get her to say things like ballet, ballet and macha and stuff. So really think of how you can keep your users engaged with using things like that. So that was two on how you can be contextual. The third one is be relatable, right? Where you're talking with your users and not at them. Again, on web and mobile, it wasn't really a cooperative experience, right? Again, the website would offer you something and it's fairly individual sort of experience. With voice, it's a very cooperative experience. There's a lot of back and forth between the skill. It's almost human-like. That's why it's called a conversational interface. So you really want to talk with your users and not at them, yeah? Don't expect your users to remember a whole bunch of things. They are cognitive load. Shouldn't be on trying to remember how to interact with your skill. It should just be able to speak with your skill naturally, right? So this is a bad idea, right? Where you say something like, Alexa, open holiday planner and tell me the cheapest return flight from Bangalore to Goa on the 10th of December, returning on the 16th of December, with offers available on HDFC with cashback, blah, blah, blah. And no one actually talks like this in real life. So you shouldn't expect your users to do this. And invariably, if you expect your users to do this, you're the one who'll end up with a whole bunch of errors, right? Because your code has to actually parse all of this, pick out the right things, and then, you know, and then provide the user an answer. You'd rather have something called a multi-turn dialogue, where like I said, it's like calling your travel agent and there's a lot of back and forth, right? So for instance, this is how the conversation would go. I know there's a lot of text, but so in the beginning, the user says something like Alexa, let's call the skill outdoor guru. So Alexa, start outdoor guru. And then the skill says, you know, welcome to outdoor guru. I can help you, blah, blah, blah. Where would you like to go? The user says, go ahead. Alexa says, are you sure, go ahead. User says, yes. Alexa says, when do you want to leave? Next Friday, until when? The following Tuesday, what would you like to do? I'll be fishing. Did I get all of this right? Yes. And now, you know, I have two ideas for you and you hit like your API and get some information and present it to the user. So it's a lot like how you would actually call up like a travel agent or, you know, like a holiday planner and it's a very interactive, cooperative sort of experience. So you should try and build your skill like this, where essentially you're helping the user out with a few things, right? If you really think about it, things like source and sorry, destination, dates of going and coming back, what activity you'd like to do are all what I said is a slot value, right? It's a variable at the end of the day. And instead of having this, where you have like different slot values in one huge utterance, you're sort of eliciting the slots from the user. So the user is engaged, is conversational and you're getting the right answers. There are a few things happening here. One is you're eliciting slots at a couple of places. So you're helping the user out with those slots. In this step here, you're actually confirming with the user a slot value, especially when you have a lot of proper nouns, that's a good practice, because like for instance, Bangalore and Mangalore sound very alike. So maybe you just wanna make sure Alexa picked up the right thing, right? So you're confirming the slot and after so much information, you might want to confirm with your user saying, hey, this is the information you gave me, is this right or can I make any changes? And if the user makes any changes, please go ahead and actually write your voice design and your code to be able to accommodate those changes as well, yeah? So this was about how you could actually be relatable and not have things like this, but actually have like multi-term dialogue to get information done from the user. And the last voice design pattern is to be available, and by that we mean basically rethink your menus and your top level UI. What this essentially means is again, so far with voice and with mobile, sorry, with mobile and with web, we've been sort of designing our data in a slightly different way than what you should for voice. It works in the sort of same principle that there's a front end and a back end. In the front end with voice user interfaces, things you see, whereas in front end on web and mobile, it's your screen, that stuff remains the same, but how your data is stored is going to be slightly different, right? So I'll tell you an example, right here. If, and this happens a lot of times, so if a user, rather if Alexa says where do you want to go, a user can say something like go out tomorrow, right? Yeah, just give me two, I'm also, yeah, go out tomorrow. Yeah, that happens often and then it would be a really bad experience to ask the question when you want to leave again because the user has already answered it. So in effect, the user has over answered, yeah? That happens often. So yeah, it might leave a bad experience, but you'll still get your API call at the end of the day. So that's fine. But when the opposite happens, it's even worse. So Alexa asks, where do you want to go? And the user says, I want to leave from Bangalore, right? So the user actually hasn't answered the question. So you don't have this piece of information and then you continue this way and you don't have one piece of information, one slot value and your API goes for a toss basically, right? Because your information is incomplete. So typically users will over answer and under answer and essentially how you'd handle that is not by using a typical flow chart type UI, right? This is how you would look at screen-based devices where you say, okay, a user logs in, a user does this, a user clicks on this button and there's this entire flow or the user clicks on the other button, there's another flow. So you have a lot of nested level, you know, iterations. You'd rather look at what we call a frame-based UI where there is a frame in which you need certain piece of information and until that frame is over, you keep asking questions in that same frame. Yeah, so in this case, until you get these four pieces of information, these four slots, until you elicit these four slots, that frame keeps continuing on and on, right? So that frame keeps going on until all those pieces of information are complete and then you make the API call. So it's a slightly different way of actually looking at how the data is stored. Also, try and have a wide top-level UI as opposed to, you know, like nested menus. And the reason is this, I'm going to take a very specific example. If you want to find the IFSC code of your bank, what do you do? You go to your bank's website, you log in and you sort of click on your profile, then you go to bank account details, then you scroll all the way down, then click on another button and then go to IFSC code. And the reason, and it's completely fine to do that, and the reason is on screen-based devices, you have a limited number of pixels. So you as designers say, hey, this is the most important stuff we need. This is a hierarchy of important things. So let's stick all of that accordingly, right? If you translate that to mobile web, you have fewer pixels. So you might show just the five most important things and the user has to probably make more clicks to get to a IFSC code. It doesn't work that way with voice though, right? A user is not going to say, okay, open my profile, okay, go to bank account, okay, do this, et cetera. They'll directly say, hey, Alexa, what's my IFSC code? Or open HDFC and tell me what my IFSC code is. And that wouldn't work if you had like a huge nested sort of menu, right? Which is why you need to have like a wide top level UI where these pieces of information are accessible immediately, all right? So that's a slight difference again, and it's all about being available. So just to recap, we spoke about being adaptable, which is let users speak in their own voice, which means utterances, intents, and slots. Be personal, which is interactions within context. You want to be relatable as well, which is talk with your users and not at them. We don't want like IVR type responses. And we also want to be available, which means to rethink the way your data is stored and how your menus are stored. Just want to end with this quote from Gartner. Gartner does a lot of research on cutting edge data and innovation. So in 2018, they said something like this. They said conversational platforms will drive the next big paradigm shift in how humans interact with the digital world. I think it's a great quote because, you know, conversation interfaces are really here to stay, and I'm sure it's going to disrupt how we engage with tech, basically, right? And if I were to tell you 10 years ago that keyboard and mouse won't be the primary user interface, you already have laughed at me. So I'm here now telling you that touchscreen probably won't be the primary user interface 10 years from now. And it'll be conversation interfaces. So as designers, y'all are the ones really at the forefront in defining that experience. So yeah, good, do check it out. Anyway, thank you so much. These are my details. Thanks a lot. I think I'm out of time. So I'll have questions off stage. We can take one question if anybody has. Or else, do we have any questions? Yeah, we have one question. We can take one question there. Yeah. Hi. For a designer, how much of interface design is involved in BUI? So I'm not sure what you mean by interface design in the traditional sense, but I can tell you this for any skill or any voice experience, I think the designer plays the most important role, right? Because I still think, I still say that tech is the easy part. And this is something that users are still not used to or it's new. So designers actually play the most important part. And it's all about interaction design at the end of the day. Like my colleague often says, like always start with people and not computers when it comes to conversational interfaces. And this has actually opened up like this entire new job market. So now you have like dialogue designers or voice BUX people and stuff, which are completely new job description in itself, right? Where you're really sort of studying the interaction between a user and a voice user interface, which is completely different from like HCI in like a traditional screen-based interface. So I'd say it's very important. And it still falls under interaction design just that with a voice interface. I'm confused because it involves a lot of machine learning, data science, and a lot of other stuff. But we know the traditional way of design is no more involved, right? So in that way, I'm like, for a traditional designer, it is a complete shift if you go to see. So that is a question. So I wouldn't quite agree with it being a complete shift, right? Because as a traditional designer, you looked at like say a website and you'd say, okay, how to make this website the most user-friendly website for my user. And you're doing pretty much the same thing just via voice. The good thing is a lot of the tech stuff is taken care of by either the Alexa Cloud or by like the tech team. So you don't, as a designer, you really don't have to worry about the machine learning, about the data science, about any of that stuff, right? Your core focus is on providing that voice user interface for your user, right? At no point as a designer, I'm like, okay, how do I do the machine learning algorithms for this? Because all of that is taken care of by the Alexa Cloud and not just with Alexa with any other system as well. So you're really focusing on, okay, what are my users going to tell Alexa and how is my Alexa skill going to help the user complete a task? But that is again the job of data scientist or a job of machine learning. Again, that is the tech, right? So like, okay, let's take the trip planner. They define all of those things, right? They define what the user should speak and all of that. Which is a wrong thing, right? It's basically like getting your engineering team to do the user interface in your app. You know what happens when that happens, right? So it's the same thing. So I'm saying that skills or, you know, building for voice needs designers to actually get that experience, right? You don't have your engineering team do that. But that is how even, you know, the coding happens, you know, we write high level coding and all that. That's because we have defined our C or C++. There are definitions like, you know, what should be written and all of that. So that is what even coders do. Yeah. That is not given by the designers. But now if we say that, you know, we have the designers have to say what should be done and all of that. Then again, the tech team will have a tough time. No, not quite. So again, let's look at front end and backend, right? On a traditional screen-based device, the front end is what the user sees. So if I go to like the Hasgeek website, for instance, you see like an eyesight, the menus, et cetera. And all that is sort of designed by the design team, right? So the design like, okay, I want these colors. I want this menu. I want this interaction to book a ticket. It's the same way with the voice user interface. There's a front end and a backend. The front end is anything a user says to the skill. So in my previous example, that conversation is the front end part. The backend is like that, that pure backend making a call to some API that you have, which is taken care of by the tech team. That is not related really to the design. I mean, it is obviously that it works in conjunction with each other, but that's not something you really need to worry about. You really need to worry about the front end, which is okay. This is how my user is talking to the skill. This is what my skill is going to respond to help the user, et cetera. So I'd say it's, designers still play a very important part. Thank you. Do we have time or am I? We can take one more question if we have. Do we have more questions? All right, I guess not. So I'll be off stage if anyone's interested. So thank you. Thank you so much.