Rola projektantów w strukturze korporacji

W dużej organizacji zajmującej się internetem, wraz z postępującą profesjonalizacją, prędzej czy później powstanie dział zajmujący się projektowaniem. Aby nie stał się wydmuszką do robienia makiet, trzeba sensownie odpowiedzieć na pytanie gdzie zaczyna się, a gdzie kończy rola projektantów i jaką pozycję powinien mieć dział projektowania w strukturze całej organizacji?

Dla wygody podzielę typowy projekt internetowy na dwa etapy: biznes i realizację. Projektowanie intuicyjnie pakujemy do części realizacyjnej. Na tym etapie najwyraźniej widać pracę projektantów (choćby dlatego, że wtedy powstają owe makiety) i na nim skupię się najbardziej. Nie można jednak ani na chwilę zapomnieć, że głos projektantów powinien być słyszalny także na etapie decyzji biznesowych. Projektanci powinni w nich uczestniczyć w roli konsultantów. Są bowiem dobrym filtrem, umożliwiającym wykluczenie lub przedefniowanie pochopnych projektów, opierających się nie tyle na konkretnej potrzebie biznesowej, co pomyśle konkretnego rozwiązania (np. „dajmy na stronie głównej boks z kalendarzem imprez, najlepiej po lewej stronie„). Projektanci są także w stanie określić stopień trudności projektu, sygnalizując, co tak naprawdę oznacza pomysł proponowany przez biznes. Jednak ludzie od UX to nie tylko hamulcowi wszelkich zmian. Projektant biorący udział w określaniu strategii lub wyznaczaniu celów może znacznie wzbogacić projekt i zainspirować menadżerów lub sponsorów do innego niż pierwotne spojrzenia na projekt (np. za pomocą person i wiedzy na temat ich wykorzystania).

Główna część aktywności projektantów to jednak realizacja. Jest to obszerny worek i warto zadać pytanie o umiejscowanie w nim projektanta lub działu projektowania. Pierwszym odruchem jest umieszczanie projektantów na najwcześniejszym etapie realizacji. Tam, gdzie zbiera się wymagania i proponuje rozwiązania (na przykład w postaci makiet), które pozwolą te wymagania zrealizować. Potem ich rola nagle się kończy, a następuje etap projektowania graficznego oraz implementacji programistycznej (dla uproszczenia wrzucę tutaj od razu cały web developing). O projektantach pamięta wówczas już mało kto. A przecież to własnie Ci ludzie mają najlepsze kompetencje ku temu, aby oceniać i krytykować zarówno projekt graficzny, jak i wynik implementacji. Doświadczenie pokazuje, że kompromisy, które pojawiają się nieuchronnie w czasie projektu, najczęściej zdarzają się właśnie na etapie grafiki i implementacji. Powinno więc istnieć ciało, które będzie potrafiło te kompromisy ocenić i podjąć w ich kwestii decyzje. Tym bardziej, że nawet niewielka zmiana w stosunku do rozwiązania przygotowanego przez projektanta może zniweczyć sens funkcjonalności lub całej strony. Gdy jednak dochodzi do podejmowania decyzji pojawia się problem umocowania projektantów. Wydaje się, że modele są dwa.

Model 1: Projektanci jako audytorzy

W pierwszym specjaliści UX pełnią rolę audytora. Oceniają projekt graficzny i implementację programistyczną, forumłują rekomendacje, ale decyzje co do ich przyjęcia, odrzucenia lub zgody na kompromisy pozostawione są w rękach sponsora lub menadżera projektu. Ten model z pozoru wydaje się najwłaściwszy, jednak jest w nim ukryte pewne niebezpieczeństwo. Jeśli projektanci nie będą posiadali wystarczającego autorytetu lub umiejętności komunikacyjnych, ich rekomendacje nie będą na serio brane pod uwagę przez osoby decydujące. Internet to miejsce, w którym każdy zna się na wszystkim, a na projektowaniu w szczególności. Istnieje duże ryzyko, że project managerowie lub sponsorzy będą podejmować decyzje w oparciu o przeczucia lub stereotypowe przekonania. Mogą też zwyczajnie nie dostrzec pewnych konsekwencji albo je zbagatelizować.

Model 2: Projektanci jako nadzorcy

Odpowiedzią na ten problem wydaje się model drugi, który oznacza znacznie silniejszą pozycję projektantów. W tym (dość odważnym) rozwiązaniu pełnią oni rolę nadzorcy nad etapem projektowania graficznego oraz implementacji. Są uprawnieni do decydowania o zmianach na tych etapach oraz wyrażania zgody na kompromisy. Te uprawnienia wymagają od projektanta dużo więcej niż tylko wiedzy z zakresu swojej profesji. W tym modelu projektanci powinni posiadać jakiś poziom umiejętności zarządzania projektem, ale przede wszystkim mieć pewne wyczucie biznesowe. Jeżeli będą aktywnie uczestniczyć w etapie inicjowania projektu, a więc będą mocno osadzeni w strategii, celach i powodach powołania projektu, to na etapie realizacji będą w stanie skuteczniej od innych podejmować decyzje projektowe. W czasie robienia stron, coraz częściej kluczową rolę pełni bowiem wiedza, którą mają właśnie projektanci, a która jest zbyt rozległa, aby obarczać obowiązkiem jej posiadania także project managera. Oprócz tego właściwie tylko projektant będzie w stanie dostrzec wszystkie konsekwencje ewentualnych zmian na etapie realizacji. To on zaprojektował stronę, więc także on wie najlepiej, z iloma elementami powiązana jest zmiana.

Ten model pozwala także najlepiej dystrybuować w organizacji wiedzę i swoistą intuicję specjalistów UX. Praca projektantów w dużej mierze opiera się na wypływającym z doświadczenia wyczuciu. Można powiedzieć, że dobry projektant stale czuje na plecach oddech swojego użytkownika. Graficy i programiści na co dzień tkwią w nieco innych od projektanta obszarach wiedzy. Jedni i drudzy (szczególnie programiści) rzadko kiedy zastanawiają się nad odbiorcami. To nic złego, bo ich profesja polega na rozwiązywaniu innych problemów. Jednak to ich praca ostatecznie przekłada się na doświadczenia użytkowników, a owego wyczucia nie da się nauczyć inaczej, niż przez kontakt z ludźmi, którzy już je mają. Projektant umocowany do nadzorowania grafiki i implementacji będzie więc w stanie zadbać o to, aby z etapu realizacji nie umknął element myślenia o ludziach, którzy będą z tworzonej strony korzystać. Można powiedzieć, że zadaniem ludzi od UX jest tchnięcie „ducha użytkownika” do rzemieślniczego procesu produkcji. Z tego powodu ten model powienien szczególnie sprawdzić się w tych organizacjach, które poważnie traktują podejście User Centered Design.

Projektant jako asertywny przewodnik

W dużych organizacjach ogromne znaczenie ma historia. Robieniem stron w dużych korporacjach od zawsze zajmowali się wszyscy – redaktorzy, marketingowcy, itp. Każdy miał coś do powiedzenia. Większość ludzi, zajmujących się internetem, wie czym jest usability i zna podstawowe błędy, których nie należy popełniać. Problem w tym, że o ile każdy może narysować dom, o tyle tylko garstka jest architektami. Może być dość trudno budować kulturę, w której redaktorzy, graficy, programiści, moderatorzy, ale także dyrektorzy i menadżerowie zaufają w kompetencje projektantów. Niemniej trzeba to robić. Model drugi to ułatwia, tworząc faktyczne, silne umocowanie projektantów.

Oczywiście ludzie pracujący w działach UX tak czy inaczej powinni być obdarzeni pewnością siebie i silnym autorytetem. Te cechy są im niezbędne choćby po to, aby być asertywnym i po prostu móc się czasami nie zgodzić. Projektanci są bowiem chyba najczęściej narażeni na krytykę i propozycje kompromisów w trakcie całego projektu. Aby pozostać otwartym i nie okopywać się, a jednocześnie umiejętnie balansować pomiędzy interesami poszczególnych grup korporacyjnych lobbystów, a dobrem użytkownika (bo najlepsze rozwiązanie musi najczęściej godzić kilka punktów widzenia, jak pisał Marek Kasperski), trzeba przede wszystkim mocno wierzyć w swoje umiejętności. Dział projektowania, aby nie zakończyć swojej działalności na robieniu makiet, musi też znaleźć wsparcie i zrozumienie managementu. Jeśli tam go nie będzie, nie ma co liczyć, że pojawi się niżej.

Realizacja projektu internetowego przypomina drogę podzieloną na wiele etapów. Dział projektowania powinien pełnić rolę przewodnika, który zadba o to, aby nikt nie stracił z oczu, dokąd ta droga ma nas zaprowadzić. W czasie realizacji tylko projektant będzie zawsze myślał o użytkowniku i kontekstach, w jakich będzie on używał projektowanej strony. Na pytanie, na jakim etapie tej drogi organizacja powinna więc umieścić projektanta, najsensowniej jest odpowiedzieć – nad nią.

W tym temacie warto poczytać

Ten wpis umieszczono w kategorii korporacja, projektowanie i otagowano jako , , . Możesz dodać go do zakładek permalink. Dodaj komentarz lub dodaj odpowiedź (trackback): Trackback URL.

2 Komentarze

  1. kupmikawe
    Opublikowano 13 października 2010 at 21:44 | Permalink

    Jest jeszcze 3 droga. Projektant jako udziałowiec biznesowy. Jeśli projektanta umieści się w roli współwłaściciela projektu to jego rola zawiera wszystkie niezbędne atrybuty. Może decydować, musi zwracać uwagę na biznes, a sam nie jest uwikłany bezpośrednio w proces wytwórczy. Do tego ma kontakt z klientem. Tylko takie podejście wymaga dużego doświadczenia, wielu kompetencji, zaufania i światłego kierownictwa organizacji. Jednak kiedy projektant UX wchodzi jako outsourcing praktycznie staje się niezależny.
    BTW nie ma nic gorszego jak wstawić projektanta UX do zespołu deweloperskiego, choć zdecydowanie może się on wiele nauczyć, to jego rola będzie marginalna i o wszystkim będzie dowiadywał się ostatni.

  2. Opublikowano 18 lutego 2011 at 15:24 | Permalink

    Bardzo ciekawy tekst. Osobiście skłaniam się ku opcji holistycznej, którą próbowałem przedstawić w swoim wpisie. Z chęcią poznam opinie autora na te temat: http://www.ucd.com.pl/2011/02/11/rola-projektanta-interakcji-w-projektowaniu-serwisow-www/

2 Trackback'i

  1. [...] w którym ma się znajdować dział użyteczności (więcej na blogu Adama Plony we wpisie Rola projektantów w strukturze korporacji) interesujące jest, w jaki sposób można mierzyć i oceniać zatrudnionego specjalisty do spraw [...]

  2. Autor Skalowalność w projektowaniu 24 listopada 2010 o 16:41

    [...] Plona na co dzień robię sajty, a tu czasem piszę « Rola projektantów w strukturze korporacji Skalowalność w projektowaniu Przez Adam | Published: 24 listopada [...]

Skomentuj

Twój adres email nie zostanie opublikowany i nie będzie rozpowszechniany. Wymagane pola są oznaczone *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>