Historia pierwsza
Siedziałem sobie na spotkaniu z drużyną programistów dużej firmy produkującej duże rzeczy. Zebraliśmy się, bo klient rozpoczynał myślenie o nowym systemie. Miała to być strona internetowa skierowana do niezbyt wyraźnie nakreślonej jeszcze grupy użytkowników; nie do końca było wiadomo też, jakie są szczegóły propozycji biznesowej. Jedyną pewną informacją było to, że trzeba zaprojektować coś, co sprzedaje coś innego. Znany wszystkim syndrom „mokrego snu prezesa”. Dzień jak codzień.
Zanim jeszcze zdążyłem zadać parę sensownych pytań, Mietek Kierpołeć, szef działu IT, stwierdził:
– Użyjemy do tego, oczywiście, Microsfot SharePoint.
Zmroziło mnie. Wyszczekałem prawie:
– A skąd wiemy, że funkcjonalność tego systemu będzie odpowiadać wymaganiom użytkowników i organizacji?
Cisza. Spojrzenia nieprzyjazne; siekiera w powietrzu. Pewność stoi na golasa za oknem i chce, żeby ją wpuścić, bo zimno.
Historia druga
Rozmawiam z młodą i ambitną pomysłodawczynią nowego rozwiązania z okolic e-commerce. Nie do końca wiadomo jeszcze, jakie są ścieżki podróży użytkownika poprzez meandry systemu. Nie jest też jasne, jak poradzić sobie z ogarnięciem dość skomplikowanego systemu płatności, którego wymaga nietypowy produkt. Dodatkowo, prototyp strony (oczywiście w fazie wizualizacji interfejsu, pomimo ewidentnych braków badawczych) nie jest zaprojektowany z uwzględnieniem wymogów responsywności, a więc oglądać go muszę z laptopa, zamiast wygodnie gładzić smartfona. Ku memu zdziwieniu, nie ma w planach implementacji responsywnego interfejsu, bo „layout strony jest taki, że już nie chcemy go zmieniać; kolory są okej, siatka też, dobrze to wygląda, mam do tego dość osobisty stosunek, bo robiłam sama.” Tłumaczę, że to nie pojedzie. Mądra pani daje się przekonać. Wraca do planowania i robi jeszcze raz, tak, jak trzeba, zgodnie z wymogami rynku. Chciałbym więcej takich klientów.
Te dwie historie mają jeden wspólny punkt. Autorzy-pomysłodawcy obydwu rozwiązań dali się porwać technologii i swoim pomysłom. Pozwolili sobie zafiksować się na rozwiązaniu, z którym są już na „ty”. SharePoint to system uważany powszechnie (i zupełnie niesłusznie) za „scyzoryk szwajcarski” dla rozwiązań korporacyjnych. Zdecydowanie przysparza mu popularności fakt, iż sprzedający go i kupujący mają często wspólne hobby: golf. Czytaj: sprzedaje się go na polach golfowych albo drogich kolacjach. A kiedy wiąże cię umowa na setki tysięcy (wstaw walutę), to nie fikasz i nie mówisz, że nie działa.
Kiedy natomiast zaprojektujesz stronę internetową i włożysz w to serce, to trudno zrozumieć, jak i dlaczego twój pomysł wcale nie musi być najlepiej dostosowany do potrzeb użytkownika końcowego. Istnieje bowiem duża szansa, że projektowałeś dla siebie.
Jednakże prawdziwy kłopot leży gdzie indziej; często wymyślając nowy produkt skupiamy się zanadto nad możliwościami rozwiązań końcowych, które podsuwają nam technologia i własne umiejętności.
Dlaczego?
Bo tak jest łatwo. Znamy niezliczone biblioteki JavaScript; wiemy, jak ekscytujące dla użytkownika są interfejsy zbudowane z atrakcyjnych przycisków i suwaków. Lubimy materiały video; wydaje nam się też, że udostępniając nieskończone możliwości personalizacji lub ustawień dajemy użytkownikom to, czego potrzebują. Szukamy uniwersalnych rozwiązań, ale takich, które „zdeklasują konkurencję zestawem opcji”. Trzymamy się tego, co wiemy i umiemy albo tego, co aktualnie zdobywa naszą uwagę (efektem wow).
Kiedy przychodzi do testowania produktu okazuje się, że nikt w to całe badziewie nie chce klikać, a cuda z SharePointa na kiju nie są warte nic bez porządnego wewnątrz-firmowego content governance, którego nie ma, bo nikt o nim nawet nie pomyślał. A człowiek używający strony na małym ekranie urządzenia przenośnego psioczy na ciągłą konieczność powiększania i pomniejszania viewportu.
Powracam cały czas myślami i wnioskami do tego samego: rozpoznanie początkowe jest najważniejsze. Faza discovery, jeśli wolisz. To, co poprzedza projektowanie.
Zbadaj, czego potrzeba Twoim użytkownikom i Tobie, a potem dobierz do tego technologię i skonstruuj interfejs. Nigdy na odwrót.
Bo po co budować coś, czego wizja rozjedzie się z zapotrzebowaniem?
Niezwykle widoczne jest to w przypadku penisowo zaprojektowanych aplikacji na Androida. Tyczy się to też iOSa, tu jednak jest trudniej zrobić coś okrutnie złego, bo mimo wszystko Apple jakieś tam standardy trzyma. Jednak produkty jednoosobowych armii programistów-wyznawców Google często powijają aplikacje, od których oczy wypadają z głowy. Wiem, bo ich używam. Material design i unifikacja trochę pomogły, ale wciąz wiele produktów woła o pomstę do nieba. Powód jednak nie leży w bibliotekach Androida, wbrew obiegowej opinii: powodem jest brak myślenia i zrozumienia, że coś, czego może użyć armia programistów niekoniecznie musi działać dla kogoś, kto nie rozumie, czym różni się integer od string. I zagubienie się w myśleniu i nowym, ekscytującym produkcie, który będzie tak zaawansowany, że zmiecie konkurencję. Jeżeli ktoś będzie miał siłę się przez niego przebijać.
Notka o kontekście
To wszystko jest oczywiście zależne od kontekstu. Czasem skomplikowanie jest ważne, a wyboru platformy faktycznie nie da się zakwestionować lub zmienić. Wtedy jednak pracować trzeba z rozwagą… I nie dać się sterroryzować.
Do boju!
Dodaj komentarz