Intranet mobile-first: jak ułatwić codzienną pracę na telefonie

Pracownik nie powinien wracać do biurka, żeby przeczytać komunikat, znaleźć procedurę albo skontaktować się ze współpracownikiem. Projektowanie intranetu mobilnego powinno ułatwiać te codzienne zadania wszędzie tam, gdzie pracownicy mają uprawnienia i możliwość pracy.

Dla zespołów pierwszej linii i pracowników terenowych telefon bywa głównym dostępem do informacji firmowych. Dla innych to okazjonalne udogodnienie między spotkaniami albo poza biurem. Tak czy inaczej, dopasowanie strony desktopowej do mniejszego ekranu to dopiero początek. Uwagi wymagają logowanie, nawigacja, czytanie, formularze i pobieranie plików.

Zacznij od zadań, które pracownicy muszą wykonać, a potem zaprojektuj i przetestuj całą ścieżkę.

W tym artykule:

• Dlaczego doświadczenie na telefonie wymaga osobnej uwagi?
• Dlaczego pomniejszona strona desktopowa nie wystarczy?
• Jak sprawić, by codzienne zadania były wygodne na telefonie?
• Jak ograniczyć zużycie danych mobilnych przez intranet?
• Jak zapewnić dostępność intranetu na urządzeniach mobilnych?
• Jak testować z pracownikami i stale ulepszać intranet?

Dlaczego doświadczenie na telefonie wymaga osobnej uwagi?

Pracownik terenowy potrzebuje numeru telefonu do kolegi. Pracownica zmianowa chce sprawdzić komunikat operacyjny przed rozpoczęciem pracy. Osoba odwiedzająca inny oddział musi otworzyć politykę podróży służbowych.

To drobne zadania, ale niewygodny intranet zamienia je w opóźnienia. Jeśli odpowiedź brzmi „znajdź komputer”, wygodny dostęp już zawiódł.

Podczas zbierania wymagań zapytaj pracowników o ich rzeczywiste warunki pracy:

• Jakie zadania muszą wykonywać na telefonie?
• Kto polega na dostępie mobilnym, a kto korzysta z niego okazjonalnie?
• Które urządzenia służbowe, prywatne lub współdzielone są dopuszczone?
• Jakie połączenia są dostępne w miejscu pracy?
• Czy krótkie przerwy, mocne światło albo częste przerywanie pracy wpływają na korzystanie z intranetu?

Nie zakładaj, że wszyscy pracują w tych samych warunkach. Pracownik magazynu korzystający ze współdzielonego urządzenia w firmowej sieci Wi-Fi ma inne potrzeby niż pracownica terenowa z przydzielonym telefonem.

Uzgodnij priorytetowe zadania mobilne i dopuszczone sposoby dostępu, zanim zaprojektujesz stronę główną. Dział HR i IT powinny też wyjaśnić, czy prywatne telefony są dozwolone i jakie alternatywy mają pracownicy. Dostęp do kluczowych informacji nie powinien zależeć od niewypowiedzianego oczekiwania, że pracownicy użyją własnego urządzenia albo zapłacą za transfer danych.

Dlaczego pomniejszona strona desktopowa nie wystarczy?

Responsywny układ dopasowuje treść do ekranu. Użyteczne doświadczenie mobilne idzie dalej: pozwala wygodnie wykonać zadanie za pomocą dotyku.

Strona może mieścić się na telefonie i nadal być trudna w obsłudze. Na przykład:

• Zwinięte menu desktopowe ukrywa link, z którego pracownicy korzystają najczęściej.
• Małe ikony są tak blisko siebie, że łatwo stuknąć niewłaściwą.
• Duży baner spycha przydatną odpowiedź daleko w dół strony.
• Szeroka tabela wymaga wielokrotnego przewijania w bok.
• Procedura jest dostępna tylko jako dokument przygotowany do druku.

Pracownicy nie powinni musieć przełączać przeglądarki na wersję desktopową, powiększać ekranu dwoma palcami ani przeszukiwać strony, żeby wykonać zwykłe zadania. Kluczowe informacje nie powinny też znikać tylko dlatego, że ekran jest mniejszy.

Weźmy za przykład szukanie zasad dotyczących urlopów.

Przed: Pracownica otwiera menu, zgaduje, który dział odpowiada za zasady, przechodzi przez kilka stron i pobiera PDF, żeby znaleźć instrukcję złożenia wniosku.

Po: Widoczna wyszukiwarka prowadzi do czytelnej strony z zasadami. Strona już na początku wyjaśnia, komu przysługuje urlop i jak złożyć wniosek, zawiera link do systemu urlopowego, a formalny dokument pozostaje dostępny jako wyraźnie opisany plik do pobrania.

Druga ścieżka ogranicza szukanie i niepotrzebne pobieranie plików, nie usuwając żadnych informacji.

Warto też odróżnić układ strony od zużycia danych. Samo przełączenie na wersję desktopową nie musi zwiększać ilości pobieranych danych. O tym, ile danych zostanie przesłanych, decydują zasoby, których żąda strona. Strona responsywna nadal może pobierać duży obraz przygotowany dla desktopu i jedynie wyświetlać go w mniejszym rozmiarze.

Jak sprawić, by codzienne zadania były wygodne na telefonie?

Zacznij od krótkiej listy priorytetów pracowników, takich jak czytanie komunikatów, wyszukiwanie kontaktów, sprawdzanie procedur i składanie wniosków. Zapewnij tym zadaniom jasną ścieżkę, zamiast w równym stopniu zmniejszać każdy komponent z wersji desktopowej.

Zadbaj o przewidywalną nawigację. Wyszukiwarka powinna być łatwa do znalezienia, a nazwy miejsc docelowych znajome, np. „Ludzie”, „Procedury” i „Pomoc”. Kompaktowe menu może zawierać rzadziej używane miejsca, a niewielki zestaw częstych działań powinien pozostać widoczny. Utrzymuj te same nazwy i położenie elementów na wszystkich stronach.

Elementy dotykowe potrzebują wystarczająco dużo miejsca, by jedno działanie dało się odróżnić od drugiego. Unikaj interakcji zależnych od najechania kursorem i nie polegaj na niewyjaśnionej ikonie, gdy krótki opis rozwiałby wątpliwości.

Stawiaj odpowiedź przed dekoracją. Na stronie z procedurą zacznij od tego, co pracownicy muszą wiedzieć i co powinni zrobić dalej. Używaj czytelnego tekstu, znaczących nagłówków i krótkich sekcji. Duży obraz na początku nie powinien stać między pracownikiem a pilną odpowiedzią.

Tam, gdzie to możliwe, publikuj codzienne wskazówki jako strony internetowe. Wymagane oryginalne dokumenty zostaw dostępne, ale opisz je wyraźnie, żeby pracownicy mogli zdecydować, czy potrzebują pobrać plik.

Projektuj formularze wyrozumiałe dla błędów. Telefon nie jest wygodnym miejscem do wypełniania zbędnych pól. W każdym formularzu:

• Proś tylko o informacje potrzebne do rozpatrzenia wniosku.
• Używaj odpowiednich typów pól, np. pola e-mail dla adresu e-mail.
• Zachowaj widoczne etykiety zamiast polegać na tekście zastępczym.
• Wyjaśniaj błędy przy polu, którego dotyczą, i podawaj, jak je poprawić.
• Zachowuj poprawnie wprowadzone dane po wystąpieniu błędu.
• Tam, gdzie to zasadne, zapewnij bezpieczny sposób zapisania postępu na wypadek przerwy.

Zapisane dane z formularzy wymagają zasad postępowania dopasowanych do ich wrażliwości, szczególnie na urządzeniach współdzielonych.

Traktuj logowanie jako część zadania. Przetestuj firmowe logowanie, monity uwierzytelniania, przekierowania i powrót na docelową stronę. Pracownik otwierający link do procedury nie powinien trafić na stronę główną i zaczynać szukania od nowa. Naprawiaj przerwane ścieżki bez osłabiania uwierzytelniania.

Śledź zadanie także poza intranetem. Użyteczna strona wniosku niewiele daje, jeśli jej przycisk otwiera połączony system HR, który trudno obsłużyć na telefonie.

Wbuduj te wzorce w wielokrotnego użytku design system. Wspólne pola wyszukiwania, nawigacja, przyciski, komunikaty o błędach w formularzach, opisy plików do pobrania i szablony procedur ograniczają powtarzaną pracę projektową i testową. Udokumentuj, jak każdy komponent zachowuje się na małych ekranach i z technologiami asystującymi. Wyznacz właściciela design systemu, żeby nowe strony korzystały z przetestowanych wzorców, zamiast za każdym razem wprowadzać inną interakcję.

Jak ograniczyć zużycie danych mobilnych przez intranet?

Mniejsze pliki pomagają pracownikom szybciej dotrzeć do informacji, gdy korzystają z danych mobilnych albo wolniejszego połączenia. Chodzi o szacunek dla ich czasu i łącza, a nie o pogoń za technicznym wynikiem.

Zacznij od obrazów. Telefon nie powinien otrzymywać dużego obrazu przygotowanego dla desktopu, jeśli mniejsza wersja wyświetli się odpowiednio. Poproś zespół wdrożeniowy o sprawdzenie doboru obrazów zarówno pod kątem rozmiaru ekranu, jak i gęstości pikseli. Poradnik web.dev o obrazach responsywnych wyjaśnia, jak przeglądarki mogą wybierać odpowiednie zasoby graficzne.

Następnie przejrzyj, co ładuje każda strona:

• Kompresuj obrazy i wybieraj odpowiednie formaty, nie czyniąc ważnych szczegółów nieczytelnymi.
• Usuń skrypty i widżety zewnętrzne, które nie wspierają zadania.
• Unikaj automatycznie odtwarzanych filmów i pozwól pracownikom decydować, kiedy ładować multimedia.
• Priorytetowo traktuj treść potrzebną do przeczytania lub działania, zamiast czekać na każdy opcjonalny element.
• W miarę możliwości pokazuj typ i rozmiar dokumentu przed pobraniem.

Przy dużym załączniku zastanów się, czy krótkie podsumowanie na stronie może odpowiedzieć na bieżące pytanie. Osoba sprawdzająca termin rozliczenia wydatków nie powinna musieć pobierać całego podręcznika. Pełny dokument zostaw dostępny, gdy liczą się szczegóły.

Testuj zarówno pierwszą, jak i kolejną wizytę. Zasoby zapisane w pamięci podręcznej mogą przyspieszać powrót na stronę, ukrywając koszt, jaki ponosi ktoś, kto otwiera ją po raz pierwszy. Sprawdzaj reprezentatywne wolniejsze połączenia, a nie tylko biurowe Wi-Fi.

Poproś zespół techniczny o przeanalizowanie przesyłanych danych i wolnych żądań w narzędziach deweloperskich przeglądarki. Redaktorzy mogą dobierać odpowiednie multimedia i pisać przydatne podsumowania; nie należy oczekiwać, że wdrożą dostarczanie obrazów responsywnych, ładowanie skryptów czy cache.

Ustalaj oczekiwania wydajnościowe na podstawie uzgodnionych zadań i rzeczywistych warunków pracy. „Pracownik może przeczytać komunikat dla swojej zmiany bez czekania na opcjonalne multimedia” to bardziej użyteczny punkt wyjścia niż niewyjaśniony wynik punktowy.

Jak zapewnić dostępność intranetu na urządzeniach mobilnych?

Dostępność jest wymaganiem wobec narzędzia dla pracowników, a nie opcjonalnym wykończeniem. Pracownicy z niepełnosprawnościami wzroku, słuchu, ruchu lub poznawczymi mogą potrzebować różnych sposobów czytania, nawigowania i interakcji.

Uwzględnij w szablonach stron i komponentach te podstawy:

• Czytelny kontrast i tekst, który można powiększyć bez zasłaniania treści lub działań.
• Znaczące nagłówki i jasne etykiety formularzy.
• Napisy do filmów zawierających informacje mówione.
• Elementy sterujące o zrozumiałych nazwach, działające z technologiami asystującymi.
• Widoczny fokus klawiatury i logiczną kolejność nawigacji.

Niektóre rozwiązania pomagają też w codziennych warunkach, np. przy mocnym świetle lub obsłudze jedną ręką. Te korzyści nie zastępują jednak potrzeb pracowników z niepełnosprawnościami.

Responsywny design nie sprawia automatycznie, że intranet jest dostępny. Oprócz testów dotykowych przeprowadzaj testy z klawiaturą i mobilnym czytnikiem ekranu. Traktuj WCAG jako punkt odniesienia dla kryteriów akceptacji, a wytyczne W3C dotyczące dostępności mobilnej jako dodatkowe wskazówki.

Jak testować z pracownikami i stale ulepszać intranet?

Testuj prawdziwe zadania na reprezentatywnych telefonach przed szerokim wdrożeniem. Zmniejszone okno przeglądarki na komputerze pomaga na etapie projektowania, ale nie odtworzy każdej interakcji dotykowej, klawiatury ekranowej, przekierowania przy logowaniu ani zachowania mobilnego czytnika ekranu.

Zaproś pracowników z grup zidentyfikowanych podczas badań. Uwzględnij ich urządzenia, przeglądarki, warunki sieciowe i potrzeby w zakresie dostępności. Przeprowadzaj sesje w bezpiecznych warunkach, nigdy podczas prowadzenia pojazdu ani obsługi maszyn.

Skorzystaj z kompaktowego planu testów:

Zadanie	Warunki testu	Na co zwrócić uwagę
Zalogowanie się z linku do komunikatu	Dopuszczony telefon z firmowym uwierzytelnianiem	Czy pracownik może dokończyć logowanie i dotrzeć do właściwego komunikatu?
Znalezienie zasad urlopowych	Telefon w orientacji pionowej, bez podpowiedzi	Czy wyszukiwarka i nazwy są zrozumiałe? Czy odpowiedź jest czytelna bez wielokrotnego powiększania?
Otwarcie pliku	Reprezentatywne wolniejsze połączenie	Czy typ i rozmiar pliku są jasne? Czy plik otwiera się w użytecznej przeglądarce?
Znalezienie współpracownika	Obsługa dotykowa i test z mobilnym czytnikiem ekranu	Czy pracownik może rozpoznać właściwą osobę i skorzystać z opcji kontaktu?
Wypełnienie krótkiego formularza	Klawiatura ekranowa, celowy błąd i przerwa	Czy błędy są jasne? Czy poprawne dane zostają zachowane? Czy można bezpiecznie wrócić do formularza?

Poproś uczestników o wykonanie zadań bez podpowiedzi. Zwracaj uwagę na nietrafione stuknięcia, mylące menu, wielokrotne przewijanie w bok, wolne pobieranie i utracone dane w formularzach. Jeśli ktoś utknie, zapisz, gdzie i dlaczego, zanim pokażesz zamierzoną ścieżkę.

Przed pilotażem uzgodnij oczekiwania na poziomie zadań. Na przykład pracownik powinien móc znaleźć procedurę, używając zwykłego języka ze swojego miejsca pracy, i przejść do linku do wniosku bez przesiadania się na komputer. Wykorzystaj obserwacje z pilotażu, żeby ustalić realistyczne oczekiwania co do czasu wykonania zadań, zamiast wybierać arbitralne cele.

Połącz te wnioski z dostępnymi zagregowanymi danymi o korzystaniu z wersji mobilnej i opiniami pracowników. Sam ruch nie dowodzi sukcesu: krótka wizyta może oznaczać szybką odpowiedź albo porzucone zadanie. Sprawdź przyczynę.

Przypisz poprawki właściwym osobom, w tym zespołom UX i IT, właścicielom treści i zespołom połączonych usług. Usuń bariery w priorytetowych zadaniach przed szerszym wdrożeniem, a po zmianach w menu, szablonach, formularzach lub integracjach powtórz kluczowe testy.

Utrzymuj kanał zgłaszania uwag, który działa na telefonie. Pracownicy nie powinni potrzebować dostępu do komputera, żeby zgłosić, że dostęp mobilny ich zawodzi.

Gotowy, by intranet lepiej działał na telefonie?

Wybierz jedno częste zadanie pracowników i wypróbuj je na urządzeniach i połączeniach, z których naprawdę korzystają Twoi współpracownicy. Zacznij od logowania, przejdź każdy link i sprawdź, czy zadanie da się wykonać bez obejść.

Jeśli planujesz nowy intranet, porozmawiaj z zespołem Open Intranet o konfiguracji i testowaniu doświadczenia mobilnego wokół tych zadań. Open Intranet, zbudowany na Drupalu, jest punktem wyjścia opartym na Open Source; użyteczność, wydajność i dostępność nadal wymagają przemyślanego projektowania i testów. Zacznij od pracy, którą muszą wykonać pracownicy, a potem zbuduj wokół niej doświadczenie.