Są systemy, które zapominają o swoim powołaniu. Wprost przeszkadzają w ich używaniu. Skąd się biorą? Powstają wtedy, gdy przestajemy szukać sensu.
W poszukiwaniu sensu
Korzystałam ostatnio z pewnej strony w celu zakupu czegoś:) Po przejściu do płatności, pojawił się opis z krokami, jakie należy wykonać. A u dołu przycisk zatwierdzenia dokonania płatności. Z ciekawości kliknęłam ten przycisk. Zrobiłam to zaraz po przejściu na stronę i przed wykonaniem przelewu. Coś zamrugało, coś się sprawdziło i dostałam komunikat, że pieniądze nie zostały odebrane. No nie, nie wysłałam ich. Jednak nie mogłam już powrócić i zapłacić. Blokada.
Napisałam do opiekujących się systemem. Nadal chciałam kupić to, po co przyszłam. Opisałam problem i pytam „co robić?”. Z odpowiedzi dowiedziałam się, że, niestety, ta rzecz może być kupiona przez jedną osobę tylko raz, a ja już próbowałam, więc trudno. Takie jest zamierzone działanie systemu, więc jest OK. Wniosek – mogę spróbować z inną ofertą lub z innego konta.
Rozumiem, że działanie zostało tak obmyślone, ale… może zostało źle obmyślone? Nie dostałam, czego chciałam, oni nie zarobili. Mógł zdarzyć się błąd po stronie aplikacji do przelewów i nie z naszej winy, również nie doszlibyśmy do celu. Nie zostało zabezpieczone niestandardowe użycie systemu (kliknęłam guzik przed wysłaniem pieniędzy). Nie zostało sprawdzone, czy coś kupiłam, ale czy próbowałam kupić. Wystarczyłoby siąść i obmyślić to lepiej.
Systemy, które przeszkadzają w ich używaniu
Czasem nawalamy jako twórcy systemów, które mają ratować świat i uszczęśliwiać ludzi. Czemu?
To jest fajne! ale bez sensu…
Jesteśmy pasjonatami technologii, nowych języków, frameworków, bibliotek. Czasem coś jest tak wspaniałe, że aż żal tego nie użyć. Ale nie zawsze to ma w danym miejscu sens.
Np. możemy wykorzystać genialne szyfrowanie, które jednak wydłuża czas używania funkcji systemu, który miał zapewnić przede wszystkim zwiększenie efektywności pracy.
Czas to pieniądz, a analiza zżera czas
Lepiej siąść i zrobić i sprzedać i zapomnieć i cieszyć się, że nie było zwrotek i przeszło i nikt nie zauważył, i nie przejmować się, że ktoś się potem musi tym elementem dziadostwa w naszym wykonaniu frustrować kilka lat.
I pierdołami się nie zajmujemy
Bo kogo obchodzi tam czy to się nazywa tak, czy inaczej, czy można iść w lewo, czy w prawo, i co się stanie, jeśli ktoś kliknie coś, czego normalny człowiek nie pomyślałby klikać. Diabeł tkwi w szczegółach. Jeśli nasz użytkownik trafi na coś drobnego, acz odrzucającego, to jednak wpłynie to na nasz obraz w jego oczach. Powstanie na nim taka mała, drażniąca ryska.
Panie, teraz to już tak się nie da
Program, może i czasem projektowany z myślą o łatwości utrzymania, to jednak nie transformers. Jeśli mamy już od dawna pewną strukturę, logikę, nie przemienimy nagle i za darmo czegoś w coś, co wymaga wywrócenia systemu do góry nogami i na lewą stronę.
Więc zostajemy z rozwiązaniem-kompromisem, z którego ani my nie jesteśmy dumni, ani klient nie jest szczęśliwy. A mama mówiła, żeby najpierw pomyśleć, zanim się coś zrobi (to się tyczy obu stron projektu)!
Jak zaradzić? Posadzić kogoś.
Jak temu zaradzić? Warto posadzić przed naszym tworem kogoś, kto ma zacięcie do dłubania, przyglądania się, zastanawiania nad sensem. Może to być specjalista od usability, analityk, sprzedawca, kierownictwo, użytkownik, reprezentant klienta (chociaż lepiej wyłapywać brzydactwa przed puszczeniem ich w świat), może tester albo programista z taką szerszą, biznesową perspektywą. Ktoś, kto po prostu chce, żeby nasz produkt był doskonały. Albo chociaż dobrze robił to, po co został powołany do życia.
Analiza sensu
Jak odnaleźć sens i sprowadzić nasze dziecko z manowców?
Po pierwsze primo. Czy to spełnia cel biznesowy?
To pierwsze i najważniejsze, co powinno zostać ustalone w projekcie. Po co to robimy? Co chcemy osiągnąć? Tylko tak jesteśmy w stanie kontrolować, czy robimy dobry system. Inaczej robimy cokolwiek. Siedzieliście kiedyś na spotkaniu, które nie miało wyznaczonego celu, ale każdy chciał, żeby do czegoś doprowadziło? Jak było?
Priorytety
Kiedy tworzymy coś od nowa albo wprowadzamy zmiany, warto pamiętać – „First things first”. Czasem robimy coś, bo jest fajne, pierwsze w alfabecie albo na jakieś liście, a nie pomyślimy, że inna funkcja szybciej pomoże w osiągnięciu wyznaczonego celu.
Czy się chce tego używać?
Zazwyczaj robi się systemy, żeby ich ktoś używał. Dawniej program był cudem techniki, od którego wymagało jedynie się działania i wzdychało z zachwytu. Później zaczęto myśleć o użyteczności i dbać o użytkownika – żeby jemu było miło, przyjemnie i żeby znajdował to, po co przyszedł. Zastanówmy się czy naszego cudu używa się dobrze? Czy się chce go używać?
Sytuacje wyjątkowe
Warto zrobić system, jak to się mówi „idiotoodporny”. Nie ubliżając. Czasem się komuś ręka omsknie, albo nawet z winy systemu stanie się coś niespodziewanego. Dobrze jest przeanalizować wszystkie sytuacje wyjątkowe. Opis przypadków użycia jest dobrym do tego miejscem.
Przebiegi alternatywne
Jak można to wykonać inaczej? Pomyśl, znajdź te sposoby i upewnij się, że każdy z nich daje oczekiwany wynik i wspiera cały czas cel biznesowy.
System, który sprawia, że osiągnięte zostają postawione przed nim cele, to nie dzieło przypadku i zgadywanek. Możemy podnieść jego jakość i efektywność w prosty sposób – przemyśleć, czy to ma sens?
