poniedziałek, 4 kwietnia 2016

Zanim - czyli o projektowaniu


“Zanim” to takie sobie słowo. Właściwie w oderwaniu od innych słów nie znaczy nic. Przy “zanim” zawsze muszą stać jakieś dwie czynności, z których ta druga, powinna zaistnieć przed tą wymienioną na pierwszym miejscu. Zanim umyjesz głowę, powinnaś rozczesać włosy. Zanim ruszysz samochodem - zapnij pasy. Zanim zaczniesz gotować obiad - załóż fartuch. To co robimy “zanim”, może nas ustrzec przed wieloma - może nie tragicznymi, ale na pewno często niezbyt przyjemnymi konsekwencjami różnych działań. Programowanie, jak każda inna dziedzina - ma również kilka swoich szalenie ważnych “zanim”.

            Rozpoczęcie nauki programowania nie dla każdego jest przyjemnym i naturalnym zestawem czynności, a powody dla których łapie się tego bakcyla, są przeróżne. Warto jednak pamiętać o tym, że samo pisanie kodu to jeszcze nie do końca programowanie, a cały proces powstawania różnych produktów jest poprzedzony wieloma różnymi elementami. Takim, do którego przywiązuje się obecnie coraz większą wagę, jest projektowanie - a szczególnie - projektowanie z uwzględnieniem doświadczeń użytkownika, czyli User Experience Design. Ostatnią rzeczą, którą mogłabym powiedzieć na temat tej metody to to, że jestem jej znawczynią - tym niemniej - zapraszam do przyjrzenia się kilku “zanim”, jakie UX (bo tak nazywamy ją w skrócie) ze sobą niesie.

1.    Zanim pomyślisz “jak?” - pomyśl “dla kogo?”

Rdzeniem UX, jak sama wspomniana wcześniej nazwa wskazuje, jest użytkownik danego programu, strony www lub aplikacji. Zanim więc przymierzymy się do wymyślania samej aplikacji - nawet jeśli mamy już pomysł na jej wygląd czy funkcjonalności, warto przyjrzeć się jej późniejszym użytkownikom. Podczas działania, które realizowaliśmy z dziećmi uczestniczącymi w Mistrzach Kodowania oraz ich rodzicami, warsztaty z projektowania aplikacji poświęconej Ogólnopolskiej Nagrodzie Literackiej im. K. Makuszyńskiego rozpoczęliśmy właśnie od zbudowania sylwetek potencjalnych użytkowników. Stworzyliśmy w tym celu trzy persony, czyli osoby, które według nas mogłyby najczęściej korzystać z takiej aplikacji. Określiliśmy płeć, wiek i zainteresowania tych osób. Zastanawialiśmy się nad tym, co robią w wolnym czasie, jakie mają marzenia, z czym mają największe problemy - i najważniejsze - jak to wszystko łączy się z naszą aplikacją.
            Wpisując w wyszukiwarce proste zapytanie “persona UX” dostajemy sporą ilość dobrych merytorycznie wyników, dzięki którym można dokładniej i głębiej zrozumieć korzyści płynące z tworzenia person przy projektowaniu technologicznych rozwiązań. Dodając do tego zapytania słowo “szablon” - możemy przebierać w dostępnych za darmo, gotowych wzorcach, które mogą poprowadzić nas, albo nasz zespół przez tę fazę projektowania. Bardzo ciekawym pomysłem jest wykorzystanie scenariusza persony z materiałów poświęconych grywalizacji, wydanych przez Fundację Orange ((http://grywalizujemy.pl/). Dobrze jest zatrzymać się na tym etapie “zanim” naprawdę na długo i pozwolić sobie w niego wsiąknąć. To, czy zrozumiemy dla kogo i po co tworzymy, na pewno przełoży się na dalsze działania.

2. Zanim zaczniesz tworzyć - pomyśl “jak”

            Kolejnym ważnym etapem, poprzedzającym w programowaniu samo kodowanie, jest zaprojektowanie samych funkcjonalności aplikacji, programu, czy strony. Na naszych warsztatach, po zastanowieniu się, jakie elementy byłyby najbardziej przydatne stworzonym przez nas personom, staraliśmy się je rozłożyć na części pierwsze i dokładnie opisać, krok po kroku, jak będzie się w nich poruszał użytkownik. To czas, kiedy można skorzystać z gotowych, darmowych szablonów ekranów, guzików, przeglądarek etc. (na przykład stąd: https://www.smashingmagazine.com/2010/03/free-printable-sketching-wireframing-and-note-taking-pdf-templates/) i zaprojektować drogę użytkownika w aplikacji oraz rozplanować ekrany, strony, przyciski, okienka i ich wzajemne powiązania. W rozwinięciu tego punktu można by napisać naprawdę wiele, najważniejsze jest jednak to, że kiedy mamy już prototyp na papierze, powinniśmy jak najszybciej przenieść go do wersji cyfrowej i zapoznać się z kolejnym “zanim”.

3. Zanim wdrożysz produkt - twórz, testuj, poprawiaj, testuj, poprawiaj… i tak w kółko :)

            Nawet najlepszy prototyp na papierze jest niewiele wart, jeśli nie możemy go przetestować “na żywo”. Na naszych warsztatach kilka razy okazało się, że rozwiązanie, które zostało naprawdę dogłębnie przemyślane i przeanalizowane na papierze, po “zakodowaniu” wydawało się pozbawione sensu. Wybór narzędzia, nasze umiejętności, na tym etapie oczywiście weryfikują wypracowane przez nas dotychczas rozwiązania, warto jednak trzymać się tego, co zrobiliśmy jako pierwsze “zanim” - czyli odpowiedzi na pytanie “po co” i “dla kogo” tworzymy. W samym kodowaniu projektu, z punktu widzenia zadowolenia końcowego użytkownika, kluczowe są częste testy. Warto dzielić się z zaufanymi, niezwiązanymi z projektem osobami, tym, co już udało nam się zrobić. Warto - nawet po wprowadzeniu do naszego programu czy aplikacji niewielkich zmian - prosić o jej przetestowanie. I poprawiać. I testować znów. I poprawiać. I tak aż do momentu, kiedy efekt będzie satysfakcjonujący dla nas, jako twórców, ale również dla wszystkich (albo większości - zawsze musimy wziąć pod uwagę indywidualne preferencje) testujących. I już - teraz możesz pochwalić się swoim dziełem ze światem. Oczywiście możesz pamiętać o jeszcze jednym “zanim”.

4. Zanim zaczniesz projektować - baw się!

            Zaprezentowane tu podejście projektowe jest dobre, albo nawet bardzo dobre - w moim bardzo osobistym mniemaniu - w dwóch przypadkach. Kiedy pracujemy z grupą, która w ogóle nie potrafi programować i część związana z zakodowaniem wymyślanego rozwiązania przypadnie w udziale komuś innemu, albo - kiedy pracujemy z grupą, która potrafi od a do zet wykonać wszystkie kroki “zanim”. Szczerze przyznaję, że nie wiem, czy ta obserwacja znajduje potwierdzenie w zdaniach specjalistów, ale doświadczenie pokazało mi, że warto zacząć przygodę z programowaniem również od nieskrępowanego niczym “kodzenia”. Sztuki dla sztuki. Tworzenia programów - zabawek. Nieprzydatnych. Niepotrzebnych. I w tym wszystkim pięknych. Warto - obok wszystkich “zanim” - mieć swoją własną ścieżkę nauki - na tyle wygodną, żeby za szybko z niej nie zejść, ale też na tyle niewygodną, żeby kroczenie po niej sprawiało nam satysfakcję.

autorka: Anna Krawczyk
Share:

0 komentarze:

Prześlij komentarz