Let’s build a better UX for AI!

I'll be talking about how we approach building a user experience for AI. We think much can be done.

Introduction

But before I start, I'm Łukasz Borowiecki. I'm co-founder of TenSenses, where we do data science and AI. I'm also an active member of AI Working Group at the Ministry of Digitization, and I'm also a member of DAMA Poland, where we focus on data quality standards. So I have a few affiliations.

And my background is in quantitative research. I'm a sociologist. I have a PhD in economics. I'm this type of social scientist who does surveys, statistics, and things like that.

So basically, you'll see that our approach is different mainly because we are not heavy in computer science. We come from a different background.

The Role of Social Scientists in AI

OK, so just like an example of stuff that we did, For example, what does a social scientist do in IT?

So for example, we did work for T-Mobile when we wrote for them requirements on how to capture how people move around and by just using information on how mobile phone log into the system. And public transportation in half of Polish big agglomerations is planned based on outcomes from this project. So that's what social scientists do.

Focus on Explainable AI

1Since a while, we focus heavily on explainable AI, so on digging into how AI does its decisions. And we also had our conference in March on explainable AI. And it's as a playlist on YouTube. So if you're interested in topics like that, you can see it.

Current Use of LLMs and User Experience Challenges

Let's look how we currently use LLMs. So I'm asking the chat to give me some requirements on explainability for high-risk systems in the AI Act. OK, so it gives me the answer. So there are three articles, actually, in requirements. And it's great.

When I start to chat and I start to ask further questions, the thing is that I may lose the context. So I will have to scroll up and down to find some other questions. I'm pretty sure you encountered this.

Other thing, it's actually me who has to ask the question. And it's a problem because I have problem choosing a movie on Netflix. How can I come up with the right precise question for a chat? And when I get the response, it's me who has to verify whether it makes sense. So basically, I'm doing all the thinking, and I'm the assistant to AI. So it should be the other way around. But often, that's the way it ends up. So in our view, it's far from being the perfect user experience.

Innovative Approach to Building Interfaces

And what we did is we basically cracked into what are standard assistants? How are they built? And out of rugs, out of prompts, we come up with a different approach to building interfaces.

And maybe one thing. What we do is more into business processes, so into areas where you need to think a bit when you interact. There are many use cases where you just want a seamless experience and just want to ask the assistant a few basic questions. And for this, chat is perfectly fine.

Three Levels of Interaction

OK, so we think there are three levels. One would be improved search. So when I ask this question, I want AI to provide me with all the documents which are relevant. Because there is a search underneath which finds the relevant information.

And it's used in generating the answer. So why should it be hidden? when it can be shown to the user as a part of experience.

And it can be great because when I see the document, I see the title, I can click on it, and I show the actual PDF. So instead of me trusting AI that it comes up with the right answer, why should I use the AI just to find the right information, and me using the interface to see the actual document? So I don't worry about hallucination with this approach, because I see into the actual document.

And the important thing is to put some context information and titles into these boxes. So things like document types, title, maybe which page is it. When we do RAC, we can extract some information. So we can extract, for example, stuff like client ID, categories, whatever is relevant.

So we can extract this. And we could also put it underneath the title. So when I look at the interface, I see, oh, there's a chunk of information. I see the title.

I see the client type. So it's great because I just click and have the information. And I know why I came up with the answer.

Finally, if I have these boxes, why shouldn't I also have filters? So I can filter by client type or by document type. Why not?

And finally, it should be actionable. So I click. I see the document. I can download it. So with just a few clicks, instead of searching on SharePoint, with a few clicks, I have this PDF on the right page.

Use Cases and Actionable Results

And some use cases. So for example, you have a patient looking for drug therapies on the internet. Why shouldn't he see just a PDF with the right answer?

Or a doctor who's just looking for some specific information, why should he trust the assistant where he can look at the actual document? So these are cases like that. And when you look at the actual document, you don't worry about hallucinations, because it's not the answer from the chart. You look at the actual document.

Another thing is actions with one click. So often when I ask AI for stuff, like I ask him to do a summary for me, maybe translate to English, maybe propose a draft of an email, stuff like that. The answer is as good as my prompt. If I spend one hour typing a perfect prompt, the answer would be way better.

I'll have that time. So why shouldn't this be used as a standardized prompt under one click? So say, I won't waste time on writing two pages of a prompt. However, if it's standardized and it's under one click, why not?

And I can have versions of it. So let's say I want to have this summarized. I can have longer summarization, shorter. Maybe I just want to have extracting information who was involved.

And the thing is, I click. So I have this prompt underneath, which provides all the information on what should be generated. But the thing is, when I click, I don't give the instruction by using text.

I give the instruction using code because I click in an app. And it's great because it allows me for various integrations. I would never allow LLM just read what I write and just propose an email and send an email or just change some information in the data warehouse. No, because it makes stuff up.

However, when I click, I actually use code. So I can say that when I click, there is this prompt part. Maybe yes, maybe no.

But there is also the code, which I can integrate. And I can have various actions like that. So I just click, and something happens.

1And often, when we have business processes, we may have stuff like, I accept the case, I reject. Maybe I want to ask some additional questions to the client. So also, this could also be built this way that I make some actions, something happens, but also proposes me a draft of an answer to the client.

The Search Path and Actionable Buttons

And literally that's how we see it. So we have the search path where AI does the search for me and the outcome is shown to me in a neat way. I still want to have some interaction sometimes, but as much action as possible, I want to have here as actionable buttons.

And the thing is that when I click, it's not only faster because I don't have to type, but it's standardized. So instead of prompting in an artisanal way, I have a standard. It becomes like an industrial process.

So say we have 10 people who work on client cases, Everyone is prompting in his own way, asking the assistant various questions. They learn something. So from month to month, their prompting style may change.

However, with this, you have one quality standard. And if you don't like the outcome, what the AI generates, instead of calling these people and explaining to them, you should be prompting in a different way, you just change what is under this button. and you have different answers. It's not only standardized and the quality is standardized, but it's a manageable process.

When someone is leaving the company who has very good skills with using AI, it's not a big deal because the knowledge is in the process. When you have someone new, it's way easier to just show him where to click instead of teaching him how to prompt in our style and what are the right questions.

And finally, integrations. So you see when you click, then you can have various code underneath. So for example, I accept the case. I want the AI to generate me some draft of our answer. And I want to share it or send this draft somewhere else. When it's clickable, it's easier to, because there's code underneath, it's easier to integrate it in various stuff.

Integrations and Process Management

So we work mostly with Azure. And it's easy to build an app. and via these buttons trigger some actions in Power Platform. It's also easier to make some changes in the data set, change some status, and also use all those supporting tools which you have in Azure, like Purview or Datamart. So by clicking, it's way easier to do various integrations. So these are these three levels that for us in our UX are great.

Automated Documentation Generation

And maybe finally, once you fix the case from the client, maybe you want to build some documentation. Because some processes need documentation after you resolve a case. And people hate it, because it takes time. However, with this, you have like, You have all the information on how the case was resolved. You have information on which documents were used. You have information on which data was used. You even have logs, so versions of the documents, timestamp IDs, IDs of the users. So all of this can be included in documentation. And people would waste their time to do this with this approach. It's way easier to create it. And AI is great at summarization. So we can enforce whatever format we want. It can be longer, shorter. Maybe we want just some logs. So yeah, like here, full documentation, maybe one pager, maybe only system logs. So yeah.

Prototyping and Tool Selection

And the way we built is we prototype with Streamlit. We use the popular tools for building assistance. But also, inevitably, a power platform comes in.

You know your systems. I assume you know best what would work for you. Actually, the tool for the front is less important than the whole idea on how to build it.

Conclusion

And the conclusion would be that with this approach, the user is provided with relevant information, relevant context. So he or she doesn't have to rely just on the auto of the AI because documents or information is there.

When you generate something, it's created by predefined rules under a button which we can manage. Because we use these buttons and there is code underneath, we can do various integrations and automations. And with this approach, I have more control.

And you can even automatically generate documentation afterwards. And the great thing is it's the user who's in charge. So the user sees the context. The user clicks or not.

And he doesn't have to rely on some autistic AI which knows everything but just doesn't understand the world and makes up stuff. So yeah, that's my content information.

Contact Information

If someone wants to contact the company, that's also the QR code. Yeah, that would be it.

Finished reading?