Lekcja 1
Systemy IT i aplikacje, Proces UCD i wartość z UXa
Warto rozumieć jak działają komputery kiedy projektuje się systemy IT. Osobiście lubię to pojęcie, mówię też o programach komputerowych – o dziwo, pojęciu tak rzadko stosowanym w świecie UX.
UXowcy mówią o produktach cyfrowych. Długo obawiałam się tego pojęcia. Może niektóre programy komputerowe to rzeczywiście są produkty, ale moim zdaniem, nie tylko. To są produkty i usługi w jednym.
Kiedyś mój światopogląd uległ zmianie, kiedy po raz pierwszy usłyszałam o „narzędziach”. A konkretnie o „najbardziej zaawansowanych narzędziach znanych ludzkości”.
Jakby tego nie nazwać, to o ile od czasów kiedy ja się uczyłam informatyki nie nastąpiła jakaś rewolucja, o której nie słyszałam, to wciąż są one budowane w dość podobny sposób.
Wszystkie z poniższych, no, może oprócz HTMLa to rodzaje oprogramowania.
Istnieje logiczny podział oprogramowania na warstwy. Zwykle 3. Jest to model MVC, czyli Model, View, Controller. Kolejność liter w tym akronimie jest albo losowa, albo dobrze brzmi, ponieważ M oznacza Model, czyli model danych, a więc bazę danych. Gdyby system był ułożony w stos, to baza danych byłaby fundamentem, a więc na samym dole. Następny w kolejności jest Controller. Mówi się o nim również Business Logic albo moduł logiki biznesowej. To serce systemu, tam zdefiniowane jest co system robi. Czasami mówi się o back endzie, aczkolwiek słyszałam też, że backendem niektórzy nazywają bazodanowców. Trzebaby jakiegoś backendowca zapytać. I na samej górze jest View, czyli UI, albo Front End, albo po prostu to, co widzi użytkownik końcowy.
Jak mówi się o Full Stack Developerach, to jest to programista, który potrafi w każdą warstwę.
Wszystkie trzy warstwy są zaangażowane w działającą aplikację (system).
Jak mówi się o „wertykalnym cięciu 'ficzerów'” (dla tych, którzy robią w agile’u), to mówi się o wycinku funkcjonalności, która przechodzi przez wszystkie warstwy. W przeciwieństwie od podziału horyzontalnego, który zakłada np. tylko UI albo tylko BE.
To jest też spore uproszczenie i dotyczy większości przypadków. Są systemy bez bazy danych, są systemy gdzie logika biznesowa jest zaszyta we front endzie, ale można powiedzieć, że to jest taki standard.
To, że to jest model logiczny, oznacza pewną koncepcję. Kod może być napisany na różne sposoby. Oprócz front endu, dużo logiki biznesowej może być zakodowane w bazie danych (mówi się wówczas, że logika jest tam „zaszyta”)
Aby programy komputerowe mogły działać potrzebują komputerów. (Smartphonów, smart watchy, tabletów, itp.)
Natomiast, gdyby każdy program miał rozmawiać bezpośrednio z kopmuterem, to znaczy odwoływać się do jego procesora i pamięci operując kodem binarnym, to każdy programista by się zapłakał. Za dużo kodowania. Dlatego potrzebne są Systemy Operacyjne, specjalne aplikacje, które pośredniczą pomiędzy sprzętem (które rozumieją tzw. języki programowania niskiego poziomu) a aplikacjami (które są pisane tzw. językami wysokiego poziomu).
Różne sprzęty miewają różne systemy operacyjne, a aplikacje pisane są pod dany system. Niektóre działają na kilku.
Aplikacje działające na systemie operacyjnym nazywamy natywnymi.
Szczególnym rodzajem aplikacji natywnej są przeglądarki internetowe. Przeglądarka może służyć jako środowisko do uruchamiania aplikacji. Są to RIA Rich Internet Application.
Przeglądarki „rozumieją” HTML, więc można napisać logikę biznesową i bazę danych do aplikacji, a następnie stworzyć UI w HTMLu (w przeciwieństwie do innych sposobów tworzenia interfejsów użytkownika). W tym sensie, przeglądarka poniekąd odgrywa rolę systemu operacyjnego.
Zaletą jest to, że ta sama aplikacja może działać na dowolnym komputerze, na którym zainstalowana jest przeglądarka. Jest to ogromna oszczędność dla każdego producenta oprogramowania, którego wytworzenie jest bardzo kosztowne, za to utrzymanie przyprawia o prawdziwy ból głowy.
To jest przykład interfejsu użytkownika aplikacji Asana.
To jest przykład kodu HTMLowego. To nie jest kod Asany, ale mniej więcej tak developer front endowy widzi to, co potem użytkownik widzie w formie ładnych obrazków. Zwróćcie uwagę na prawą stronę ekranu. To co jest widoczne na ekranie jest tylko małym wycinkiem całości. Kod zajmuje bardzo wiele linijek.
To jest przykład kodu backendowego.
To jest przykład bazy danych. Bazy można tworzyć w takim wizualnym edytorze, albo pisać „z palca”, czyli również będzie to tekst, czyli kod.
Ale zanim powstanie kod…
Kod, to wierzchołek góry lodowej, każdy produkt cyfrowy ma swój cykl życia. Firmy mogą mieć własny proces, i oczywiście jest rozróżnienie na Waterfall i Agile (o tym innym razem), ale wygląda to mniej więcej tak, że najpierw trzeba to zaprojektować, następnie zbudować, potem sprawdzić i w końcu wypuścić na produkcję – czyli do ludzi. A potem zaczynamy od nowa. Dlaczego? Bo software ma to do siebie, że „żyje”. Jest nieorganicznym organizmem. Wypuszcza się pierwszą wersję, a potem w nieskończoność rozwija.
Jak już wiemy co projektujemy, to możemy teraz o UXie w końcu.
Sensem życia aplikacji komputerowych jest aby były one używane przez ludzi. Przynajmniej tych, które posiadają interfejsy użytkownika. A ludzie, jak to ludzie, mają swoje humory (i preferencje, i percepcję) i wszystko to, czy czyni nas ludzkimi.
Jest wiele powodów, żeby zatrudnić specjalistę od UX, ale prawie zawsze dlatego, żeby wyciągnąć z produktu największą wartość.
To pytanie jest tendencyjne, nie musicie na nie odpowiadać, ale warto mieć świadomość jak to działa. Dlatego tyle mówi się o etyce w projektowaniu.
System przynosi wartość tylko wówczas, kiedy ktoś z niego korzysta. Nieużywany, nie przynosi żadnej wartości.
Bardzo ważny slajd!
To jest realna piramida potrzeb. Produkt musi robić to, do czego został stworzony – a więc mieć niezbędną funkcjonalność. Musi być niezawodny, co z tego, że robi, jak się psuje? Jego użytkownik musi umieć z niego korzystać. Co z tego, że robi i to porządnie, jak nie umiem go obsłużyć? Dopiero kiedy to wszystko jest spełnione, można mówić o „zachwycaczach”. Nie wcześniej.
O procesie UXowym
Jest ich tak bardzo dużo…
Fundamentalnie, zawsze chodzi o to samo. Poznaj swoich odbiorców, zrozum jak myślą, zaprojektuj im rozwiązanie, stwórz i sprawdź czy działa.
Kiedyś wpadłam w paranoję, że nie wiem na czym polega Design Thinking, bo kiedy zaczynałam w UXie, tego pojęcia nie było. Pojechałam na warsztaty DT i… okazało się, że to po prostu proces projektowy. Nie da się projektować dobrze bez przejścia wszystkich faz. Da się te fazy wykonać źle, owszem, ale nie da się ich pominąć. Jako, że nie szkoliłam się w DT, z kolei latami podążałam podobnym procesem, szanując autorów, będę mówić o procesie projektowym, ale nie do DT.
Poczekajcie, dalej będzie więcej szczegółów o każdym z kroków, bo pewnie zauważyliście już, że Test jest po Develop i zastanawiacie się „gdzie prototypowanie?”. Będzie, obiecuję.
To chyba najtrudniejsza do wytłumaczenia metafora, ale sama ją wymyśliłam, więc spróbuję ją opisać.
Jazda konna jest trudna. Każdy, kto chce robić ją dobrze, musi ćwiczyć latami. Natomiast, istnieje w niej pewna logika, pewna spójność, która działa. Jak zrozumie się konia, można go nauczyć różnych sztuczek, nie jesteśmy ograniczeni do kłusu. To trochę jak z dobrym modelem mentalnym. Czasami działamy w trudnych dziedzinach, np. medycyna, albo lotnictwo. To nie są łatwe systemy. Ale jeśli rozumiemy domenę i stworzymy spójny system logicznych interakcji, korzystanie z aplikacji będzie bolało.
Jasne, prawda?
