‍Hello! Business is all about attracting as many customers as possible, but as we said in one of our previous episodes, . Some may negatively evaluate our product, waste our time, or use it in a way that may harm themselves or others.: Hello, in today's episode we continue the topic of patient experience. So if this is something that interests you, I invite you to listen to this episode. And our hospitality will be , which has been working for many years . I invite you.

‍

About Self-Auditing

‍

Perhaps you have indications that something isn't working. Perhaps you're convinced that such an audit would be beneficial, but you're not entirely convinced yet about, for example, collaborating with an agency like ours, or with a freelancer or expert.

Well, today's episode is for you. Because for those "do-it-yourselfers," we'll provide some tools to help them conduct a UX audit on their own.

‍

Ilona: But even if you believe your product is perfect and needs no improvement, I still think going through these principles, which we'll share shortly, will be a very valuable exercise.

‍

This will help you better understand your product, look into areas usually overlooked, and conduct an audit that reveals any potential gaps.

‍

Introduction to Nielsen's Heuristics

‍

Radek: Yes, there's always room for improvement. The guidelines we'll be discussing today are organized according to principles that are well-known in the market and are called Nielsen's Heuristics.

Ilona: Yes, we will be relying on knowledge compiled by Dr. Jakob Nielsen. These aren't the newest principles. They have already become established in the digital world and have stood the test of time. They are still current and universal enough that going through this list with examples and explanations will allow you to create such a checklist for your own product.

‍

One note at the beginning, before we start and delve deeper into our checklist... remember that a UX audit conducted by a specialist or by yourself will show you the scale of the problem, but it won't give you solution recommendations.

Radek: Yes, designers can give you such recommendations; they will look for solutions and indicate the direction for further development to address a given problem.

‍

#1 Visibility of system status

‍

Radek: Let's not drag this out! What can we do within the first heuristic, which states: show system status? What does that even mean?

Ilona: This means that our solution's interface should provide information about what is happening on a given screen. And here we're talking, for example, about operations in progress, processes, or... what can I actually do on this screen?

‍

A very simple, even trivial, example here could be showing the status of whether I am logged in or not.

Radek: Yes, or what stage I'm at, for example, in the purchasing process. This is very common in e-commerce projects where a large part of the buying journey is online. Am I currently in the cart, or pre-cart (because those also occur in the sales process)?

It's very important to show the user where they are.

‍

So, if you're analyzing a user's purchasing journey, or if you're within your own system—for example, one where the user needs to be logged in—then ask yourself if your interface clearly indicates where you are and at what stage in the process. Does the interface provide this kind of information?

Respect user time

‍

Radek: Another example on websites is all sorts of loaders, for instance, when data is loading.

‍

I once worked on a project where the main value was a report generated after a significant amount of user input. Users had to enter a lot of data into the system to receive this report, which concerned creditworthiness.

It took a long time for the system to process all the data and generate a good report for the user. It lasted quite a while, over a minute. On the internet, that's an eternity.

‍

So what can be done here to prevent the user from leaving or thinking something is broken? Online, we quickly grow impatient, and negative emotions intensify rapidly when we don't get what we want immediately.

‍

So it was very important to design a loader that would not only provide semantic information that something is happening in the background, but also tell me how much more time the system needs before I can see the result.

‍

#2 Maintain Consistency

‍

Ilona: Now we'll move on to the second principle. The second principle is to maintain consistency between the system and the real world. The statement is quite complex, but it's about language.

Radek: The sentence might not be complicated, but these are the heuristic traps that I notice and point out, because ultimately, what's the point? It's about  for whom we're dedicating a given solution, a given interface.

Ilona: Yes, the phrases and formulations used should be adapted to who our audience is. When auditing your product, pay attention to whether you're not, for example, using jargon or language that your audience has no chance of understanding.

Maybe they have doubts? If you have doubts while checking the key path, it means that the text will likely be incomprehensible to them.

Radek: It's very difficult to verify something like that because, as industry specialists, we use such specific language every day. And for us, something like website structure or...

Ilona: Flow. We'll do the flow of something... we love that.

Radek: To proceed, swipe... various influences from the English language. It's hard for us to see that it's actually jargon and that some people will genuinely struggle to understand something, because we just grasp it, and it's clear to us.

Ilona: The swipe example shows how important it is to know who our audience is. If we're talking to teenagers, using the term swipe will be perfectly understandable. But if we want to create a general application for everyone...

For example, imagine if mObywatel's instructions, addressed to all Poles, said, now swipe right or left... that would be a bit poor.

Mind your words

Radek: I brought up the phrase website structure and functionality because I recently saw a survey in an audit that directly asked about the website's structure and navigation.

It was an e-commerce store, so people don't really go to a website and think: oh, what great navigation and site structure. Maybe also the architecture and UX, and everything combined.

We need to be careful about that. Let's not use such terms. And that's very difficult.

We can say that we know our target audience very well and decide to use a specific language. Which is great, because then we have that target audience.

But there are few products with such a very specific target audience. Maybe SaaS products, or those dedicated to particular industries...

But most of the products I encounter in our daily work are products that should pass the five-year-old test. That means a five-year-old should more or less understand what it's about.

Ilona: I would also suggest checking one more corner. When you're conducting such an audit, check the error messages displayed on the page when a user performs an action incorrectly or if some information is missing and they can't proceed. How is the feedback formulated for our valued customer, patient, or simply user?

Radek: What fits this state of alignment between reality and the system are also online stores. It's worth considering how store shelves look, how product categories are divided.

How they are placed next to each other in a category, for example, in your navigation or categorization. It's very important that, for instance, pajamas are next to underwear, not next to...

Ilona: ...sportswear, which sometimes happens.

Radek: Exactly, so it's worth checking.

#3 Give the user control  

Ilona: The third principle from our checklist is: give the user full control.

Let's face it, users often do things by mistake. They click a button, for example, to check what's behind it, what actions are available. And sometimes they didn't even plan to perform that action.

That's why this principle (give the user full control) states that you should allow them to return to the previous state. Give them the option to perform, to use some jargon again, an emergency exit, meaning a return to the previous screen, the previous state.

Especially if it's an important action, such as deleting an element.

Radek: Even simply going back to the previous tab, for example, to a listing, which is a list of products displayed on the tab. It's important that we provide the ability to control this.

Control pop-ups

Radek: And here, bad examples often come to mind. For instance, pop-ups appear with a tiny "X" to close them, and it turns out to be, for example, sign up for the newsletter.

There are many such actions that can be presented to the user, but without really explaining what they're about. For example, you might accidentally sign up for a newsletter, even though the entire pop-up gave the impression of something else.

Ilona: Yes, but the newsletter is an interesting case, because sometimes, especially on a small screen, we get a huge pop-up sign up for the newsletter, with no way to close it.

How can we talk about giving the user any control here, when we force them to sign up for a newsletter, because otherwise they can't use the site?

Radek: My favorite is when you try to unsubscribe from a newsletter, and the interface is so designed that you actually don't want to leave the newsletter... so sign me back up.

Ilona: Yes, we also have an episode about so-called dark patterns. We often talk about it.

Radek: Dark patterns... sounds a bit like the darknet.

Ilona: Kind of. It's in the same vein. We have an episode about it, and we'll link it in the description.

Radek: Pay attention to whether the operations you provide to the client/user on your interface... do they give them full control over the decision for a given operation, or do they rather force unconscious actions upon them? This is very important.

I understand that you might want people to sign up for a newsletter, but if someone signs up for a newsletter and didn't want to, they'll be annoyed. And if they're annoyed, they'll tell someone else. And then you're creating bad PR for yourselves, and nobody wants to risk that.

Ilona: Yes, exactly. It will be the same if they perform an action that significantly impacts how they use the product, and they can't undo that action, nor do they see the consequences of that action.

#4 Interface Consistency

Radek: So, the fourth one... the one about maintaining interface standards and consistency.

Ilona: This point is mainly about system consistency. System consistency sounds grand. We all know it's very difficult to maintain throughout the entire development cycle of a digital product or service.

But I've often seen that in products, especially large ones, the same action we perform is called something completely different.

‍

Make up your mind.

‍

Radek: What do you mean by "actions"?

Ilona: I'll tell you. Recently, we even standardized the display of change history for one of our clients. One of the requirements for this application is that all actions performed must be saved in the system and be able to be reproduced later. Actions such as deleting, adding, or editing an element. An element could be, for example, an invoice or a photo. This is a B2B application, and it's clear that if we do something wrong, delete something, and it significantly impacts the project, potentially leading to additional costs, companies usually want to know who performed that action and when. And we had a really cool feature, which was the change log — the history of changes. But this change log was called differently in various parts of the application. Sometimes it was just a log, sometimes it was a change log...

Radek: Changing log...

Ilona: Changing name... And that was interesting too, because we had the exact same function, but it was named differently in various places.

We're confusing our user because they saw that specific action in one module. Now they're looking for it, and it's either gone or has a different name. And that's not good.

Radek: Or proceed in the cart, or in some form. Then you have the next step, and you really don't know what's going on.

But I think this doesn't just apply to naming conventions. These standards also include, for example, color, right? When working on an interface, we try, for instance, to maintain the same color scheme for active buttons, links – basically, anywhere you can click to trigger an action.

‍

These colors are bright and reserved for such active elements. And if, for example, there's a lack of consistency between these elements, the user might click on something that isn't clickable. And that can be annoying. Or, conversely, they won't click on something that *is* clickable because it might look like part of a graphic, for instance.

Ilona: We also had an example where we designed a rather complex configurator. This is also an example of e-commerce, but B2B.

Help the customer click

Radek: E-commerce has a lot to answer for.

Ilona: There's also a strong association that if it's an audit, it's for e-commerce. That's a fairly common practice.

But this is a B2B product. The moment we delved into this product to understand what was going on, it turned out that the place where we could test the product in action looked exactly like a graphic.

After integrating product analytics, it turned out that no one was clicking it because, ultimately, they didn't know it was clickable. Thanks to such an audit, we found this issue, and all it took was to change its appearance. We gave the user clear information on what they could do with it. And people started clicking it.

Of course, it wasn't that the feature wasn't needed, and that's why they weren't clicking it. They were asking support for help.

Test your call to action

Radek: I think a simple exercise would be to check the basic call-to-action buttons, meaning those that trigger the main actions.

And check, for example, if we have consistency at the level of the main button that says buy, proceed, sign up. Then move on to other active elements and check if those differences appear there as well.

‍

Ilona: If we have doubts about whether something is visible or clear on a given screen, we can always ask someone. Of course, in an ideal world, it's best to ask someone from our audience, from our target group.

‍

But if we don't have anyone from our target audience readily available, we can also ask someone we know about a small part of it.

‍

But the thing about consistency is that you have to maintain it practically all the time, when creating new projects, changing modules. You have to refer back to what already exists so as not to turn our service or digital product into a Frankenstein.

‍

And if we are doing it, at least we know why and when we will exit this state. It's also my approach that sometimes it's worth changing something on one screen, checking if it works, and only then changing it everywhere.

Radek: But then you are aware of it, you have a plan in all of this...

Ilona: Yes, the fourth principle: maintain standards and consistency is absolutely something we should do every day.

#5 Prevent Errors

‍

Radek: We're at the halfway point. The fifth principle:  is about helping users avoid making mistakes. Users can make such errors when, for example, entering a sequence of numbers, dates, or phone numbers.

‍

The interface should support users in not making such errors. The reality is, we live at a very fast pace now. A lot of these interactions and data entry happen on the go, on the phone.

‍

So how can our system support ensuring that data is entered correctly?

Ilona: Or once an error is made, how our application handles it...

And precisely for this point, Nielsen himself identified two types of errors. He said that one type of error is minor errors, so-called typos. These are things we do when operating on autopilot.

Then we have more serious errors like skipping a field, incorrectly entering a phrase, and trying to search for it.

In such a case, the interface can react in two ways: it can either return an empty search result and say that the phrase doesn't exist, or it can correct us and return search results that are most similar to the phrase the user is trying to enter.

So, for example, pay attention to your search engine. How does it behave and how does it handle minor errors like typos, versus more significant ones?

Radek: Enter errors and see what happens in your system.

Anticipate errors

Ilona: And I'd like to elaborate on this point a bit. Preventing errors is super important, but on the other hand, when we usually test our product or service, we follow the so-called happy path. Everything goes smoothly then. We enter all the data because, after all, we know the product. We know that this form requires specific data.

But if you want to audit your system yourself, it involves finding areas and intentionally making errors to see how your product handles error management.

Remember that the context in which users interact with the product matters, and it might be, for example, on the go. Especially with mobile apps, we might be tapping while crossing the street at a traffic light.

Radek: So we list potential errors and test if our system helps us resolve them and avoid making them. We simply check how much the system supported us.

Ilona: Exactly, and in places where errors might potentially occur, either because we know about them or we have reports from support... there are things that we, as UX, have already figured out.

For example, underlines that show how many characters we should enter when providing a postal code after selecting Poland as the country. Phone area codes, PESEL (national identification number) — these are also things we've already figured out, and it's worth sticking to such good practices.

Radek: I think that's clear.

Time for an audit!

‍

Radek: I think we'll stop at this halfway point today, because we'll discuss the remaining five heuristics in the next podcast episode, which is coming soon.

‍

Ilona: And now for a task, dear listeners! Take the five-point checklist we've included with this episode and try to audit your digital product. I'm very curious to see how that turns out for you. Thank you for this episode, and see you in the next one.

‍

Radek: Talk to you later. Bye.

‍