Architektura vs. (tak zwane) projektowanie UX.

Jestem z wykształcenia architektem. Po studiach pracowałem kilka lat jako architekt, ale szybko zdałem sobie sprawę, że projektowanie UX jest tym, czym naprawdę chcę zajmować się z życiu. Obecnie pracuję w K2 jako Senior Product Designer.

W tym artykule zamierzam porównać architekturę z projektowaniem UX, i podzielić się moimi wnioskami na temat różnic i podobieństw tych dwóch dyscyplin.

Dla ułatwienia będę używać terminu UX (User Experience, w niezręcznym tłumaczeniu "doświadczenia użytkownika"), ale wszyscy wiemy, że nie jest to najlepsza, czy nawet poprawna, nazwa dla tej domeny.

Różnice.

Wydaje się oczywiste, że architektura posiada wiele różnic w porównaniu z projektowaniem UX, ale kilka z nich jest bardzo szczególnych i mogą dać one całkiem inne spojrzenie na to zagadnienie.

Dojrzałość.

Architektura towarzyszy nam od wieków. Pierwsze budowle, które służyły celom mieszkalnym, pojawiły się w epoce Neolitu (ok. 10 000 lat p.n.e.). W projektowaniu UX porównałbym te zabudowania do tzw. wiersza poleceń (z ang. CLI – Command-Line Interface – jeden z pierwszych i podstawowych sposobów interakcji człowieka z komputerem): obydwa nie wyglądają zbyt przyjaźnie, nie są zbyt wygodne, czy łatwe w użyciu, ale zaspokajają podstawowe potrzeby ich użytkowników.

Nie mniej, znacząca świadomość tych dwóch dyscyplin pojawiła się dopiero po jakimś czasie. W architekturze, możemy odnieść się do pierwszej książki poruszającej zagadnienie projektowania architektonicznego – była to “De architectura” napisana przez Witruwiusza w pierwszym wieku naszej ery. Dotyczyła ona bardzo wielu aspektów, które wydają się aktualne do dziś. Z drugiej strony, w projektowaniu UX, możemy wymienić Dona Normana i wprowadzony przez niego w 1995 roku termin “User Experience” – co było swojego rodzaju ewolucją podejścia do tzw. HCI – Human-Computer Interaction.

Patrząc na same daty możemy zauważyć ogromną rozbieżność w dojrzałości tych dwóch dyscyplin, ale nie wolno zapomnieć, że sama dynamika rozwoju odgrywa tu też istotną rolę.

Produkt.

Zapewne nie jest zaskoczeniem fakt, że produkt projektowania architektonicznego i UX jest czymś kompletnie innym, ale dobrze jest na niego spojrzeć także w kontekście analogii.

Zaznaczam, że przez projektowanie UX mam na myśli obszar, który nie jest “napompowany” takimi terminami jak Human Experience, Customer Experience, Product Design, czy im podobnymi, które celowo ignoruję w tym konkretnym porównaniu.

Skoro architektura “dostarcza” produkty fizyczne, materialne, to projektowanie UX jest odpowiedzialne, za produkty cyfrowe. Jeśli myślimy o przestrzeni jak o “płótnie” architekta, to możemy odnieść je do ekranu, który jest medium dla projektanta UX. Idąc głębiej możemy zdefiniować budynek (jako jedną z najbardziej popularnych struktur/budowli, z którą użytkownik wchodzi w interakcję) i jego cyfrowy odpowiednik – interface – powiedzmy, że aplikacji.

Tego typu analogie możemy z łatwością stosować do innych skal (większych i mniejszych), choć to zamierzam omówić poniżej jako jedno z podobieństw.

Długość procesu.

Ta różnica jest ogromna i jest chyba jedną z tych, które odegrały znaczącą rolę w mojej decyzji dotyczącej przekwalifikowania się na projektanta UX.

W architekturze, zanim zobaczysz produkt – prawdziwy rezultat Twojej pracy – zazwyczaj mijają miesiące, nie rzadko więcej niż rok (wliczając etap budowy). W tym samym czasie z powodzeniem można wdrożyć wiele produktów cyfrowych, takich jak aplikacje czy strony internetowe, które spełniają swoją funkcję i zapewniają wystarczającą jakość. W wielu przypadkach można zaprojektować i wdrożyć MVP (minimum viable product) w ciągu zaledwie kilku dni – jest to znacząca przewaga dla niecierpliwych projektantów.

Długość życia.

Jak można się spodziewać, długi proces prowadzi do długo istniejącego produktu. Nie jest nietypowym, żeby budynki istniały po 50 lat… a i wiele z nich z pewnością postoi jeszcze kolejne 50 lub więcej. Ten fakt może być bardzo wynagradzający dla architekta, choć oznacza również ogromną odpowiedzialność.

W projektowaniu UX sprawa wygląda prościej: projektujesz apkę, która w ciągu roku zapewne zostanie zaktualizowana do dumnej wersji 2.0 po to, by za kolejny rok otrzymać nową “modną” nazwę, a następnie zostać zapomnianą, sprzedaną lub po prostu zniknąć z rynku – nie jest to nietypowe dla produktów cyfrowych.

Badania.

Ten obszar nie jest zbyt pochlebny dla architektów. Ich badania ograniczają się zazwyczaj do kontekstu, co w teorii nie jest złym podejściem – dbają oni bardzo o otocznie, relacje z innymi budynkami, przestrzenią miejską, skalą ulicy, itp. Niestety, niejednokrotnie brakuje spojrzenia na potrzeby użytkownika – są one z łatwością zamieniane na potrzeby biznesowe, kontekst biznesowy. Czasy, gdy potrzeby użytkownika były najwyższym priorytetem minęły dziesiątki lat temu.

Z drugiej strony, projektowanie UX ani trochę nie ignoruje użytkownika. Proces projektowy zazwyczaj jest poprzedzony dokładnymi badaniami, prototypy są testowanie z użytkownikami, skończony produkt jest dogłębnie i stale analizowany. Biznes odgrywa tutaj również istotną rolę, ale ma znacząco mniejszy wpływ na ostateczne doświadczenia użytkownika.

Autorstwo.

Tę różnicę lubię szczególnie, bo jest trochę kontrowersyjna.

Budynki – w odróżnieniu od obrazów – nie są zazwyczaj podpisywane imieniem i nazwiskiem autora. Nie mniej, jesteśmy w stanie rozróżnić wiele budynków po “stylu” projektowym i wymienić nazwisko autora. Nie mówię tu tylko o dość wyrazistych osobowościach jak Gaudi, ale o bardziej “stonowanych” architektach jak Frank Lloyd Wright, Mies van der Rohe, Zaha Hadid, Norman Foster czy Bjarke Ingels (choć tego w zasadzie trudno nazwać “stonowanym”). Wszyscy oni mają swoje przekonania, ich własne idee, własne środki wyrazu, które sprawiają, że ich budynki stają się unikalne bez utraty na jakości, czy też funkcjonalności.

To wszystko nie ma miejsca przy produkcie cyfrowym. Oczywiście jest to zupełnie inny produkt z innymi możliwościami ekspresji autorstwa, ale wciąż – jest to duża różnica, która znaczy dla mnie bardzo wiele.

Podobieństwa.

Teraz pora na wypunktowanie podobieństw. Nie zawsze są one oczywiste, ale przy odrobinie uproszczenia, możemy wyciągnąć ciekawe wnioski, które ukazują te dyscypliny w całkiem nowym świetle.

Proces.

Wcześniej wspomniałem o tym, że długość procesu jest czymś, co odróżnia architekturę od projektowania UX. Nie mniej fazy, które mają miejsce w tych proces są z łatwością porównywalne.

Pomijając fazę planowania strategicznego, w projektowaniu architektonicznym zaczynamy od analizy – tak, jak w projektowaniu UX zaczynamy od badań. Następnie jesteśmy gotowi, żeby skupić się na projektowaniu użyteczności (funkcja), które oczywiście zazębia się i miesza z projektowaniem estetycznym (forma), ale w podobny sposób w obydwu tych dyscyplinach. Na końcu przychodzi oczywiście pora na realizację, czyli na nic innego jak na budowę/wdrożenie.

To, co jest w tym wszystkim wysoce pożądane, to nadzór autorski podczas całego procesu – zapewnia on, że idea zostanie zrealizowana zgodnie z zamierzeniami pierwotnymi, bez zbędnych niedociągnięć, czy ubytków.

Produkty pośrednie.

Z pewnością nie są one takie same, ale mają bardzo wiele wspólnego.

Szkic jest zazwyczaj najłatwiejszym sposobem na “start” – bez znaczenia, czy szkicuje się plan domu, czy tzw. wireframe aplikacji. Ołówek i papier służą tu doskonale zarówno architektowi jak i projektantowi UX. W UXie dość powszechne jest tworzenie makiet, ale przecież i architekci budują makiety. Cel jest trochę inny, ale sama makieta pozwala spojrzeć na projekt z innej perspektywy (nierzadko dosłownie). Prototyp, z drugiej strony, jest już raczej czymś szczególnym dla procesu UX – używany jest często do testów, co oczywiście nie jest wykonalne podczas projektowania, powiedzmy, dużej przestrzeni biurowej. W obydwu dyscyplinach potrzebna jest dokumentacja techniczna – głównie na potrzeby budowy/wdrożenia – i jest to naprawdę porównywalne w obydwu tych przypadkach.

To, co sprawia, że projektowanie UX jest łatwiejsze, to fakt, że podczas całego procesu wszystkie produkty pośrednie są w skali 1:1 – od samego początku do końca. Co prawda sprawia to, że produkt cyfrowy jest mniej zaskakujący na samym końcu – mało co można porównać do ewolucji surowego szkicu, który przekształca się w realny budynek, zmieniając otaczającą przestrzeń na lata (i oby na dobre).

Skalowalność.

Przy opisie tego podobieństwa posłużę się kolejny raz przykładem aplikacji w projektowaniu UX, bo jest ona bardzo odpowiednia podczas porównania z budynkiem.

Projektując nie powinniśmy myśleć tylko o skali, w której obecnie pracujemy. Nie tylko ze względu na szerszą strategię, ale także ze względu na to, że w każdej skali mamy możliwość (jeśli nie obowiązek), wyrażenia naszej idei: bez znaczenia czy jest to widok zadań do wykonania (w aplikacji to-do), czy przycisk, który te zadania dodaje – wszystko powinno być ze sobą związane i spójne. Dobry budynek wygląda dobrze nie tylko z ulicy; jego idea, styl, jakość są widoczne w przestrzeniach wewnętrznych, ale i w najmniejszych detalach, jak np. klamki.

Komponenty.

Podobieństwa są także dostrzegalne w samym produkcie, w jego komponentach, choć jest to trochę bardziej złożone i abstrakcyjne.

Zacznijmy od popularnych technologii webowych: HTML, CSS i JavaScript. Wszystkie służą jakiemuś celowi i wszystkie z nich mają swój odpowiednik w architekturze. Jeśli HTML jest odpowiedzialny za to jak jest coś zbudowane, to struktura (konstrukcja i przegrody) są jego analogią. Jak myślimy o CSS i o tym jak coś wygląda, to możemy porównać to do formy budynku, jego materiałów, elewacji, itp. JavaScript sprawia, że coś zaczyna działać, tak jak funkcja budynku nadaje mu prawdziwe i ostateczne przeznaczenie.

Dobór technologii, też odgrywa znaczącą rolę w projektowaniu zarówno produktów cyfrowych jak i budynków. Jest odpowiedzialna za dostarczenie wszystkich innych komponentów i elementów, które powinny być użyte.

Podejście do afordancji.

Afordancja jest ważnym terminem w projektowaniu. Był on wprowadzony przez psychocholga Jamesa J. Gibsona, ale później użyty został przez Dona Normana w odniesieniu do Interakcji Człowiek-Komputer (HCI), gdzie w tym kontekście oznaczał właściwości obiektu, które dają (lub nie) wskazówki jak go używać. Innymi słowy: przycisk powinien wyglądać jakby dało się go nacisnąć i jakby miało to sprawić, że coś się wydarzy.

W architekturze od lat istnieje fraza, która koresponduje z afordancją: "forma wynika z funkcji". Była ona wprowadzona przez Louis Sullivana (amerykański architekt, 1856–1924) i bardzo rozpowszechniona w modernizmie. Oznacza ona, że forma, kształt, czy wygląd obiektu (nie tylko budynku) powinny odnosić się i wynikać z jego funkcji i przeznaczenia. W związku z tym wejście powinno wyglądać jak miejsce, którym można dostać się do budynku – nie jak witryna, która znajduje się obok niego (to zdecydowanie zbyt ordynarny przykład, jak na tę teorię).

Ten koncept jest bardzo powszechny i widoczny zarówno w architekturze jak i projektowaniu UX.

Podejście do skeumorfizmu.

Skeumorfizm to kolejne “modne” hasło szeroko rozpowszechnione w projektowaniu UI. Oznacza nic innego jak udawanie i imitowanie obiektów rzeczywistych i materiałów w „interfejsie”. Jeszcze nie tak dawno panował trend pokazywania tekstury papieru w każdej aplikacji do notowania (aplikacja Notes w iOS nadal ją posiada!), nadawania przyciskom plastikowego, trójwymiarowego wyglądu, czy nawet stosowania wzorów ceglanych ścian na tła pulpitów czy stron internetowych (!). Szczęśliwie ten trend się zakończył.

Większość z najlepszych budynków nie używa udawanych materiałów. Prawdziwe piękno pochodzi ze szczerości materiału: bez znaczenia czy jest to ciepłe drewno, czy surowy beton. Ten trend istnieje już od dłuższego czasu i mam nadzieję, że pozostanie na długo.

Opcja "zero" JEMSów.

Mogliście nie słyszeć o polskim biurze architektonicznym JEMS, ale nakłaniam Was, żebyście zapoznali się z ich projektami (www.jems.pl). Są oni bez wątpienia jednym z najlepszych zespołów architektonicznych w Polsce.

W swoich projektach kierują się zbiorem zasad, które nazywają opcją “zero” – odnosząc się do wzorców i wartości zrozumiałych dla każdego:

1. ...
2. Stosowność i proporcjonalność.
3. Czytelność i jednoznaczność formy.
4. Spójność formy, funkcji, konstrukcji, technologii.
5. Spójność (homogeniczność) całości i detalu.
6. Jednorodność materiałowa.
7. Prawda o materiale – naturalne materiały.
8. Rytm, ciągłość, integracja.

(Te zasady zanotowałem kilka lat temu, więc istnieje niewielkie ryzyko, że zostały od tego czasu nieznacznie zaktualizowane.)

Jak widać, większość z tych punktów może zostać zastosowana nie tylko do architektury, ale i do projektowania UX. Nie mniej, najważniejszy jest tu punkt numer 1:    

1. Po pierwsze: Użytkownik.

Więc czym jest architektura, skoro nie projektowaniem (dla) doświadczeń użytkownika?

Autor: Marcin Ukleja.

Ten artykuł został oryginalnie opublikowany w magazynie UX Collective na Medium.