Optimizing UX in AI-Based Technical Products

Khushali Sandhi at UXDX Community: Payment Design & AI-Based UX Optimization. Video: https://youtu.be/NOwfYeBexMg

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why we're having this session

[00:00:00] Hello everyone. I am really excited for this session and I want to thank everyone, first of all, for participating in this. I would really love to share what I have been learning so far working on AI projects recently. So let me get started with my introduction.

[00:00:24] As you probably now know, I'm Khushali and I am a senior UX designer at Amazon. I've been working in the UX design field for over 15 years now, and I recently got an opportunity to work on AI projects, end to end. So I thought this would be good to share, my experience about how it changed the design process a little bit. Because to be honest, when I was getting started on this project I didn't find a lot of resources. I was trying to see how I could get started, how the design process is different when you're working on AI products, but I didn't actually get a lot of things, although I started reading some of the books, taking some online courses. So I thought it would be really good to just share my journey, and what are some tips that you could use in your design process.

[00:01:27] Coming to the agenda, I will first be talking about why we are having this session. I talked a little bit about it already, but yes, I would like to dig in a little bit on it, the goal of this. I would also go into the definition of AI UX design. Although it's not accurate, but I think it's just how I'm seeing AI influencing UX design. And then we'll dive into design thinking for AI products. At the end of it we don't want to miss out how we measure the success when we have designed something, so we'll get into that as well, and then we can take questions as well. But if there are any questions in between as well, feel free to shoot them to us.

[00:02:15] So why are we doing this presentation? As I was saying, when I was getting started on the AI project I didn't find a lot of resources about the UX design as such, so I was hunting for the information all over the place, and then I wanted to do it the right way for my very first project. So I would really like to share my experience based on those learnings. I also realized that since the technology itself is really coming into play with full force and power, everybody is now talking about the AI strengths, where we can use it, its weaknesses. But then, for decades, whenever we have seen the technology come in, it's driven by the technologies, and we kind of forget the human element. It is kind of like an afterthought.

[00:03:13] So I think it's easy, even in this scenario, that we focus on the technology more, but then we forget about the emotions of the people here. How can we make the human element important here? And that's where UX design comes in, our role as a UX designer, to keep reminding how important it is to not forget UX design. With AI being in full force, fast pace, we have to just go along with this technology. And I would like to share the tips on going over the design process, so that you and all of us, we can design with confidence. So my personal opinion is that there will be an increased significance of UX design with this technology.

What AI adds to the layers of UX design

[00:04:06] All right, so now let's talk about UX design. As designers we all know that at a high level this is the diagram from Jesse James Garrett's The Elements of User Experience. At a high level he put in five elements. Although this is not the complete picture, but still, this is the best, which applies for any product in real life. So it talks about the scope, where we talk about what is the goal of the website or the product that you're working on. And then we start going into the actual specification, the requirements of that particular product. And then we get into the interaction design, basically trying to define what are the task flows, the customer workflows and so on. And then we start defining the components that will help to achieve those task flows. And then the last layer is the visual design, where we talk about how that finished product would look like. So far our understanding for UX design has been like these layers, doing a good job on what we have been doing right now.

[00:05:19] With the introduction of AI in UX design, most often we are designing in a probabilistic system. There are deterministic systems, we have been working in that scenario already, so I'll be talking about the probabilistic system, where the input of the product is kind of random, at the same time the output is also something that needs to be predicted. The system itself is dynamic here. So I think it really changes the way we look at UX design now. The products we had been working on were doing what we tell them to do, which is what the deterministic systems are. There are AI products which are deterministic, they are probabilistic as well, most often they will be probabilistic, because that is where the power of AI can be seen.

[00:06:14] So I guess with the introduction of AI UX design I want to point out that there are multiple layers now that get added, starting from the system, how the system is built. That is something we as UX designers would want to know, how the system itself is built. What I mean by that is the data that is being used to train the AI model here. We want to know the algorithm of the AI itself, how it is working, what kind of algorithm it is using, what kind of output that model is going to generate. And then the human interaction again: how is the customer going to use the product, how is the customer going to react to the product? So there are a lot of things that come into play.

[00:07:07] And in this scenario now, these five layers actually get added to each of these stages of the current UX design diagram that we just saw. So I think mostly, I personally feel that they are part of the business objectives, they add to the functional requirements. At every stage of these layers, the interaction design, the information architecture, we have to keep looking at these additional five layers, which are going to guide our user experience.

Design thinking for AI products

[00:07:42] Okay, now I want to get into the design thinking for AI products. So we saw what that model looks like. Now I want to talk about some of the examples and the process itself that we can use to design AI products. So I'll be talking about understanding the data. I talked about understanding the system, the data and the model, so this is where I want to go into a little bit deeper, to share what does it mean to understand the data. And then, once we have an understanding of the data itself, also think about the phases that the AI feature itself can have. And the journey mapping, which we as designers already do, but then for this product, how is it going to be different? Doing the design itself, and then how earning trust is actually even more important with AI coming into the picture, and then evaluating the AI experience that we have designed. So I'll be talking about each of these topics now in the design thinking.

Understanding the data

[00:08:50] All right, so understanding the data. How can we as designers now participate in the proof of concept? When any company starts an AI product they may have an engineering team who is doing this hard job of training the model. They're gathering all the data, first of all, to train that model. So I think in this stage it's really important for us to be part of that. Although we may not be doing the training piece of it, we just want to make sure that we understand how much of the data is being used, what that data is, what parameters have been considered. So once we have an understanding of data that is being used to train the model, then we know the system really better, we can understand the output as well.

[00:09:48] So I think once you have gotten an understanding of the outputs, we now also understand the success rate of the output. What's the accuracy, how often the system is actually giving us an accurate response? Once we have that understanding, then it will really help us to put the AI product into different stages. If the data is not good enough then the product itself is not mature enough to put out with the confidence that this is a product you can give a full level of autonomy. I think if the data is something that needs to be improved over time, then the onboarding experience itself is really different. So that's why understanding data is really important here.

[00:10:47] At the same time, the performance: how much time the system really takes in responding. And then again, just trying to understand, if the data isn't good, do we have enough time to improve the model before we launch? So if we have enough time, again the design kind of changes. That's why understanding the data is really important.

When the data goes wrong: Watson and the Twitter bot

[00:11:12] I want to talk about the examples here. In 2011 IBM came up with this concept of Watson, which was trying to help in the healthcare industry. Watson was basically focused on oncology, so the idea was that this product would really help the oncologist to give recommendations about cures for cancer. They had a really great goal in mind and I think they saw an opportunity here, and I think it was a great effort from their end. They already spent like five billion dollars to gather data from different sectors, into insurance, like companies who were having the imaging details. They also tied up with the oncologist experts. So they did a lot of good job on gathering data from various industries and they started to train the model.

[00:12:19] Around 2017, when they actually partnered with a cancer center in Texas, they started to realize that the product is failing. So now what really went wrong in this scenario? The thing was that the data that was being used was kind of biased. It was data from, let's say, a specific geography, and if, let's say, the data is used from New York and then you try to apply it to population in China, then the cure really differs, because the people are different. So what happened was that the recommendation that it was giving was not really relevant to the people. So the experts, the oncologist experts, started to feel that it's not giving the right information, so the product really failed.

[00:13:14] Now, why am I giving this example? It's to make you all see the value of the data itself, and how a designer can come into play at the very beginning, to try to understand the output themselves, trying to understand how much data we have fed in, is the data, is there a possibility of bias here? So the data itself needs to be good enough.

[00:13:42] Another example is from Microsoft. It was a Twitter bot that they had created. I think the goal here was that this would have a very positive conversation with people, but I think this product also, within 16 hours of deployment, it failed, because the algorithm that they had used was such that the chatbot, not chatbot but the bot which was on Twitter, it will learn after communicating with people. So as you communicate with it, it's kind of like reinforcement learning. You talk with it, it learns from that data and then it will talk to you. So I think what had happened was that, because it was in social media, a lot of people started to train the bot, it started to game the bot, and then it started to learn the bad things, and this started to post vulnerable[?] posts. So I think this was another example to just show you how the data is important and the algorithm is important, and we as designers, when we start asking these questions, we can raise these concerns very early on in the stages.

The three phases of an AI feature

[00:15:00] All right, so now let's go into the AI feature phases, which is our second topic. Now, once we have understood the data itself, how good that data is, then we want to break it into three phases as such. For example, the onboarding. If we know that the product is going to have good enough data, it's going to be a very strong product, then we can give it a lot of autonomy. But then, if the data itself is such that we need inputs from customers to train it, then the level of autonomy is not really high, we might need to give a lot of control to people when the customers are getting started. So what would that onboarding experience look like for this AI feature?

[00:15:44] We might need to also think about the level of intervention, how often the people will need to intervene. For example, if the customers are using a product to review the content that the AI has generated, then we might want to have an approval process before it actually gets to the end users. So I think we have to think about the level of intervention here while the product is in use. And then, once the usage has been done, if there is reinforcement learning that we have in the product, then we might also want to consider having a way for the customers to give feedback, based on which the model can again use that data to learn. So I think there are these three stages that we might need to consider when we are designing that particular AI feature itself.

[00:16:41] Based on McKinsey Global Institute's analysis on 400 use cases across 19 industries, this was an analysis that was done, and they found out that more than two thirds of the opportunities to use AI were in improving the existing flows, not actually creating a complete new AI flow, but it was within the existing flows. So in this whole presentation, and my experience was also to improve an existing flow that we had. But then there were about 16% use cases which needed entirely new workflows. So in any case, the design thinking process that we are going over will apply in both these scenarios. I just wanted to call that out, that the majority of the experience as of now might focus on improving the existing flows.

Journey mapping for AI

[00:17:40] Now let's get into the journey mapping. I'm sure you all might have done journey mapping in your design process. There's nothing to read on the right side, I just put an image so that you know that the journey mapping is still important when it comes to AI. It's actually even more important, because now, since we are talking about improving the existing flows for most often scenarios, we want to have this journey map as a reference, to compare how did we improve the flow with AI being there. Did it actually improve, or are the customers spending a ton of time just figuring out what just happened? So we want to really compare the before and after, and our journey map is the reference for that.

[00:18:28] Once we have created the journey map in our design process, we might want to keep updating this journey map with the new data that we discover. So if the model is getting trained really well, you might have a beta, and after the beta the product is actually really good because now it got more data. So then this journey map might even change, because now the onboarding experience might not really need that many steps to just train this particular product, you're just having a good level of autonomy in that product. So again, the journey map changes. Even the opportunities: at every touch point that we add in the journey map, the touch point will really help us to see how the AI can now fill this gap, so we might need to keep updating that as well. I just wanted to call that out, that journey mapping is even more important with AI products.

Designing for a probabilistic system

[00:19:29] Okay, now going into the probabilistic system design. As I was saying, now we might be working most often with this kind of system, where the inputs are random, the output is going to be something that we might not know as well. So in this dynamic system it really makes sense to start with the data instead of Figma, because now the data is the meat of everything. So we really want to understand the data, we might also want to start with a spreadsheet where we have the input to output mapping. We just want to understand the data first. Once we have the data we start to know what are the data variances, what are the scenarios we might run into. Maybe there is a situation where there is no prediction, or maybe there is a situation where the prediction is not good enough, it's bad, or maybe the prediction is completely wrong. So I think there are various scenarios that we might run into, and I think we as designers would really want to now capture those data variances in our designs.

[00:20:39] I would also like to encourage all of us to participate in the back testing. What I mean by that is, for example, you have this example, which is to see the pricing of a house. This AI which determines the estimated price of a house will have a lot of parameters, so based on, let's say, the location, our budget, it's comparing the pricing of the nearby homes and so on, so it might have a lot of different data that it could be using. But I think what might be very helpful is that back testing, which is to go into the historical data. Maybe in this scenario we take the last time the home was sold, and now play around with our AI product and try to see whether, using the historical data, whether its prediction in that timeline when it was last sold is actually matching with the pricing that it was actually sold for. So that is what I mean by back testing, and this kind of thing will really help us understand the accuracy of the model itself. So we as designers will just be closely working with engineering to do this.

Earning trust

[00:22:06] Okay, and then lastly I want to cover the earning trust part of the product. We want to really allow customers to do experimentation with the AI product. Because AI is really new, we want to allow customers to have more control when we launch this. We want to also make sure that the AI is not really posing any risk in the real world scenario. For example, the IBM Watson scenario, even that had some level of risk, because it was showing the cancer recommendation for the cure, but still it was in the hands of the oncologist experts. So we might want to really think about where we are putting the AI. It shouldn't be that it just breaks anybody's production databases, or whatever you're working in, so we just have to think about that.

[00:23:04] We also want to participate in the pricing model here. In my project that I recently worked on, I was closely working with the product managers to have this conversation. Because if we just come up with a pricing model that is, let's say, flat, but then the customer is actually not knowing what the AI is going to do, how the output is going to look like, then we might want to consider scenarios where they use it maybe for free for some time, and then, when they earn the trust, then they start actually using the product. So I think as a designer it's really important to again participate in this kind of conversation, so that it's not impacting the customer experience.

[00:23:52] Give control to the customer, I already talked about, and then also give them flexibility to turn on or off this feature as needed. We don't want to force them to use AI. We also want to get feedback from customers, how their experience was after using the product. And then I think what might help with earning trust is that, since AI could take time to show the results, it can take a little bit of, let's say, a few months or so, it might really help to have a way to show some kind of reporting to the customers where they can see the value of AI outcomes. They can compare: okay, now the AI is actually giving me this output, it's actually better than what I was doing before. So I think that would really help the customers to see the value.

[00:24:44] I think the Air Canada example, this was another example of failure, where Air Canada actually used a chatbot which gave wrong information. There was a customer trying to understand if there is a discount that they can avail. The chatbot told them yes, they can, and then when they went out to the customer support to actually get the refund, they denied it. So this was a scenario where the trust was actually broken here, and Air Canada then apologized, they maybe paid back to the customer. But again, it is really important to see these scenarios up front, so that the customers don't lose trust on the product.

Evaluating the AI experience and measuring success

[00:25:30] Now, evaluating the AI experience. I think this might be really helpful, we have seen a lot of examples now, so I just want to talk about this for a bit, that it's important in this scenario to see how the product is doing before the launch. So as a designer I would encourage you to have beta launches, maybe multiple ones if needed, to see how the customers are reacting to it, how the AI is actually helping customers. Also define the telemetry from the product usage, along with the qualitative feedback. So this will really help us see how the customer is reacting to it. At the same time I would say the feedback on the data is critical in this scenario, rather than just the interaction. The spreadsheet that we had created maybe to understand the data, maybe that is something we show to the customers, get feedback on that. We might also do A/B testing with multiple versions if needed, to see the positive and negative impact of the feature that we launched.

[00:26:37] And lastly, measuring the success. As I was sharing, an AI product could really take time to show the value to the customer, so in this scenario we might need to be patient enough to see the outcomes. Oops, sorry about that.

[00:26:58] Okay, so we might need to be patient enough to actually see the expected outcomes. The adoption rate: as compared to what we have been working on, we could be expecting the adoption rate, but then in case of AI it could be really unexpected and we might see some time, because the AI itself takes time in learning and in showing accurate results. So it could take time to see the adoption rate as per our expectation. The customers themselves will need time to get confidence on the product. So I would say track the same telemetry over time and then compare, are we doing good? So that's my tip on that. And then based on that, our designs would need to be iterated as the product gets better. So I think that was mostly about measuring success, and I just want to thank everyone. I would like to take any questions if there are, I know we are almost at time.

Q&A

[00:28:03] Host: Hi, thank you for that. I have actually loads of questions that I could ask, because one of the biggest challenges I find is, how do you uncover all of the different scenarios when you're dealing with a probabilistic system, and you don't know that nine out of 10 times it's going to answer correctly but one time it doesn't?

[00:28:22] Khushali: Yeah, true, I think that's a great question. I guess when I was working on the product I was asking the engineers to give me the real data. So in my mockups I wouldn't put just lorem ipsum, I think that's our enemy in this scenario. So I would just first of all try — we have a couple of categories already, we could think of the error scenarios, the no data scenarios, the prediction going bad. So we already have some scenarios. Trying to get data from the engineers, the real data, and then I tried to define the user experience. Because from the engineering side, if we just put it on them, they might just come up with an outcome that we as designers might want to change a bit.

[00:29:11] So I think I was just working very closely with the engineering team and having these categories which I already had in mind, and then I would ask the engineering team, hey, are there any scenarios that I'm not covering in my designs? So they might just give me more categories to add, and then I would just revise the messaging that we want to show to the customer. So I think the data was really important, just having those categories in mind and on the designs was really important.

[00:29:42] Host: And it's a great example of where, if it was segmented, you wouldn't be able to get as good a product, so having to work closer together is the success. We're actually over time now, so I just want to thank you once again for a great talk. I hope it was exciting and interesting for everybody out there, as it was for me. Thank you.