Photo by Miguel Henriques on Unsplash

Jakim językiem mówimy do tysięcy kursantów i kursantek platformy e-learningowej?

Martyna Przygoda
Bethink
Published in
10 min readMay 23, 2024

--

Czym są platformy e-learningowe Więcej niż LEK i Więcej niż Matura?

Wyobraź sobie naukę z magicznego podręcznika, który sam się aktualizuje. Sam powiadamia Cię, gdy tylko coś się w nim zmieni. Sam odpowiada na wszystkie wątpliwości, które zapiszesz na marginesie. Pamięta wszystkie Twoje odpowiedzi, pomaga Ci korygować błędy i kieruje Cię zawsze tam, gdzie znajdziesz poszukiwane treści…

To opis naszej platformy e-learningowej, ze strony https://wiecejnizlek.pl/platforma/. Idealnie obrazuje, czym się zajmujemy.

Od kilku lat pomagamy studentom medycyny w nauce do Lekarskiego Egzaminu Końcowego, wspierając kilkadziesiąt tysięcy kursantów. Stworzyliśmy także kurs dla maturzystów, pomagając w przygotowaniach do egzaminów z biologii i chemii.

Występ przed taką publicznością byłby wyzwaniem. Ale my podjęliśmy się większego — napisaliśmy tym ludziom interfejs. Taki, z którego codziennie korzystają, który muszą rozumieć, który ma pomagać, nie wykluczać i być przyjazny. I przede wszystkim, ma być dostosowany do różnych grup, nie tylko wiekowych (licealiści i studenci), ale również o różnym stopniu znajomości cyfrowej.

Jak piszemy do naszych kursantów?

Artykuł skupia się wokół języka interfejsu. Opisuję w nim głównie zasady dotyczące microcopy, komunikatów błędów i komunikatów informacyjnych na maksymalnie kilkanaście zdań. Warstwa merytoryczna naszych kursów (wszystkie lekcje, slajdy, przypisy) jest pod opieką twórców kursów i chociaż jest częścią interfejsu, nie projektujemy jej.

Nasze microcopy i komunikaty, skupiają się na tym, by:

  1. Wyjaśnić zasady działania platformy i pojedynczych funkcji.
  2. Ostrzec przed niepożądanym działaniem i potencjalnymi negatywnymi konsekwencjami.
  3. Wytłumaczyć dlaczego system nie zadziałał zgodnie z oczekiwaniem.
  4. Zamknąć ścieżkę działania użytkownika, pogratulować mu.

Przedstawiam Ci poniżej 6 prostych zasad, które z powodzeniem możesz wykorzystać, pisząc microcopy do Twojego systemu. Szczególnie, jeśli zależy Ci na tym, by pisać inkluzywnie, przyjaźnie, skupiać się na języku korzyści i prawidłowym rozdzieleniu przyczyn i skutków.

1. Pisz do wszystkich użytkowników

Przede wszystkim, bezosobowo. Nigdy w interfejsie nie użyliśmy ani męskiej, ani żeńskiej formy czasownika. Chociaż w wielu miejscach ułatwiłoby to przekaz, staramy się zawsze pisać copy tak, by nie sugerować płci.

Co nam to daje? Poczucie, że nikt nie jest wykluczony w naszym interfejsie. Wbrew temu, jak „domyślnie” pisze internet (forma męska), my musielibyśmy zmienić naszą formę domyślną na żeńską. Zdecydowana większość naszych kursantów to… kursantki. 🙂

Jak można sobie wyobrazić, nie zawsze napisanie takiego copy jest proste.

PRZYKŁAD

Kontekst: Użytkownik chce zresetować postępy swojej pracy, by móc rozpocząć ją na nowo.

Wydaje się, że łatwo byłoby napisać:

Co zostanie zresetowane? Postępy w planie pracy z bazą pytań — będziesz mógł utworzyć nowy plan lub edytować istniejący.

Ale w związku z tym, że nie używamy bezpośredniej formy męskiej, ostatecznie zdanie brzmiało:

Postępy w planie pracy z bazą pytań — możliwe będzie utworzenie nowego planu lub edycja istniejącego.

Wprowadzenie formy bezosobowej czasem sprawia, że komunikat jest bardziej mglisty, niż ten pisany bezpośrednio. Z tego powodu poświęcamy więcej czasu na to, by każdy nasz komunikat był po prostu zrozumiały. Jeśli mamy wrażenie, że jakieś słowa czy forma może budzić wątpliwości, staramy się przekształcić zdanie tak, by jasno mówiło o tym, o czym ma mówić.

Czasem, może się okazać, że copy bezosobowe jest dłuższe i mniej precyzyjne. Ale wiemy o tym. Uświadomienie sobie tego, i trzymanie się założeń, ułatwia podejmowanie ostatecznych decyzji projektowych.

Nasze wskazówki:

  1. Staraj się nie używać czasu przeszłego, bo często to on wymusza formę męską lub żeńską.
  2. Wykorzystywanie strony biernej w komunikatach oddzielonych od płci jest czasem konieczne.
  3. Napisz najpierw copy, używając form męskich (jeśli jest Ci trudno pisać w bezosobowej formie), a następnie staraj się zmienić podmiot w zdaniu.
  4. Może okazać się, że czasownik będzie musiał być zastąpiony rzeczownikiem odczasownikowym (słowa z końcówką -cie, -anie, -enie; np. zejście, pisanie, utworzenie). Chociaż zasady poprawnej polszczyzny nazywają je “rzeczownikami zombie”, dla niektórych komunikatów pozbawionych płci, mogą okazać się konieczne.

2. Kropka zamiast przecinka i zasada 50%

Dużą uwagę przywiązujemy do tego, by komunikaty były możliwie proste i krótkie. Jeśli da się coś skrócić o „50%” — zawsze to robimy.

Każda interakcja usera z interfejsem kosztuje go czas. Jeśli jego celem, podczas korzystania z naszego produktu, nie jest czytanie treści samych w sobie, to robimy wszystko, by zajmowało to jak najmniej czasu.

Wierzymy w to, że każdą informację da się napisać precyzyjniej, krócej i nie tracąc przy tym sensu i właściwego przekazu.

PRZYKŁAD:

Kontekst: Stan zerowy sekcji, w której pojawią się wszystkie wyniki egzaminów i testów (jak już jakieś kursant rozwiąże).

My też nie możemy się doczekać, aż coś się tu pojawi!

W tym miejscu będą wyniki wszystkich rozwiązanych przez Ciebie testów i egzaminów.

Zamieniliśmy na krótszy komunikat, który od razu mówi o co chodzi:

Jeszcze jest tu pusto, ale…

W tym miejscu pojawią się wyniki wszystkich rozwiązanych przez Ciebie testów i egzaminów.

Nasze wskazówki:

  1. Po napisaniu copy, zawsze popatrz na nie krytycznie. Zastanów się, czy wszystkie słowa użyte w tych kilku zdaniach (albo w zdaniu) są niezbędne. Jeśli nie — usuń je.
  2. Zastanów się, czy synonimy słów użytych w zdaniach nie będą krótsze i bardziej precyzyjne.
  3. Jeśli nie pasuje Ci forma — napisz to zdanie na różne sposoby, tak, aby nigdy nie traciło swojego sensu i przekazu. W którymś momencie dojdziesz do odpowiedniej formy.

3. Pisz tyle, ile w danym momencie potrzebuje user

W przypadku naszego edukacyjnego produktu, ta zasada ma niezwykle duże znaczenie.

Na przykład, kursant analizujący swoje statystyki, musi wiedzieć z czego wynikają kolory, przedziały, ikony. Ale, wystarczy że zapozna się z tym raz, a każdy następny kontakt ze statystykami będzie dla niego zrozumiały. To oznacza, że nie potrzebuje mieć legendy widocznej na stałe, ale jeśli będzie poszukiwał więcej informacji — musi ją znaleźć prosto, najlepiej pod stałym miejscem.

Służą nam do tego modale (okna modalne, czyli interaktywny element systemu, niepozwalający na obsługę zdarzeń, dotyczących pozostałych okien danej aplikacji) , które uruchamiane są zawsze za pomocą ikony — znaku zapytania w kółku. Jest to pattern projektowy, który stosujemy na naszych kursach od lat.

PRZYKŁAD

Kontekst: użytkownik widzi swój plan pracy z zadaniami w postaci progressu i kilku istotnych informacji. Szczegółowe informacje może zobaczyć na modalu:

Umieszczenie tych wszystkich informacji w interfejsie byłoby nieoptymalne, z punktu widzenia codziennej pracy.

Co nam to daje? Często wyciągamy prostą esencję, która jest potrzebna kursantowi tu i teraz, zostawiamy przy tym odnośnik do „Pokaż więcej”, pod którym możemy zawrzeć dodatkowy, większy kontekst.

Dlaczego „Pokaż więcej”, a nie „Czytaj więcej”? Jeśli pomyślimy o tym przez pryzmat rozkazów użytkownika i systemu, widać subtelną, ale znaczącą różnicę. „Czytaj więcej”, jest rozkazem systemu do użytkownika. „Pokaż więcej” odwrotnie. 🙂

Stosując inne odnośniki, np. w postaci linków, zawsze staramy się pisać, gdzie user trafi po kliknięciu.

PRZYKŁAD:

Zamiast:

Jeśli masz jakieś pytania, kliknij tutaj

piszemy:

Jeśli masz jakieś pytania, napisz do nas na Pomocy technicznej

Pomoc techniczna od razu wskazuje miejsce, do którego trafi user. Komunikat jest więc precyzyjny.

Co z skrótami i definicjami? Jeśli user ich nie zna, zawsze je tłumaczymy. Nie możemy pozwolić na to, by nowy element w interfejsie nie był w żaden sposób wytłumaczony kursantom.

Nasze kursy są specyficzne — nie ma wielu patternów „internetowych” na pokazanie pytania na pojedynczym widoku, rozwiązywania zadania w trybie samodzielnym, czy ikony średniej liczby pytań dziennie do rozwiązania. Stosujemy w tych miejscach ikony i labele, które tworzą jakieś znane skojarzenie (np. do widoku rozwiązywania samodzielnego stosujemy ikonę ołówka i kartki). Zawsze staramy się odpowiednio „nauczyć” naszych kursantów znaczenia ikon i labeli.

Używamy do tego wspomnianego wcześniej modala, ale stosujemy również feature onboarding — czyli „instrukcję” korzystania z danego elementu. W pierwszym kontakcie usera z danym elementem, pokazujemy mu kontekstowo informacje, które tłumaczą czym jest i do czego służy.

Pisząc feature onboardingi oczywiście stosujemy się do pierwszych trzech zasad — zawsze onboardingi są neutralne płciowo, krótkie, ale precyzyjne oraz kontekstowe.

PRZYKŁAD:

Kontekst: użytkownik pierwszy raz wchodzi do zakładki “Baza pytań”, w której może rozwiązywać pytania do egzaminu. Pokazujemy mu feature onboarding funkcji, które są na stałe umieszczone w nagłówku z nazwą bazy.

Nasze wskazówki:

  1. Zanim napiszesz obszerną instrukcję, banner informacyjny czy wyjaśnienie danego feature’a, zastanów się, które z informacji są niezbędne użytkownikowi w pierwszym zetknięciu się z daną funkcją. Następnie oddziel wszystkie bardziej szczegółowe informacje i umieść je w dodatkowym kontekście.
  2. Jeśli wprowadzasz nowy element na stronie, a nie jest on znany z patternów czy standardów online, możesz rozważyć feature onboarding.
  3. Pisz precyzyjnie, unikaj ogólników — szczególnie przy wskazywaniu na konkretne miejsce.
  4. Tłumacz skróty i nowe definicje w interfejsie.

4. Pamiętaj o odpowiedzialności i o nadawcy komunikatu

Staramy się zwracać uwagę na niuanse słowne, bo sprawiają, że nasz język jest bardziej precyzyjny. Ale też bardziej przyjazny. Tam, gdzie jest jakieś ograniczenie platformowe, staramy się zrzucać odpowiedzialność z użytkownika — nie możemy komunikatem sugerować, że zrobił coś złego. Jest jednak druga strona — kiedy użytkownik jest za coś odpowiedzialny, przekazujemy mu to w komunikacie.

Nasze komunikaty zawsze są przyjazne (emocjonalne), a nie suche i formalne. Jest to ważne z perspektywy tego, jak chcemy być postrzegani jako marka. Jesteśmy po to, by pomagać, jesteśmy otwarci na dialog, „chcemy być dla ludzi”.

Komunikujemy się z ludźmi jako „my”. Zwracamy jednak uwagę na konsekwencję w naszych wypowiedziach. Jeśli piszemy do kursanta na „Ty”, to cała wiadomość jest na „Ty”. Jeśli piszemy z perspektywy „my”, to wszędzie używamy „my”. Nie może być zatem: „Jeśli możesz, powiedz nam proszę…”, tylko „Jeśli możesz, prosimy powiedz nam…

PRZYKŁAD:

Kontekst: Opiekunowie kursów odpowiadają na pytania kursantów. Aby podzielić się pracą, stosują specjalny system przypisywania sobie pytań kursantów. Zmienialiśmy ustawienia tego systemu i informowaliśmy ich o nieudanym przypisaniu (jeśli takie nastanie).

Nie widzisz aktualnych informacji. Aby to zmienić, kliknij w ikonę [ikona odświeżenia] i odśwież status taska. Sprawdź też połączenie z internetem. Jeżeli to nie pomoże — daj nam znać o błędzie.

Staramy się zawsze pisać komunikaty tak, by jasno wskazać, kto jest „odpowiedzialny” za wystąpienie błędu. „Nie widzisz aktualnych informacji” przerzuca odpowiedzialność na użytkownika.

Ostateczne copy:

Informacje w tasku są nieaktualne. Aby je odświeżyć, kliknij ikonę [ikona odświeżania] i spróbuj ponownie. Jeżeli to nie pomoże — daj nam znać o błędzie.

„Informacje w tasku są nieaktualne” przerzuca odpowiedzialność na system i ma charakter informacyjny. Drugie zdanie również zostało skrócone i wyrażone bardziej precyzyjnie (akcja-reakcja, aby odświeżyć-kliknij ikonę).

Nasze wskazówki:

  1. Zawsze pisz komunikat tak, by dokładnie wskazywał, kto jest odpowiedzialny za zaistniałą sytuację w systemie. Pamiętaj o tym szczególnie, jeśli użytkownik widzi jakieś niepowodzenie, za które nie jest odpowiedzialny.
  2. Zwracaj uwagę na kompozycję komunikatów, w imieniu kogo i do kogo się zwracasz.

5. Język korzyści, przyczyn i skutków

Jak jeszcze piszemy komunikaty? Staramy się mówić językiem korzyści oraz przyczyn i skutków. Jakie to ma przełożenie na treść i intencję komunikatów? Jeśli chcemy opisać kursantowi np. jakąś sekwencję zdarzeń, których kolejność może mieć znaczenie dla kursanta, zawsze zastanawiamy się, czy chcemy się skupić na przedmiocie czy na człowieku i jego potrzebach?

PRZYKŁAD:

Domyślny plan pracy jest niedostępny, ponieważ do egzaminu pozostało zbyt mało czasu.

Komunikat skupiony jest na przedmiocie — domyślny plan. Starajmy się takie komunikaty kierować w stronę podmiotu:

Do Twojego egzaminu pozostało zbyt mało czasu — nie możemy ułożyć Ci domyślnego planu pracy, który przyniesie spodziewane efekty.

Język korzyści jest szeroko wykorzystywany w komunikatach internetowych. Użytkownicy mogą nawet nie zdawać sobie sprawy z tego, że czytają treści, które są nasączone pozytywnym przekazem.

Nasze wskazówki:

  1. Postaraj się zmienić podmiot w zdaniu. Sprawdź, czy komunikat na tym nie zyskał.
  2. Zamiast informować o tym, co jest obecnie, powiedz o tym, jaką korzyść przyniesie dane działanie (o ile to możliwe w danym kontekście).
  3. Jeśli ważna jest sekwencja działań — napisz copy tak, by użytkownik nie miał co do tego wątpliwości.
  4. Jeśli coś wynika z czegoś (przyczyna-skutek) — napisz o tym.

6. Obsługuj błędy

Komunikaty błędów są idealną okazją do ćwiczenia i egzekwowania wszystkich powyższych zasad — dlatego w swoim artykule umieściłam je na końcu.

We wszystkich sytuacjach, które wymuszają pokazanie jakieś niezgodności systemu z oczekiwaniami użytkownika, musimy pokazać komunikat błędu. Najgorszym scenariuszem dla użytkownika jest to, że nie dostaje rezultatu swoich działań, i jednocześnie nie wie dlaczego.

Microcopy na komunikcie błędu jest szczególnie ważne — pojawia się w sytuacji niespodziewanej, ma poinformować o tym, że coś nie działa, ale jednocześnie musi dostarczyć odpowiedni kontekst i propozycje wyjścia z danej sytuacji.

PRZYKŁADY:

1.

Nie udało się odświeżyć listy pytań.

Sprawdź swoje połączenie z internetem i spróbuj ponownie. Jeśli to nie pomoże — daj nam znać o błędzie.

2.

Brak wyników pasujących do wybranych filtrów.

Spróbuj zmienić filtry. Jeżeli to nie pomoże — daj nam znać o błędzie.

3.

Ten plan nie zawiera dni nauki.

Ustaw odpowiednie daty w planie. Jeżeli to nie pomoże — daj nam znać o błędzie.

A tak wygląda nasz alert:

Jak widzisz, wszystkie komunikaty łączy kilka powtarzalnych zasad.

Nasze wskazówki:

  1. Komunikat zawsze jest konkretny. Jeśli wiemy (technicznie), co poszło nie tak, zawsze piszemy o tym wprost użytkownikowi.
  2. Informacja o tym co poszło nie tak, jest pierwszą informacją, którą widzi użytkownik.
  3. W komunikacje zawsze staramy się wskazać konkretne działanie, które może naprawić stan błędu — czasem jest to jedynie rekomendacja odświeżenia strony (bo coś poszło nie tak po stronie np. serwera), a czasem jest to konkretne działanie po stronie użytkownika (np. zmiana filtrów, jak w jednym z przykładów).
  4. Zawsze staramy się zawrzeć informację o tym, że jesteśmy otwarci na pomoc — wystarczy jedno zdanie Jeżeli to nie pomoże — daj nam znać o błędzie, aby uspokoić użytkownika, że w razie ponownego wystąpienia błędu lub braku naprawy, może po prostu do nas napisać.
  5. Komunikaty są krótkie i zwięzłe. Zawieramy maksimum treści w minimalnej przestrzeni, ograniczonej czasowo (alert znika sam po określonym czasie).

Podsumowanie

Zasady, o których mowa wyżej, chociaż pisane z uwagi na konkretny produkt, mają charakter uniwersalny. Zapomnij o określaniu płci, poświęć uwagę przekazowi i kontekstowi, zachowaj zwięzłość i szacunek dla czasu użytkownika — to fundamenty, na których powinno się opierać Twoje microcopy.

Pamiętaj, że dobre microcopy pomaga unikać błędów i powinno być zawsze o krok przed osobą po drugiej stronie.

Kilkadziesiąt tysięcy naszych kursantów codziennie czyta nasz interfejs. Słowa mają moc. Czas użytkownika jest ważny. To, jak użytkownik odbiera nasz produkt, jest bezpośrednio powiązane z tym, w jaki sposób się do niego zwracamy i jak mocno staramy się zapobiegać błędom, tłumaczyć interfejs i wszystko to, co może być dla użytkownika ważne.

Pamiętaj, że użytkownik korzysta z Twojego produktu w jakimś konkretnym celu. Tylko Ty możesz mu pomóc (lub przeszkodzić) w jego realizacji. Słowa mają w tym ogromny udział!

Daj znać w komentarzu, które ze wskazówek pomogły Ci najbardziej!

Powodzenia!

--

--

Martyna Przygoda
Bethink
Editor for

I'm a UX/UI Designer passionate about UX writing. I share knowledge and strive to ensure our users have positive experiences. Mission-driven and user-focused.