The Invisible AI Feature

Speaker A: Foreign. If you're caught up in the AI helps me design screens faster Buzz. You may be distracted from the real challenge of design in an AI world. I'll walk through how I designed a product where AI is used as an invisible feature. Sound simple? Well, we'll cover how to design with an unknown AI output, instill user trust and still make the user's task speedy and accurate. I'm Darrell Estabrook, 30 years in product design and the founder of Designing a platform for product designers who want to design with a why I coach designers into leaders through real time interactive product specific guidance. Find out more and get on board with a free newsletter@designy.com that's Design with a Y.com. So welcome to episode 19. Yes, that awkward age. The last year of teenagehood. Well, I'm glad you're here. So we've talked a lot about AI and the design process on the Daily Sprint. There's episodes you can go back and look at. It's all over the place, right? Gen AI is really a weak substitute for experience as a designer. There's so much that you gain. Sure, it has a lot of breadth and knowledge, but when it comes down to applying wisdom, that's where you come in as a person. So relying totally on Gen AI is not a real strong position to be in. It's also not a trustworthy decision maker. So understanding design decisions, it's proven to be very accurate, but not necessarily very systematic. And understanding why it made so many design decisions all at once. As a designer, you should know what every single one of those design decisions is so you can explain it to others, specifically stakeholders. And then Gen AI is something that really erodes your creativity. It's like when you have a muscle that you don't use, if after a while it just kind of gets weak. And creativity is something that you have to keep sharpening, you have to keep using it because when you don't, it's just easier just to turn it over to the machine. It hands you the answer. So why would you need to really think or question it? So that's not what we're doing here. We want design. It's very relatable. We're rational and emotional people, so our designs have to reflect that and how we go about doing it is really important. Even so, there's a potential for AI to help in things like design ops, design system management, um, the creation of design systems. Things where there's analysis, it's not quite there yet in a totally reliable way, but scaling is an issue. But it has potential. And the reason that it has potential is there's a lot of um, repeatable, uh, sometimes the fuzziness of it is really able to handle that and something that you can automate. It doesn't require creativity per se and so there's definitely potential. AI as a feature though is a real thing. You're probably using it every day to ask and answer questions. I've used it in a number of apps, a global app for IBM I worked on for machine part recognition. You got real time analysis of systems and things like that, where uh, image is really important in um, video processing, things like that. And the AI conversation in design that's been happening is a distraction from the reality of the greatest force that AI is a feature, not the interface. So how do you design a feature which is AI enabled? There's a lot of things that you have to consider such as the user interaction design. We're not dealing with static content, we're dealing with dynamic and even user affected content. So how do you represent that in a screen? And this other thing which is really huge is the user trust issue. So we see on every AI chatbox that AI makes mistakes. It's text there. It's one of the worst UX patterns that we're going to say, hey, trust this text that's here and know that the output is going to be unreliable. You know it's not, uh, people will cut corners, they're going to use it anyway. So how do we ensure that the results that are coming back are trustworthy or that the user is in a position to make a decision and not just hand over their thinking to the AI? So that's the thing that's confidence and accuracy is really a good thing. And making this non technical. There were a number of confidence ratings back in the day with percentages and things like that. It's like it's very complicated for the user to process and understand that. So how do you do that? How do you make it so intuitive? Well, AI as a chat interface is very rudimentary and you see it everywhere. It seems like a lot of these assessment tools or even dashboards where it's just ask a question and I'll give you an answer. It's very generic. Uh, it's very easy to put a chat box and say, hey, AI will just read your context and produce something. But it's this idea that you're talking to a person but it's really not a person. You're having a conversation, you're chatting, you're Back and forth. It's, it's a messenger but it's really not a person on the other side. It's very slow. Even if you do voice activated or just voice conversation, it's single threaded. So as you have this conversation you kind of go down a certain path. It's like a real conversation. How many conversations have you been in where you branch off and maybe you come back to the main topic but you don't really ever go back to the branch again. You never go back down and uh, explore something new on the conversation that happened five minutes ago. So when you're doing that for even design purposes, but really for business use cases, it limits exploration. A lot of times if we're going to put a chat, uh, interface in front of someone, we're, we're kind of asking them to explore the data and find out more. So it puts them on a track and really frames their thinking in a way that kind of limits what they can do. It's just accepted. So it might be really good for general queries. But a chat interface is not really for serious productivity. There's going to be processes to follow and, and depending on the industry that you're in, it's going to be very important to follow those processes. So that's going to be baked into the UI or at least in waypoints and guideways that way. So think of it this way, that chat AI is just one type of interaction with a product. It's not the end all, be all, uh, overt, kind of in your face. You are using AI. It's rather think of it as uh, behind the scenes delivering content and insights. It's really the powerhouse. It's game changing for dashboards, but we're still going to need dashboards. You're going to maybe have users ask more questions about it. But in the end if it's a business process, there's a lot that can be determined and known, um, still presented to the user and users are still going to need to get around the app. So that's not AI. Uh, you're not going to have dynamically changing menus and throw off user navigation. Content is still going to be relatable even though it's maybe generated. The user is going to have to interact with it in a way that makes sense in what they're doing. So that's going to require a bit more uh, care and you're still going to need to choose patterns and conform to the conditions like a mvp. And when you have customer feedback like you can design a Great interface and then need to do it for mvp, get it out in production. So what are you going to cut out? How are you going to make this really viable? And then customer feedback is going to come in and you're going to need to change things about the product. So those alterations are going to be very, very, uh, meticulously handled in a, in a craft sort of way. So I want to walk through kind of a case study of a product that I designed for an internal job audit app. So internal app to this company and their auditing job. So it's, it's definitely a thing that they do for their requirement and their standards. What I'm going to go through is approximately two and a half calendar weeks, so keep that in mind. This isn't months, it isn't even multiple weeks. It's not ours either, because there's a lot of discussions that have to happen. There's people on the other side of this design process that are important and they need to understand what the design's about, how it works, testing all sorts of things. So calendar time becomes a real thing. But I want to demonstrate that this is definitely possible and that we're talking about an invisible AI feature and where it really fits in. So see if you can find it as it's there. Although I kind of talk about it too. So the situation. Think of this in medical terms. There's patients that get home care, right? There's nurses that visit them on regular basis, uh, scheduled appointments, that sort of thing, but at home. And the nurses need to complete an assessment. So there's certain standards and things that they'll need to check up on and make sure that patient is doing well or changing, um, the care and how that's noted. So as they do that every month, regional directors are going to audit those nurses just to make sure that the patients are getting the care they need and really supporting the company's standards. So. So it's a very good business. It's nothing unusual here, nothing out of the ordinary. But the problem is that audits take time and the directors have a certain quota that they have to do each month. So they need to understand the patient situation and the type of care. So for each one, that context is going to matter. And they have company standards which require that they confirm that these nurses are meeting those standards. Totally reasonable. This makes sense. But there's multiple systems that hold this data and they have to. How would you know if they met the standard or not for this particular month unless you go in and research it? And so that takes time. All that takes time. It's good work and they're doing really well. But the question is, and this would be the purpose, as I talk about in the designing framework, how might AI be used to pull together these nurse assessments to check to see if they're met or not met by the company standards? And it might suggest a rating, but it would have to provide the evidence for the rating and allow the user to make the final decision. So how do they do that and decrease the time it takes to perform the audit by half or more? I mean it could be more, won't limit it just in half. And you have to use the current software platform, um, this is not green field. And uh, improve the overall usability and visual presentation because it's a legacy system. I think whenever we go into these things, the current system is the legacy, it will become the legacy because we're designing the new thing. Okay, so great. So that's the purpose. First thing out of the gate, get some context. Kind of new to me. I need to understand what goes on. So get some of that context through that purpose problem discovery bit. But I ended up meeting with stakeholders and understand the direction a bit more, get their take on it because they're feeling that pain and they also have the strategic need, uh, read the company standards, actually went first hand information, pulled those open, read them. Didn't have an AI assess it for me or uh, summarize it for me because it's not the same as understanding it. So I actually had a user walk through the current system and process, watch them do it, see what's happening and then kind of have the chance to ask them questions about where their pain points are and kind of the breaking down of the current process. Really great talking to a real person. You read documents, but then that helps inform the questions. And then I assess the brand elements in marketing material. So trying to get a look and feel that kind of goes in line with the company and what they're publicly stating, it's a nice bonus. I think internal apps don't necessarily have to be branded, uh, but they certainly can't use those marketing elements in the same way because we're talking about productivity app. And then the other part of context, which in this case with an AI feature is to understand the engineer's proof of concept. This is huge. They're working on how are we going to pull all this information in and create an efficient model, train the model, um, tweak the parameters. There's a lot that goes into that and so that's their work stream that's kind of happening in parallel, but yet the output that they're creating is critical to the design because that's going to be what I'm presenting to the user. So it's a bit of a building the bridge from both shores kind of a thing. I want to meet in the middle, but I'm going to need some of that because if I don't understand how the output is working, I won't be able to guide it and say, hey, this is the voices of this is not right. Or, um, it's not accurate and users need to react to it too. And then to be able to lay it out in the screen, I need to know what I'm dealing with and other things I might need to add to make the context clear. So a lot of thought needs to go into that proof of concept, and they need access to it, even just the output. So did I use any generative AI to help analyze any of these things? I already said no. It's taking those documents and creating user flows from them really undermines the natural empathy you have. And it's something that you end up infusing in the design because you're a designer. The other thing is it wouldn't really have access to the existing systems, so it couldn't really click around, got some screenshots and things like that. But it wouldn't have the full context of what I saw. And I can store that in my brain faster than I can document it. And it would have just taken longer to have it analyze the video and make sense of it in the same way as I could make sense of it by watching them. Plus, you pick up little things along the way as you're watching someone use the system. And I didn't and won't ever really use AI to summarize the meetings. I think it's a really big danger because it never catches the little things. The body language, voice inflection, even humor or sarcasm aren't really captured well in transcripts and summaries. And I find that the little things that are said, those don't make it to the summary, it gets summarized out of it. The AI won't pick that up. And so we're talking about a conversation with people and we're trying to summarize it in text. So that's not a good use. If I'm not in the meeting, I'll watch the meeting like one and a half or as fast as I can push it. But I will watch the Meeting in real time, uh, just for the experience. So it's always a good thing. So got the context started putting together my thoughts visually. So these take the form, not necessarily screen designs, but in the case of a flow, um, diagram of the current state, it's like, here's what I saw and it really maps it up, lets people in the future. In fact, questions came up later. They said, what's the current process? Able to pull that up immediately and walk them through it, because I know it now. And then I did a story mapping of the future state. And I don't know if I've talked about story mapping here, but it's a fantastic way of getting activities and tasks and having those very well structured in a timeline format. So it's a really good idea to compartmentalize the actions users are taking and the ways they go about doing it. It's also a great way to inject ideas of how we're going to change this from the current state to the future state. It's not a flow diagram, it's not really detailed, just sticky notes. And in doing so, I was able to demonstrate kind of taking two of their existing screens and making them kind of one, and then taking a single screen that had two separate features in it and splitting it apart. That seems like I got a net zero benefit. But actually it flipped the whole thing on its head, um, because the way the actual content and the way the users were navigating, where those weren't very efficient in that setup. And then I also asked some questions about these confidence ratings. How are we going to do that? I did have a sketch which was focused on this auditing screen. And the focus there was to show, hey, here's an idea to emphasize the evidence, and then here's a couple ways that we could make the suggestion clear. So the AI suggestion strong and weak, uh, as opposed to gradients of scale, uh, how confident are we now? It's a strong one, it's a weak one. That's a tricky one because we want the user to understand that just because the AI had a strong suggestion, that doesn't mean that it's correct. And that's where the evidence comes in. So we're really balancing these two things together real carefully. So getting confirmation on that, uh, from the stakeholder, they're satisfied and we can move to the next step, which is the first prototype. Now, there's a couple of moving parts in this. We're focusing on the audit screen because of all of that. The emphasis, uh, on the evidence and the suggestion. And so I use the evidence from an engineer proof of concept and baked it into the screens. What I really like about that is it's relatable information for the user test. Never use Lorem Ipsum. There's no reason to use filler text, especially in a user test. There's no way a user is going to relate anything to Latin or not even grammatically correct Latin. So having realistic content, even if it's not real content, we would like it to be real, but realistic is going to be so much better. And baking that in, that's, that's just um, that helps you as a designer to understand um, how much space you're going to have, make some layout decisions that way. Um, added this confidence badge, strong and weak. Um, provided a new way to navigate these standards. Kind of a full screen view instead of a single form list that they had before. And in doing all this I ended up creating a mini design system based on the company brand. Now however you go about a design system, you don't have to start out with the components, which is like, what now? I didn't do this in a vacuum. I started designing screens first because that's the main thing. That's what's going to be the end result. So we start there and as I'm going through it, as I'm trying different things, different approaches, the parts I start to reuse become components. So using Figma, right? Pick a design tool. But um, when you start to be able to use that design tools component system, it's like I'm going to repeat this anyway, even in the same screen. Better make a component. And then those components start to get properties as I need variations. So very natural approach to this thing. This happened in hours, not in days, not uh, in a single hour. But we're not talking about a huge effort, but we're talking about just what we need to be efficient and kind of setting the stage for the future. Solving the real screen problem, uh, first is a great way to get the design system the barest amount that you need instead of trying to backfill it in with the design. So I created several states of these screens, uh, in separate artboards or separate frames. And it's much easier to do this than creating complex components. So a lot of times designers get into the mindset that they have to create this realistic app in their design and the components get really highly. Well, they're complex but they're reusable before they even need to be reusable. So it's so much easier than creating complex components. And we're not building in the app. We're showing what the screen looks like when the user interacts with it in different ways. So different states of the screen. This is selected, this is not selected, this is open, this is close. And what you do when you get that is you have an instant prototype, because now you've shown every state. It's also easier to look at from a bird's eye view. Uh, engineers appreciate it much better instead of having to click through a prototype because they're going to miss a certain interaction. Just do the screens. You have them all there. And that leads us to the first user test. 30 minutes. So this was not a prolonged, uh, interview. It actually gave them the clickable prototype. So this is an expert user, very familiar with their current process. So that's helpful. Not a lot of explanation, not cold. Uh, they recognize immediately the content, so that's fantastic. And the UI layout was very intuitive because they understood the content. Nothing crazy. Content didn't require, like a whole new rethinking of things. But it did need to be different in order to organize these standards, preview the ratings and indicate completeness of the audit. So kind of three in one in this navigation. And, um, that's a complex thought to think through. Uh, if that would have been AI generated or not, I don't. I don't even know. And so the user successfully understood the evidence as it was presented. Uh, from the proof of concept, they were 99% confident, they 99% that the evidence represented the assessment because of key information that was in it. So that really helped test the evidence the way that it was being generated. And they had means to verify that evidence. They can click on it and see the source, and then they can even open the source. So that was all demonstrated through this prototype and it resonated very well. So the interesting thing is they thought the confidence badge represented the evidence, like how, uh, strong or weak. But I really intended it to mean the suggested rating was strong or weak. And so the reason they thought that was where the badge was placed on the screen. So think of it this way. Uh, just think of what that implies. A user test. I had it in my mind. Oh, yeah, this is very clear. They came back with an observation that was way off. I mean, it wasn't doing what we wanted it to do, what I thought it would do. And layout and composition matter, the placement of that on the screen. Eventually, in this next design option, I just changed the position of it and it made a big difference. Realistic data Mattered because there was no way they could have understood that, um, whether or not they could make the selection or not. And it was branded in high fidelity. I think that matters too, because it's not a distraction if it's just a wireframe or something like that. Uh, that's okay if you're testing something really high level. But in this case, we wanted to see if they could recognize the information. So really it really did matter. So that led to a new design option. It wasn't just as simple as moving the badge, although that's ultimately what I did. But in doing that, it created a cascade of design decisions that I had to rethink. So that was totally good, right? It's totally healthy, totally expected and totally needed. Because you can't just say, well, I'm just going to change this badge. I don't want to do a lot of work. I don't want to disrupt the screen. No, it's like, pull it all apart and let's reassemble it because we want to rethink this with this brand new design decision at the core, which is clarity of the selection of the AI selection. But this wasn't really as complicated as scrapping the whole layout. So even pulling it apart doesn't really mean we throw out everything that we thought that does work. But it does require reworking some of the positions of things. And I always find that doing that some of these cascading results, like moving other content around, really ends up being better for the whole screen. It's very funny how that works. So I added a few things to the prototype, like a selection screen with filters. Like, you got to get to these audits somehow. So what does that selection screen look like? More screen states. I added more standards and more examples of AI evidence from a new engineering proof, uh, of concept. So they're creating new proofs of concept as they learn and tweak. So that led to a new user test. Different user, 30 minutes still. And they understood the new navigation. Great. They understood the new recommendation badge and how it worked, the interaction. They successfully disagreed with an AI rating based on the evidence. So that was an excellent part of the test, which wasn't just to say, hey, can you corroborate with the AI selection? We want you to disagree with it because you are thinking and the evidence is showing. Ah, this isn't right. It really proves the expert, um, degree that they have. So awesome. And the evidence was understandable and actionable. So, uh, more confirmation that the proof of concept was working. But a huge discovery so think of this. There's two screens of different, you know, different standards, different evidence. But one screen had evidence which was very detailed and organized, which was fine. A second screen had evidence which was displayed in a way that matched up with the phrasing of the standard. So it was kind of like one to one. The standard had three parts, so the evidence had three parts. The other one was comprehensive and detailed. The user preferred the second one. They said it was more intuitive. It was easier to confirm that the standard was there because they just associated. This is the huge part. I wrote the second screen. I took a stab at it and said, okay, well given this structured evidence, uh, let's make it so that it's a one to one. The first screen was directly from the proof of concept from the engineers. So that, I mean that, that is huge. It becomes feedback to engineering that they could produce this evidence in a way that would align with the standards. So however the standards are structured, why don't you align the evidence that way? Great feedback. And from there then we start the engineering design workflow because now we're ready to kind of move into a more um, live data and final product kind of way. This is not a multi billion dollar product that is going live with lots of customers, but it is very important. It's going to be piloted with that in mind. You want to make sure that uh, you're going as fast as possible, but also as minimal as possible. We want to get more information and the next plateau from there was to use actual content in an actual audit kind of the beyond that. So given all of that, did you catch the invisible AI? Well, I mean we talked a lot about it. So there's no direct AI feature, there's no chat box, there's no generate a thing yet. AI was huge in this product and it's invisible because it helped by pulling in multiple sources and producing evidence for review as well as suggesting this rating. Like that's massive. Given the fuzzy nature of the, you know, the content, the assessments. The core of this was uh, designing in trust and the association between the rating and the evidence. So some of the challenges that you're kind of walking into this when you're designing an AI invisible AI kind of feature, it's kind of that unknown of the user's reaction to this AI summarized data. What would they do to it when they see it? How are they going to react? What do they want to do next? What don't they know? What's going to fall flat? And it's really the output Itself, you really don't have it. You need a proof of concept. You need some way that it's going to be realistic. Sometimes the term is synthetic data. I mean, however you want to do it. But it has to be realistic. It has to be something that the user can say, hey, this is in gibberish. I can actually make a decision that I would be making in the real app. I need to be able to do it here. And you need to test this with real users, not synthetic users, real users that have real experiences and vary in those experiences. So the prototyping was kind of funny. I actually tried to use Figma make. That did not work. No, it was too assumptive. Uh, it tried to make it such an awesome app that it just didn't. It crashed several times. You can really control the experience by building a prototype yourself. Besides, the prototype is just to communicate things that are going to happen in the app that you can't show in a static screen. Um, but there's many ways to demonstrate that. And so it doesn't have to be, uh, a completely interactive prototype. You can, and there may be some complexities, uh, situations where that's warranted. Figma variables, Figma screens, like all these tools are already there to use. The other challenge was in trying different approaches to see if the user would trust the assessment, whether they would see distrust and where they would need to dive in manually. So that was like a real critical thing. It's this very soft requirement of when will it fail and how can you recover? Because we want to design those things, we want to make it so easy for them to drill into that evidence, find the source material of all of that. What do we take away from it? Well, I think 80% of the product design is still in patterns and decisions made based on the shifting of the user testing and the requirements. Like that's not generative, that's not going to be solved generatively. You're still going to have to associate it. And if you learn that and try to feed it into your model that's designing for you, I don't know if it's going to handle all of that, especially these context windows. There's a lot more going on, there's a lot more conversations that are happening, uh, that can't be collected and distilled in a prompt. You spend more time distilling instead of just thinking and doing an invisible AI really means designing for trust and accuracy. You don't want users just to say, oh, it says it's high confidence click and human in the loop just becomes a drinking bird. You remember this keeps bobbing down and pressing the button now. And it's not just an AI chat window. That's now become the easy filler. Just put AI chat there. That'll solve all the process problems. Uh, the design process itself, it involves carefully understanding users and stakeholders and making interactive changes. This is fundamental. Even if you're using the most advanced AI to generate everything that you're doing, you're still going to have to understand people. And that is part of the design process. That's part of what we talk about all the time in the Daily Sprint and at Designing. So take all of this and see the next time where you have an opportunity to use AI as a feature and not just as a tool for designing. There's a lot more opportunity there than meets the eye. If you find this, ah, useful, this podcast, the episode, review it, like it, subscribe, whatever you do, however you do it, it's really going to tell other designers that they should be listening to. It'll help surface this podcast. But I'd really appreciate if you share this episode, any of the episodes. That would be great and really help designers know that you find this helpful. And remember, you can go to designee.com um, see the other podcast. I've got some articles up there. We've also got Designee Academy with some courses, other things to help you think through the design process and really leverage that communication that's required to make this successful. Sign up for the free newsletter@designy.com that's design with a y.com thanks for listening to the Daily Sprint. Remember, today is a great day to design with a why see you next time.