Dziewięć lekcji wyniesionych ze współpracy z redakcjami

Ten wpis dzieli się kluczowymi spostrzeżeniami i lekcjami wyniesionymi z naszej pracy z redakcjami mediowymi przez ostatnie cztery lata. Omówimy takie tematy jak znaczenie rozumienia nawyków i potrzeb zespołów redakcyjnych, wagę angażowania wszystkich niezbędnych osób w demonstracje produktów oraz wartość dokładnych badań i ciągłej iteracji w projektowaniu skutecznych rozwiązań.

Jeśli jesteś profesjonalistą medialnym pragnącym zrozumieć unikalne wyzwania i możliwości tej dziedziny, mamy nadzieję, że ten wpis okaże się dla Ciebie wartościowy i przydatny.

1) Nawyki kontra innowacja

Projektanci zazwyczaj tworzą innowacyjne rzeczy. Jednak w przypadku aplikacji, z których użytkownicy korzystają wiele godzin dziennie, znajomość nawyków użytkownika decyduje o sukcesie. Innowacja nie zawsze jest rozwiązaniem. To bardziej jak tworzenie Word'a czy Excel'a niż strony internetowej czy panelu startupowego używanego trzy razy w miesiącu.

Dlatego tak ważna jest znajomość nawyków użytkowników. Na przykład w jednej redakcji spędziliśmy kilka dni, fizycznie siedząc z nimi w pokoju. Obserwowaliśmy, jak pracują, wybierają tematy, spierają się, który artykuł trafi na stronę główną, a który nie, przeprowadzają wywiady w sąsiednim pokoju lub przez telefon. Jak dodają treści do CMS-u i jak wygląda dalszy proces. Zawodowo nazywa się to badaniem etnograficznym. Oznacza pozyskiwanie danych polegające na obserwowaniu i opisywaniu zachowań danej grupy społecznej w jej „naturalnym" środowisku – w tym przypadku w miejscu pracy. Naszym zadaniem jest przeniesienie tych obserwacji do systemu tak, aby praca była jak najłatwiejsza.

Kolejny przykład: redaktorzy powiedzieli nam, że woleliby nie mieć przycisków do zapisywania ustawień artykułu w prawym dolnym rogu. Używali Windows, gdzie właśnie tam pojawiają się powiadomienia, które są dla nich równie ważne w pracy. A te modalne powiadomienia zasłaniały im przyciski. My wszyscy pracowaliśmy na Macach, gdzie wiadomości automatycznie pojawiają się w lewym górnym rogu. Nasza intuicja i nawyki po prostu nie pasowały do realiów redakcji.

2) Demo produktu

Demo produktu pokazuje klientowi, jak działa system. Te spotkania są kluczowe, bo to właśnie na nich redakcja powinna podejmować większość decyzji.

Jeśli wyślesz e-mail do tak dużej organizacji, możesz czekać kilka tygodni na odpowiedź. Albo nie dostać jej wcale. Jeśli chcesz dynamiki – tworzysz nowe rzeczy i wersje co tydzień, a potem przynosisz dema na spotkanie.

Podczas dema produktu każdy w pokoju może się wypowiedzieć; jest dyskusja, a po każdym spotkaniu wracasz do notatek, rysujesz nową wersję i wprowadzasz poprawki. I tak co tydzień.

W pokoju powinny być obecne osoby niezbędne do kontynuowania procesu, takie jak deweloperzy. Zdarzało nam się, że ustalaliśmy coś z zespołem i pracowaliśmy nad tym, ale deweloperzy nie zgadzali się z naszym pomysłem, bo nie było ich na spotkaniu.

Jeśli firma ma wiele zespołów redakcyjnych, na takim demo powinni być przedstawiciele każdej redakcji. To ważne, bo każdy może pracować nieco inaczej i potrzebować innych funkcji.

Impresjonistyczny obraz olejny przedstawiający demo produktu. Wygenerowane przez DALL·E

3) Szczegóły mają znaczenie

Analizowanie przepływu pracy dużych redakcji (redaktorzy, dziennikarze, reporterzy), a następnie przekładanie wniosków na konkretne rekomendacje wymagało skrupulatności i precyzji. Nawet najmniejszy szczegół może mieć mierzalny wpływ na oszczędność czasu i komfort pracy ludzi.

W każdym projekcie stosujemy zasadę iteracji. W innowacyjnych projektach cyfrowych naturalne jest pojawianie się nowych informacji w trakcie realizacji. Klient często o czymś przypomina i chce coś dodać. Albo sami odkrywamy funkcję, którą chcemy wdrożyć. Iteracja powinna być wpisana w DNA prowadzenia takiego projektu.

Raz zaprojektowaliśmy proces dodawania informacji na dwa kliknięcia. Później, na spotkaniu z redaktorami, okazało się, że to za dużo. Musiało być jedno kliknięcie, bo praca na siatce strony głównej jest bardzo dynamiczna i wymaga szybkiej reakcji w danym momencie. Zorganizowaliśmy interfejs tak, by najważniejsze rzeczy były dostępne za pierwszym kliknięciem.

4) Interdyscyplinarna współpraca

Każdy projekt tej skali wymaga interdyscyplinarnej współpracy na linii design–development. Zarówno front-end, jak i back-end mają własną perspektywę, którą projektanci powinni uwzględniać w rozwiązaniu.

Mieliśmy sytuację, w której na początku intensywnie współpracowaliśmy z front-endem. Potem współpraca między designem a front-endem w kontekście rozwijania komponentów i systemu projektowego mocno podupadła (zmieniające się priorytety). Zespół zawęził zakres prac nad systemem projektowym kosztem innych produktów.

Nagle potrzebowaliśmy więcej współpracy między front-endem a designem. Każdy robił swoje, i te rzeczy zaczęły mocno rozbiegać się strukturalnie i pod kątem wydajności. To jest właśnie to, co kluczowe: front-end i design muszą mówić tym samym językiem i konsultować się ze sobą przy każdej możliwej okazji.

Współpraca między designem a rozwojem oprogramowania oczami AI.

5) Cierpliwość i zaufanie

Często podkreślamy zaufanie w kontekście realizacji projektów jako kluczowy składnik współpracy, często decydujący o sukcesie.

Partnerzy mogą budować zaufanie na dwóch poziomach:

• Poziom biznesowy – chodzi o czas i pieniądze. Klient musi ufać ekspertowi, by pracować w modelu time & material (T&M). Oznacza to, że powinniśmy być zaangażowani w ustalanie harmonogramu projektu. Czas i budżet nie są z góry narzucone.
• Poziom projektowy – rekomendacje firm IT muszą być uważnie wysłuchane. W naszym przypadku, gdy pojawiały się odmienne opinie, często to nam pozostawiano decyzję. Organizacja nie mówiła: OK, idziemy w prawo. Zazwyczaj firma mówiła: niech zdecyduje Autentika. Są ekspertami.

Te dwa czynniki budują odpowiedzialność i efektywność, i po prostu chcemy ciężko pracować. Gdy jest zaufanie, chcesz dać z siebie jak najlepszą jakość przy takim projekcie.

Na przykład na początku naszej współpracy z jedną firmą stosowaliśmy Atomic Design. Po pewnym czasie okazało się, że to nie było dobre rozwiązanie, więc przedstawiliśmy partnerowi nasz punkt widzenia. Mimo że poświęciliśmy na to czas i pieniądze, firma nam zaufała i zgodziła się na zmiany.

Oznacza to, że nie baliśmy się przyznać do błędu. Bo jednocześnie przyszliśmy z rozwiązaniami, które miały argumenty i były do zaakceptowania. To stawia współpracę w innym świetle: to nie firma przychodzi do nas po jakimś czasie i mówi: widzimy błąd, namieszaliście w pracy. To my przychodzimy i mówimy: jest błąd, zatrzymajmy się.

Projekt oparty na zaufaniu ma znacznie większe szanse powodzenia.

Jak redakcja przyszłości wygląda według AI? Obraz wygenerowany przez Midjourney

6) Język

Badania użytkowników są niezwykle ważne. Musimy rozmawiać z ludźmi tym samym językiem i używać właściwych słów. Wchodzimy w partnerstwo na długi czas. Nie jesteśmy zwykłą firmą, która zniknie po krótkim czasie.

Raz mieliśmy sytuację, w której musieliśmy rozgryźć, co redaktorzy mieli na myśli, używając słów „pula kategorii". W systemie nazywaliśmy to inaczej i zajęło nam trochę czasu ustalenie właściwego języka.

Pracując z wieloma redakcjami, zauważamy, że redaktorzy używają różnego słownictwa, opisując te same rzeczy. Każda firma ma swój żargon i badania użytkowników muszą być przeprowadzane w każdej z nich.

Zanim zaczniesz tworzyć lub zmieniać oprogramowanie, zawsze warto sprawdzić, jak ludzie z niego korzystają i jakich innych systemów używają.

Musimy rozmawiać z ludźmi tym samym językiem i używać właściwych słów. Zdjęcie redakcji wygenerowane przez Midjourney.

7) Skalowanie

Przygotuj się na niespodzianki. To stały element tego rodzaju projektów. Często zdarza się, że po tym, jak uzgodniłeś coś ze wszystkimi decydentami, przychodzisz tydzień później i decyzja jest zupełnie inna. To naturalny proces i trzeba być na to mentalnie przygotowanym. Nastawienie projektanta jest tutaj kluczowe.

Projektanci powinni też przygotować się na to technicznie. Jeśli firma nie inwestuje w rozwój systemu projektowego, komponentów, automatyzacji i auto-layoutów – idea skalowania powinna pojawić się od samego początku, bo w połowie projektu może nie być możliwości rozpoczęcia procesu skalowania. Trzeba byłoby zaczynać od nowa. Nazywa się to długiem technologicznym i jego spłata jest kosztowna.

8) Refaktoryzacja

Refaktoryzacja jest potrzebna, gdy coś pójdzie nie tak w procesie projektowania lub tworzenia; coś musi zostać zmienione, dodane lub usunięte. Refaktoryzacja developmentu oznacza, że gdybyś zaczynał proces od zera, zrobiłbyś to inaczej – ale nie robiąc wszystkiego od nowa.

W pewnym momencie musieliśmy przejść ze Sketch na Figma. Mogło się wydawać, że robimy krok w tył, bo przeniesienie całego systemu zajmuje dużo czasu. Jednak z Figmą projektowanie nowych aplikacji zajmuje nam znacznie mniej czasu. Dzięki lepszym funkcjom w Figmie pracujemy szybciej, co oznacza mniejsze koszty dla klienta. Czas poświęcony na migrację do Figmy zwrócił się już kilkakrotnie w ciągu zaledwie jednego roku po przejściu.

Abstrakcyjna grafika ołówkiem i akwarelą przedstawiająca design system. Wygenerowane przez DALL·E

9) Design system: niekończąca się historia

Design system to zbiór narzędzi i procesów ułatwiających projektowanie, budowanie i rozwijanie produktów cyfrowych. Biblioteki komponentów, zasady, narzędzia i procesy – to najlepsze, co mogło się przydarzyć projektowaniu aplikacji webowych.

Projektanci nigdy nie kończą pracy nad systemem projektowym, bo systemy nieustannie ewoluują. Jednak przy transformacji nie trzeba projektować tylko nowych elementów. Można korzystać z już zaprojektowanych i ewentualnie dodawać lub zmieniać części. Dla jednej redakcji zaprojektowanie jednej z aplikacji zajęło nam zaledwie 42 godziny, właśnie dzięki komponentom systemu projektowego.

Jeśli chcesz dowiedzieć się więcej o systemach projektowych, przeczytaj nasz artykuł.

Podsumowanie

Praca z redakcjami mediowymi przez ostatnie cztery lata nauczyła nas cennych lekcji o znaczeniu rozumienia nawyków i potrzeb zespołów redakcyjnych oraz o wadze angażowania wszystkich niezbędnych osób w demonstracje produktów.

Jeśli jesteś redakcją medialną pragnącą usprawnić swój przepływ pracy i zwiększyć efektywność, rozważ współpracę z doświadczonym zespołem o udokumentowanych sukcesach w tej dziedzinie. Sprawdź nasze studium przypadku lub skontaktuj się z nami, by dowiedzieć się więcej o tym, jak możemy pomóc.