Podcast Design i Biznes, Radek Rejsel. Witam Cię serdecznie.

‍

Ilona: Cześć, Ilona Skarbowska.
‍

Radek: New season, new year, and a different approach to our podcasts. From now on, all our episodes are tested with our audience before they're produced, or even developed and recorded by us. And we'll be talking a bit about that today, won't we, Ilona?
‍

Ilona: Yes, today's episode, the first of our new season, will cover this topic. We'll also be talking about how we test our episodes.

‍

Introduction

Radek: And all of this is to show you how UX, the field we specialize in, can help you create a sales and marketing strategy.

And today, we'll practically tell you in which 3 areas UX can help you.

• The first of these is "what", meaning what information can be used to effectively develop sales and marketing activities
• The second thing is "when", meaning when to use this information throughout the user journey
• And the third area is "how". How to speak to the user, to our buyer persona, so that they truly understand and feel that the message is for them, not

We invite you to listen.

‍

UX in Marketing and Sales

Ilona: Yes, it's well-known that sales and marketing go hand in hand. There's no need to convince anyone of that. But then we, UX designers, come along, and I have a feeling that UX is a bit like the younger sister to those two older ones, sales and marketing.

It's also a somewhat underestimated sister. And from my perspective, it can bring significant value when planning sales and marketing strategies.

It's great that today we'll talk about our perspective, which is the perspective of owners who create UX, marketing, and sales strategies. This bird's-eye view allows us to see how these three areas connect with each other.
‍

Radek: Yes, this is a very important point for me. For a few years now, I've observed that marketing and sales can lose a lot if they don't leverage the potential that UX offers. At least in the situations I've had the opportunity to experience. And now I see that I was indeed right.

‍

Theme 1. — What?

Radek: What does this potential entail? Perhaps we can smoothly transition to the first area we'd like to discuss.

What information can be used in the sales and marketing process to reach our customer, or the so-called buyer persona?

And now, completely from our project perspective… We deal with designing solutions, which means we solve problems. The success of our project and our actions will depend on what problem we solve.

Will we solve a problem that is truly pressing? One that is real? Or will we find a solution that satisfies a need?

So a lion's share of our work is analyzing what problem and what need we need to solve. This will determine the subsequent success of our actions, right?
‍

Ilona: As they nicely say in analytics: garbage in, garbage out, which means that if the input data is poor, the output data will also be poor. This nicely illustrates that choosing the right problem is super important.

‍

Understand your client

Radek: Exactly. Let's look at the marketing process now. To interest our client, we need to talk about their problem. For example: Do you have a headache? Do you have indigestion?…

All advertisements say that, but it cannot be something that isn't true about our persona, about our client. It must be very well measured. It must be very well analyzed and selected.

What we do when we try to find this out isn't just, for example, reading desk research, market reports, analyzing a mass of data…

All of this is, of course, important. The experience we have with our clients is also important. Especially with B2B, where you talk directly with the client.

However, what we can do, and what is a significant and very valuable part of our work, is seeking answers and delving into the topic directly with the client.

So if we have a user of a product, e.g., a digital one, we need to reach them. We need to sit down with them, talk, and ask why something is important to them, or why something is a problem for them.

These are in-depth, individual studies that happen on a smaller scale. These are not quantitative studies where we need a large sample. Here, for example, six people are enough, where we delve into the client's problem with them.

This is a great way to gather a lot of insights and create a product. And if we have such data, it's excellent fodder for marketing or sales.

We have arguments that we can use in this process. We have key information that we need to convey to bring that user closer to us.

Ilona: Marketing, of course, also has its own tools and research methods. Focus group research is often used in marketing. But today we don't want to talk about those, only about UX tools. UX tools include, among others, the individual in-depth interviews you mentioned.

‍

In practice — Warsaw-Radom

Ilona: To give a specific example… Some time ago, we carried out a project for one of our clients. These were Polish airports, where we designed a website and a mobile application for the Warsaw-Radom airport.

One of the initial stages in this project was concept testing, which included design tests, tests of information layout on the website.

Since we couldn't draw on existing data because it was a new website, we had to rely on the desk research you mentioned. But also go to the users and conduct interviews with them.
‍

Radek: So it wasn't just a new website, but also a new airport. That was really just the tip of the iceberg.

Ilona: So, with our digital component, we went to users to show them the design concept. But besides discussing the design, we also talked generally about the airport itself.
‍

As a warm-up for such an interview, we always ask more general questions before moving on to specifics. And it was precisely in this first part, during the general questions, that we clearly highlighted the concerns people have about using the airport.

By interviewing eight people, we were able to identify recurring themes regarding what truly prevents them from even considering flying from Warsaw-Radom Airport.

With the information we gathered from our concept report, we were able to create an additional report for marketing that highlighted consumer insights and concerns. Marketing can then leverage this to address these points in their communication.

‍

UX and Marketing Collaboration

Radek: That's a really good example.

It's interesting that on numerous occasions, when I worked on projects that involved in-depth research, and had absolutely no access to a marketing department, I felt that the project or product stood to lose a lot.

I just remembered when we had conversations on Clubhouse. We had our own room there. There was also a room that I visited every day. I think it was called... something about marketing.

Yes, because that's when I was already sniffing around, curious about that area. It wasn't my field at the time, but I was curious if we operated on similar principles, or if there was some kind of symbiosis.

Być może ja tej symbiozy jeszcze nie zaznałem, ale jest pewien branżowy standard UX and marketing collaboration.

But it turned out that wasn't the case; these are outdated ways of thinking. That marketing perceives UX as a field solely focused on creating mockups.‍

Ilona: This is a significant limitation, and it also highlights just one specific area we focus on. But in reality, we forget about the entire research and exploratory branch that UX also effectively utilizes.
‍

Radek: Yes, he makes the most of it because he has to.

If we don't properly identify our problem, the solution we design or propose will fail. ‍

Motyw 2. — Ścieżka użytkownika

Radek: No dobrze, to teraz drugi motyw. Drugi obszar związany z tym, kiedy powiedzieć o tych informacjach, które wyciągnęliśmy.

Jak sobie popatrzymy na ścieżkę użytkownika z naszym produktem, to zobaczymy, że ona nigdy nie zaczyna się i nie kończy na produkcie samym w sobie.

Na przykład jeśli mamy aplikację, to ścieżka użytkownika nigdy nie zaczyna się od momentu, kiedy użytkownik odpala tę aplikację. Jego relacja z tym produktem zaczyna się o wiele wcześniej, a kończy się dużo później po zakończeniu użytkowania.

Jest pewien punkt, w którym ja w ogóle zaczyna myśleć o danym produkcie. Ten produkt pojawia się w mojej świadomości. Bardzo upraszczając, jest to ten marketingowy obszar.

Jest ten moment sprzedażowy, kiedy decyduję się o zakupie. Jest ten moment typowo UX-owy, kiedy użytkuję ten produkt.

W naszej pracy musimy narysować tę ścieżkę użytkownika (customer journey). Musimy zidentyfikować, gdzie mogą wystąpić, jakieś problemy. Musimy zrozumieć, co użytkownik wie wcześniej o produkcie.
‍

Ilona: Ja bym jeszcze wyróżniła tutaj dwie rzeczy, bo możemy narysować tę ścieżkę użytkownika od momentu wejścia do aplikacji. I wtedy zwykle zaczynamy od boardingu wewnątrz aplikacji… Co się dzieje, jak już tę aplikację zainstaluję.

Ale można to narzędzie wykorzystać także do marketingu i sprzedaży, żeby narysować wszystko to, co się dzieje wcześniej.
‍

Radek: Tak, właśnie do tego dążę. W naszej pracy skupiamy się na tym, co jest, powiedzmy „w środku”. Czyli kiedy użytkownik już korzysta.

Ale my musimy wiedzieć, co się wydarzy wcześniej albo bardzo często też to ustalamy. Musimy sobie to wyobrazić dokładnie. I teraz, jeśli nie mamy tutaj przy sobie osoby od marketingu i sprzedaży, to my sobie wymyślamy. Tak to wygląda, tak naprawdę.

‍

Badania i warsztaty

Radek: Na szczęście są takie sytuacje, w których siadamy z działem albo z osobami, które odpowiadają za rozwiązania dotyczące marketingu i sprzedaży i jesteśmy w stanie z nimi to zrobić, przeprowadzić.

Zazwyczaj robimy to tak, że organizujemy warsztat, który dotyczy właśnie ścieżki użytkownika i projektujemy wspólnie taki lejek informacyjny. Czyli co się dzieje na etapie marketingowym, kiedy użytkownik dopiero buduje swoją świadomość na temat produktu.

Tam będziemy wsadzać te informacje dotyczące pewnych bolączek. Ale na bardzo ogólnym poziomie. Potem jest sprzedaż, czyli musimy wyciągnąć argumenty sprzedażowe, które…
‍

Ilona: … pogłębią to, co powiedzieliśmy wcześniej.
‍

Radek: Tak, ale też sprawią, że użytkownik nie zawaha się i kupi.
‍

Ilona: Czyli musimy wiedzieć, jakie ma obawy.
‍

Radek: Tak. I o tych obawach dowiadujemy się wcześniej, bo na przykład przeprowadziliśmy z nimi badania. I te insighty można wykorzystać w tym procesie… tak, wracając jeszcze do tego pierwszego etapu.

Potem oczywiście projektujemy to, co się dzieje już w samej aplikacji. I teraz mówię tutaj o lejkach informacyjnych, bo to jest klucz. Dlatego, że użytkownik nie może dostawać tych samych informacji na tym samym etapie. Te informacje muszą być podawane jak przez lejek…

Ilona: Albo w kółko tych samych informacji, bez ich pogłębienia.
‍

Radek: Dokładnie. Więc my musimy być tego świadomi kiedy projektujemy produkt lub kampanię. I tak kalibrujemy naszą sprzedaż.

Brak spójności w marketingu

Ilona: Jest częsty błąd, który wynika z braku takiej współpracy. A mianowicie, kiedy mamy piękną kreację reklamową z jakimś konkretnym hasłem. Po czym wchodzimy na stronę, gdzie mamy zupełnie inny komunikat, inne wartości i mówimy o czymś zupełnie innym.

I wtedy my, jako potencjalni klienci przez ten brak spójności mamy pewien niepokój w sobie. Szukamy, chcemy pogłębić temat, chcemy dowiedzieć się więcej, o tym haśle, które przed chwilą usłyszeliśmy. A trafiamy do miejsca, które jest zupełnie inne i mówi o czymś innym. I tracimy zaufanie.

‍

W praktyce — Nowa Era

Radek: Dokładnie. Przypomina mi się jeszcze taki projekt, który mieliśmy z naszym klientem Nowa Era, która też zaprosiła nas do takiego wyzwania stworzenia ścieżki onboardingowej do produktu.

Tam było takie wyzwanie produktu, który z jednej strony był klasycznym podręcznikiem i książką… Nowa Era jest wydawnictwem, które produkuje właśnie takie materiały edukacyjne… A z drugiej strony ma taką cyfrową część, która pogłębia tę wiedzę.
‍

Ilona: Nowa era jest bardzo nowoczesną firmą, która chce łączyć ten świat realny, czyli podręczniki fizyczne ze światem cyfrowym. I w tym projekcie naszym zadaniem było między innymi, aby pomóc im zaprojektować, jak taki lejek mógłby wyglądać.
‍

Radek: Jak można sobie wyobrazić, te narzędzia cyfrowe w edukacji „oficjalnej”, państwowej… to jest naprawdę innowacyjna rzecz. To, że Nowa Era łączy próbuje dodawać cyfrę, jest super.

Natomiast zgłosili się do nas z wyzwaniem lejka onboardingowego, ale w produkcie.

Szybko odkryliśmy, kiedy usiedliśmy sobie na warsztatach, że potrzebujemy kogoś od marketingu, że potrzebujemy kogoś od sprzedaży. I tak naprawdę w pewnym momencie na warsztatach siedzieliśmy w dość dużym gronie.

‍

Moc warsztatów

Radek: To, co jest ważne w tym przykładzie, to to, że my pracowaliśmy warsztatowo. Czyli my nie siedliśmy sobie w kółeczku i nie uprawialiśmy burzy mózgów. To nie było zwykłe spotkanie.

To jest bardzo ważne. W naszym świecie warsztat to nie jest jakieś wyświechtane słowo. Moim zdaniem jest obecnie absolutnie nadużywane.

Warsztat to nie jest po prostu spotkanie, tylko to jest naprawdę ustrukturyzowane spotkanie, które ma cel. I do tego celu prowadzi nas konkretna agenda, czyli zadania, które musimy wykonać.

Oczywiście ta agenda może się zmienić, możemy coś odkryć. Ale mamy jakiś konkretny cel, konkretny czas i to wszystko jest moderowane przez osobę, która prowadzi ten warsztat.

Taką ścieżkę użytkownika, którą właśnie zrobiliśmy przypadku projektowania tego lejka onboardingowego dla Nowej Ery… zazwyczaj prowadzi się warsztatowo. Inaczej byłoby to bardzo trudne.
‍

Ilona: Powiedz Radek, co było takiego fajnego w tym projekcie. Co najbardziej ci utkwiło w głowie?

Radek: Wiesz, co najbardziej mi utkwiło w głowie? To jak porcjujemy te informacje. Użytkownik z każdym przystankiem ma w swoim bagażu już jakąś wiedzę, jakieś informacje. I on nie potrzebuje, żebyśmy mu to powtarzali na każdym etapie. On już je ma.

To było fajne, że można było naprawdę stworzyć taki lejek… nie wchodząc w szczegóły, bo myślę, że dążysz do tego, żeby powiedział jakieś konkretne rzeczy…
‍

Ilona: Ale chyba nie mamy zgody klienta, żeby wchodzić w konkrety, więc zostawmy to…

Radek: Ale zapraszamy, szczególnie osoby, które mają dzieci, albo maturzyści. Nowa Tera Matura, myślę, że to fajnie wygląda.

Ilona: Tak, można kawałek naszego produktu zobaczyć na żywo.

Radek: W zasadzie nie naszego, ale rezultat działań z naszym klientem można zobaczyć na żywo.

‍

Motyw 3. – Jak Mówić?

Ilona: To powiedzieliśmy sobie o tej drugiej warstwie.

Radek: Tak, jest trzecia część. Powiedzieliśmy sobie o tym, co mówić, kiedy mówić… czyli ta customer journey — ścieżka użytkownika, jak tworzyć lejek informacyjny…

Ale mamy jeszcze ten aspekt „jak mówić”. Bo to też jest absolutnie ważne. My w pracy nad naszymi produktami też szukamy odpowiednich stylów. Szukamy odpowiednich archetypów, które będą rezonowały z tym naszym odbiorcom.
‍

Ilona: Co to znaczy, że szukamy odpowiednich archetypów?
‍

Radek: Tak na dobrą sprawę produkt musi w jakiś sposób odpowiadać charakterologicznie…  Wiem, że to brzmi bardzo enigmatycznie. Produkt ma charakter? No ma. Ma jakiś swój styl.  

I przez różne części produktu (formalne, nieformalne) możemy ten styl pokazywać. I to może być między innymi komunikacja.
‍

Ilona: A to jest fajne, bo to jest stricte działka marketingowa.

Mój ulubiony przykład to wszystkim nam znane dwie sieci fastfoodowe: McDonald’s, który ma komunikację bardzo rodzinną i ciepłą. Oraz Burger King, który w swojej komunikacji jest bardziej waleczny, buntowniczy. Tak mówiąc archetypowo, może trochę męski.

Ale to fajnie pokazuje, o co chodzi w stylu komunikacji. Mamy dokładnie ten sam produkt — burgera. Tylko on jest opakowany i komunikowany do innych odbiorców. Tutaj mamy rodzinę, a tutaj mamy młodsze buntownicze osoby.

No i teraz faktycznie UX może pomóc marketingowi w wypracowaniu takiego stylu.
‍

Radek: Co więcej, jest masa elementów, które składają się na ten styl, który używamy. Np. kolory, zdjęcia. Ale też istotą samego UX-u jest content. Czyli co jest napisane, w jaki sposób mówimy do użytkownika.  

O tym jest jeden z naszych odcinków z Ewą Wasilewską. O UX Writingu. Zapraszamy do wysłuchania odcinka o tym jak interfejs może mówić do użytkownika i jak jest to super ważne.

No więc jak możecie się domyślać, my też mamy wypracowane metody i procesy na to, żeby te komunikaty i styl komunikatów wypracowywać.

Znowuż cofnę się do tych badań, o których mówiliśmy i opowiem może o takim projekcie, który kiedyś miałem okazję realizować…

‍

W praktyce — Visa

Radek: To był taki bardzo „komunikacyjny” projekt, którego efektem końcowym był projekt ulotki. Jest to projekt robiony w ramach inkubatora innowacyjności Visa prowadzony przez Innovatikę, z która wtedy ten inkubator współtworzyliśmy.

Inkubator miał na celu wypracowywanie takich standardów rozwiązań dla ogólnie pojętej branży finansowej. Brali w nim udział przedstawiciele różnych banków, instytucji finansowych, które mogły coś wyciągnąć z tej wspólnej pracy dla siebie.

To był czas, kiedy wchodziła Polska Bezgotówkowa i była taka kampania dotycząca terminali za 0 zł. My mieliśmy do przebadania właśnie grupę docelową, która byłaby głównym beneficjentem tej akcji, czyli mikroprzedsiębiorców i JDG, czyli jednoosobowe działalności gospodarcze.

To było parę lat temu i w mojej świadomości i inkubatora generalnie… przyjęliśmy, że jeśli ktoś zakłada biznes, to jest biznesmenem. Ma łeb na karku…
‍

Ilona: Chodzi w garniturze albo garsonce?

Radek: Może nie aż tak. Ale rzeczywiście, nawet jeśli myśleliśmy o fryzjerce, która ma swój salon, to jednak myśleliśmy sobie, że to jest osoba, która nie jest takim zwykłym tzw. zjadaczem chleba.

I przeprowadziliśmy taką serię pogłębionych badań. Wiele segmentów badaliśmy, więc naprawdę było tego sporo. I szybko się okazało, że jesteśmy w ogromnym błędzie. Oni nie używają wcale innego słownictwa niż normalni ludzie.

Ilona: Niż klienci salonów fryzjerskich.

Radek: Dokładnie, my nie mogliśmy im zaoferować komunikacji, która byłaby bardzo profesjonalna. Oni ledwo rozumieją zagadnienia związane z prowadzeniem działalności. W tym sensie technicznym jak płacenie podatków, sprawy urzędowe. To już jest dużo.

Więc my musieliśmy stworzyć tak na dobrą sprawę komunikaty oparte na bardzo prostym języku, zero-jedynkowym, mocno adresującym korzyść.

I ona musiała być bardzo charakterystyczna dla tych grup, bo jednak trochę inaczej myśli osoba, która prowadzi salon fryzjerski, a inaczej osoba, która prowadzi gabinet stomatologiczny, inaczej warsztat samochodowy.

Aczkolwiek tak jak powiedziałem wcześniej, to nie są osoby super profesjonalne w tym sensie, że nie mogą używać skomplikowanego języka. One po prostu potrzebowały prostego, zwykłego, codziennego języka.
‍

Ilona: Nie używają skomplikowanego języka w pracy, dlatego komunikowanie się z nimi w sposób profesjonalny, używając żargonu czy pojęć finansowych mija się z celem, bo ten komunikat nie trafi do.

Radek: Podsumowując — nie B2B, tylko B2C.

‍

Podsumowanie

Ilona: Podsumowując dzisiejszy odcinek, najważniejsze jest to, że marketing, sprzedaż i UX powinny żyć ze sobą w symbiozie. Wszystkie działania, które planuje firma na poziomie strategicznym, czy już na poziomie operacyjnym powinny być ze sobą połączone i te działy powinny ze sobą rozmawiać.

Opowiedzieliśmy wam też o tym, jak narzędzia projektantów UX mogą wspierać tworzenie takiej strategii dla marketingu i sprzedaży. Powiedzieliśmy o tym, jak te narzędzia mogą pokazywać: jak mówić, kiedy mówić oraz co mówić.

A jeżeli macie podobne problemy w waszych organizacjach i chcielibyście przyjść do nas i porozmawiać na ten temat, to zapraszam was na naszą stronę internetową designzima.com.

Tam w prawym górnym roku będzie przycisk zapytaj eksperta. Można do nas napisać w sprawie takiego warsztatu i jedno z nas odezwie się i porozmawiamy o tym, jak możemy pomóc w marketingu i sprzedaży w Twojej firmie.
‍

Radek: Ja jeszcze powiem, że jeśli macie u siebie działy UX i do tej pory nie rozmawialiście z nimi, a planujecie jakieś działania marketingowo-sprzedażowe, koniecznie odezwijcie się do nich. Naprawdę, to tam może znajdować się wiedza, która może się okazać kluczowa dla waszych działań marketingowo-sprzedażowych.
‍

Ilona: Dziękuję, że jesteś z nami do końca tego odcinka. Jeżeli podobało ci się to, co powiedzieliśmy, zasubskrybuj nas na Spotify albo na YouTube.

Jeżeli masz jakieś przemyślenia, Napisz do nas na przykład na LinkedIn albo na naszego maila. Podziel się feedbackiem o tym odcinku.

Dziękuję i do usłyszenia.
‍

Radek: Cześć!

‍

‍

‍

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.

‍

‍

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.

‍

‍

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.

‍

‍

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.

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.

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.

‍

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.

‍

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.

‍