   MOJE KSIĄŻKI - AUTOR
REDAKTOR MERYTORYCZNY
|
Blog > Komentarze do wpisu
"Projektanci są jak wino": Pić trzeba umićTytuł to parafraza tego, o czym napisał Andy Budd na swoim blogu, opisując dość istotny element naszej pracy - czyli wycenę. Artykuł Andy'ego jest na tyle zwarty, że nie widzę sensu 'pisania go na nowo' (polecam przeczytać), aczkolwiek moim zdaniem wymaga jednego, dość istotnego uzupełnienia.
1. Andy - w skrócie - napisał artykuł o kupowaniu kompetencji projektowych na rynku, gdzie odniósł się do kwestii wyceny prac jako kluczowego, bądź nawet jedynego, kryterium, którym kieruje się klient. Przy tej okazji ukuł całkiem zgrabne porównanie: "As humans we don’t carry around a constant notion of value in our heads. Especially not for something we’re inexperienced at purchasing. Instead we take input from our surroundings and make a decision from the range of options availible. So if you’re an inexperienced wine drinker, you walk into the shop, take a look at the different shelves and map your purchasing decisions on to the range of prices available, some perceived notion of quality (often the design of the bottle) and the occasion you’re purchasing for (do I want a cheap wine to take to a party, a mid priced wine a a gift for a friend or an expensive one for a special occasion)." 1.1. Kierowanie sie kryterium ceny podsumowuje: "Clients have the money, but they don’t have the expertise." 2. Ostatnio znajoma opowiadała mi - z perspektywy klienta - o rynku użyteczności (tak go umownie nazwijmy) w PL. Opowiadała o tym, jak potrzebowała wsparcia ludzi znających się na usability - wsparcia zarówno dorywczego, jak i pracowników na etat. Wydała ileś-tam-$ na ekspertyzy, które otrzymała i... w których nie znalazła żadnych rekomendacji, tylko spis opisujący subiektywne wrażenia z oglądu danego systemu. Ciekawe w kontekście wpisu Andy'ego jest to, że podsumowała tą opowieść stwierdzeniem: "Nie ukrywam, że kierowałam się przy wyborze ceną. Jednak chociaż wydałam znacznie mniej, niż by to miało miejsce gdybym zatrudniła sprawdzone osoby, w sumie nic za to nie otrzymałam." 3. Od czasu do czasu otrzymuję zapytania w związku z przeprowadzeniem szkolenia/warsztatu dla klienta, który to warsztat/szkolenie miałby na celu dostarczenie kompetencji w zakresie opiniowania przesłanych przez dostawców (czy to zewnętrznych, czy też wewnętrznych) projektów. Oznacza to jedno: klient zdaje sobie sprawę (duży plus!), że brak mu wewnętrznie wiedzy. 4. Pisałem też ostatnio o rekrutacji w UX. W pierwotnej - nieopublikowanej - wersji tego wpisu poruszyłem również kwestię roli i zakresu obowiązków, jakie zatrudnione na stanowisku projektanta osoby powinny mieć. W skrócie chodziło mi o to, że czasem spotykam się z sytuacjami, w których w firmach powstają takie osobne wyspecjalizowane działy (niekiedy złożone z pracowników z innych działów), gdzie w sumie nie wiadomo czego teraz od działu projektowego powinno się wymagać i czym powinni się zajmować poszczególne osoby w dziale. Może dla niektórych to brzmi dość abstrakcyjnie, ale zapewniam, że w cale nie jest to rzadką praktyką. 4.1. Czasem punkt 4 związany jest z punktem 3.
Podsumowanie Historie z punktów 1-4 łączą się ze sobą w dość istotny sposób. Na każdym szczeblu te historie związane są z brakiem wiedzy bądź przepływu wiedzy: czy to w przypadku wyboru dostawcy (historie nr 1-2), opiniowania jakości wykonanych prac (historia nr 3), w końcu kompetencji wewnętrznych firmy (historia nr 4). Jakiś czas temu - rok-dwa lata temu - myślałem o założeniu szkoły, której celem byłoby dostarczać m.in. takich kompetencji. Rozmawiałem nawet z kilkoma znajomymi na ten temat i okazało się, że jest zapotrzebowanie; znalazłem też kilku zawodowców, którzy wyrazili chęć wzięcia udziału w tej inicjatywie w roli prowadzących zajęcia (często to ludzie z ugruntowaną wiedzą oraz wielo-(kilkunasto)-letnim doświadczeniem. Wtedy nic z tego nie wyszło, z różnych powodów nie ciągnąłem tematu dalej. Teraz znów zaczynam się zastanawiać... Jeśli - Czytelniku - uważasz, że to byłoby coś, co by Ciebie zainteresowało, daj znać - w komentarzu, pisząc do mnie na e-mail. Może pora powrócić do tego pomysłu i przekuć go w realizację. środa, 25 stycznia 2012, marekkasperski
TrackBack
Komentarze
2012/01/25 15:02:57
@Życzliwy: Bardzo fajny komentarz. Z niego również wypływa element edukacyjny, jak chociażby nauka pisania briefów, czy "jak wyznaczyć cel"?, "cele długoterminowe vs cele krótkoterminowe"?
Poprawki, to zawsze wpisane jest w życie produktu. Masz rację, oby było ich jak najmniej.
Gość: Życzliwy, apn-77-114-7-179.dynamic.gprs.plus.pl
2012/01/25 19:13:30
Wydaje mi sie, ze tego typu informacje, przyklady lub nawet scenariusze 'po co mi strona' powinny byc stalym i podstawowym elementem informacji o ofercie projektanta. Pewnie dlatego tak przydatne sa profesjonalne blogi, bo na nich mozna to wyczytac. To jest chyba tansze niz szkolenia (znowu nie dotyczy lansu ;-)
2012/01/25 19:32:18
@Życzliwy: Hm, zastawiam się czy w pełni czytelnie napisałem swój wpis, bo mi nie chodziło o szkolenie, a o szkołę, z pełnym programem. To jednak różnica. To nie byłoby szkolenie wykonywane przez jedną firmę, która się lansuje i pod kątem sprzedaży. Nie! Celem byłoby przekazanie wiedzy przez ludzi, którzy siedzą w tym - przedstawicieli, pracowników kilku firm/instytucji. Z pełnym programem.
Gość: życzliwy, 89-68-151-108.dynamic.chello.pl
2012/01/25 20:25:38
@Marek Wychodzi na to, że to ja mam problemy z czytelnością ;-) Rozumiem Twój pomysł, ale w pierwszej chwili wydawało mi się, że materiału nie ma aż tyle, stąd z Twojej "szkoły" u mnie zrobiło się "szkolenie".
Jeżeli: 1. nie było by nauki jak "zrobić usability", ale 2. była by jak ustalić co się chce i jak to przepisać na wymagania/brief, 3. jak policzyć czy to będzie miało sens (BC,P&L,CHGW), 4. i do tego jak dobrze kupić usługę projektanta oraz 5. jak przeprowadzić/monitorować taki projekt 6. do tego bez latania "po łebkach" i pokazywania adresu kontaktowego do sprzedawcy, to mogło by to wypalić. Jak Ci się uda to zorganizować, to daj znaka - zapiszę na pierwszą edycję ;-) 2012/01/25 20:34:50
@Życzliwy: Tak właśnie o tym myślę, przy czym myślę o szerszym kontekście, czyli szkole, która dawałaby kompetencje w zakresie projektowym. Nie tylko by klienci mieli kompetencje w zakresie napisania briefu, czy wyznaczenia celów - o czym napisałeś - ale i w ocenie tego, co otrzymali. Także by projektanci wiedzieli na czym polega ich praca. By nie tworzyli bez sensu makiet składających się prostokątów, bo to nic nie daje, tylko rozwiązywali problemy - nauczyli się je dostrzegać, definiować w terminologii internetowej czy interfejsowej i rozwiązywać. Poprawiać błędy po sobie też :)
Gość: Laik z Głogowa, 85-222-47-1.home.aster.pl
2012/01/25 22:26:23
Chyba WSPS oferuje studia podyplomowe w podobnym temacie (www.podyplomowe.pl/informacje-ogolne-warszawa/rekrutacja-na-studia-podyplomowe-swps-w-warszawie)
Generalnie uważam, że to może byc pomysł na medal :)
Gość: wkotecki, 94-75-107-197.home.aster.pl
2012/01/27 09:18:49
Zgadzam się z Markiem co do konieczności edukacji - szczególnie tej wykraczającej poza to kal to ujął autor, co ludzie szumnie nazywają architekturą infomracji a co często w praktyce PL sprowadza się do rysowania makiet w AXURE bez głębszej analizy i faktycznego wnioskowania istoty problemu który się kryje pod spodem. I tu też kłania się częto definicja z briefu który mówi : chcemy serwis x,y,z - lub funkcjonolaność x,y,z - nie skupiając się na celach. A gdy proponuje się im wstępne strategiczne/ideacyjne fazy projektu okazuje się, że nie ma na czasu (pieniędzy) i często kończy się na zatrudnienia rysownika (kreślarza) a nie architekta (projektanta)....
Gość: dr watson, d215-239.icpnet.pl
2012/02/01 19:48:57
Subiektywnie o teoretycznej szkole projektowania interfejsów ;)
1. Przede wszystkim powinna wiedzieć kim będą uczniowie [łatwiej pisać uczniowie i szkoła z oczywistych powodów ;)] i skąd pochodzą oraz jakiej wiedzy oczekują. 2. Program szkoły powinien być podzielony na dwie klasy uczniów: początkujących [wszelkiej maści absolwenci mnogich enigmatycznych kierunków "grafika komputerowa", czy osoby które postanowiły z różnych powodów zając się projektowaniem interfejsów: zmiana zawodu, zmiana działu w korporacji etc, także reprezentanci lub sami klienci ale mam wrażenie że będzie to margines] oraz zaawansowanych [celowo nie piszę "profesjonalistów" bo w Polsce projektowanie interfejsów to jeszcze raczej zbiór indywidualności niż profesja jako taka] 2a. Początkujący uczniowie są zaciekawieni Interfejsami dlatego że to ciekawe, w jakiś sposób niszowe, "bo tak" [w dobie pokolenia studiujących "dla papiera" to wcale nie rzadki powód dowolnej aktywności umysłowej więc dobrze o nim wspomnieć]. Początkujący uczniowie mają na ogół dobrze opanowany techniczny warsztat: posługują się biegle oprogramowaniem do budowania modeli, grafiki, etc. Czyli znają narzędzia ale mają problem z objęciem całościowym jeśli chodzi o problem, wiedzą gdzie szukać reference'ów ale mają problemy z ich stosowaniem, wyborem dobrego patternu, brak doświadczenia i praktyki. 2b. Uczniowie zaawansowani to ludzie którzy trafili do projektowania interfejsu w najróżniejszych okolicznościach. Ktoś był grafikiem, ktoś programistą, ktoś był w dziale biznesu, komuś tak się ułożyły zlecenia na frilansie. Niektórzy używają pełnego pakietu do projektowania, niektórzy nie słyszeli o Axure czy Visio, wolą gomockinbirda czy podobny jsowy klamot do robienia mockupów. Niektórzy lecą na kartce ze wszystkim i potem pieką całość w fotoszopie, no co człowiek to inna metodyka pracy [oparta na doświadczeniu rzecz jasna]. Jako grupa mają jednak świadomość że projekt interfejsu jest częścią pewnej całości na którą ma wpływ również marketing [brrr], biznes [brr], grafika, development. Jeszcze [bo to się zmienia] zdarza się że interfejs nie jest równorzędnym partnerem dla grafiki, developmentu i chciejstwa naczelnego POwnera.
Gość: dr watson, d215-239.icpnet.pl
2012/02/01 19:54:29
i ciąg dalszy tzn wnioski:
3. Krótko reasumując program powinien grupie początkującej dostarczać wiedzy ogólnej, skupiając się bardziej na wskazaniu dobrych praktyk projektowych, pracy i rozumienia inputu, podstawowy opis narzędzi do budowania modeli. Byłoby też dobrze pokazać nie tylko jak się projektuje interfejs ale kto ma jaki wpływ na jego powstanie także poza działem/stanowiskiem projektowym, po to żeby potencjalny projektant zdawał sobie sprawę jakiej skali rzecz projektuje, żeby umiał odnaleźć się na meetingach, uzgodnieniach, konsultacjach etc - to trochę takie review procesu produkcji webowej że tak to naukowo określę. Także w odniesieniu do urządzeń mobilnych bo można mówić że mniej lub więcej one znaczą ale z pewnością dzisiejszy model działania interfejsu musi być kompatybilny z urządzeniami mobilnymi - tym bardziej, że to dość dobry test umiejętności dla projektanta interfejsów ;) 4. Krótko reasumując program powinien grupie zaawansowanej dostarczać rozmaitych przykładów budowy interfejsów, różnych metodyk podchodzenia do problemu na maksymalnie dużej ilości przykładów w różnej skali i na różnych urządzeniach. Mam wrażenie, że lepiej mówić o przestrzeni projektowej niż uczyć jak coś zaprojektować. Bardziej iść w jakąś abstrakcję projektowania niż pokazywać do znudzenia motywy w rodzaju: multipleselect tabela gmaila to najlepsza tabela jaką do tej pory zaprojektowano i tak dalej. Nie znam się na języku naukowym i na naukowej metodyce ale szedłbym raczej w wykształcenie wrażliwości na zmiany, adaptację projektu do tych zmian niż pokazywanie narzędzi, odkrywanie nowych możliwości fotoszopa [ktoś kto klika w nim 10 lat potrafi 99% problemów techniczno-warsztatowych rozwiązać na swoje sposoby bez poznawania nowych opcji, grzeje w klawiaturę jak Blechacz w fortepian i nie musi/chce uczyć się jakiegoś mockapnika skoro "zrobił go sobie" z kartki papieru lub powerpointa]. Ponadto warto oczywiście pokazać przykłady monetyzacji dobrego pomysłu za pomocą dobrego interfejsu. Branża lubi zarabiać, zarabiać też lubią ludzie ale świat potrzebuje kształcenia wyobraźni a nie nowych maszyn. Wydaje mi się to przydatne dla projektantów z różnej maści startupów które mają jakiś pieniądz na start i 4 programistów, 2 menedżerów, grafika na kontrakt no i gościa od interfejsów bo "wypada żeby był i nas stać". Niewątpliwym plusem takiej szkoły/kursu byłaby większa aktywizacja środowiska i powstanie jakiejś samoświadomiści pt "jesteśmy potrzebni do czegoś więcej niż upraszczanie mockupów i rysowanie ikonek". 2012/02/02 16:40:13
Ad. 1-2a
Trochę widzę to inaczej szczerze powiedziawszy praktyka codzienna pokazuje mi, że często osoby nowe w temacie uzyskują dużo lepsze rezultaty niż. tzw. osoby z branży. Nad tymi drugimi też trzeba pracować, zwykle po to, by wykorzenić im złe nawyki z różnych firm. Nie widzę takiego podziału jaki rysujesz. Ale wiem co chcesz pokazać i jest w zasadzie jest to o tyle cenne, że do przemyślenia na poziomie zbudowania ew. rozkładu zajęć. Ad. 2b. Tu też myślimy inaczej w tym sensie, że u podstaw szkoły leżałoby co innego. Z zamierzenia to nie miałaby być szkoła ucząca obsługi narzędzi, a szkoła pokazująca jak rozwiązywać dane problemy, na co zwracać uwagę przy odbiorze/tworzeniu layoutu, etc. Teraz dla przykładu przerabiałem taki temat z jednym grafikiem (właściwie graficzką), która jest świetna w sensie estetyki, ale nikt jej nie pokazał, że np. silnymi akcentami graficznymi zabija treść strony. Musiałem z nią długo rozmawiać i pokazywać przykłady stron, gdzie grafika jest niejako z tyłu i służy po to, by zaakcentować informacje i je odpowiednio zharmonizować na stronie, wcale nie po to, by użytkownicy widzieli jej wypracowane belki. Do uczenia tego rodzaju wiedzy dość uniwersalnej, nie są potrzebne prace na konkretnych programach. Ad. 3. To prawda. Ale też trzeba pokazać chociażby na przykładzie PC że historia lubi się powtarzać. I jak dzisiaj jedną z wytycznych w projektowaniu serwisów/interfejsów mobilnych jest oszczędność i lekkość layoutu, w kategoriach wagi plików graficznych, tak zapewne za jakiś czas to nie będzie ważne, bo inaczej będzie skonstruowana oferta firm telekomunikacyjnych. Niektóre wytyczne siłą rzeczy się dezaktualizują i moim zamiarem nie byłoby nauczanie ludzi jak jest teraz, ale by w przyszłości na podstawie tego jaki jest stan rozwoju rynku, mogli podejmować najlepsze decyzje samodzielnie i mądrze. Druga sprawa aczkolwiek nie druga w kolejności, bo mająca to samo znaczenie to uczenie projektowania zależnego od przyjętego modelu zarabiania. Wiedza nt. mechanizmów dających odsłony serwisowi, gdy rozlicza się za reklamy i budowania zaangażowania czy sprzedaży, przekuwa się na inną budową serwisów. To też są pewne uniwersalne sprawy. Ad. 4. Podoba mi się to stwierdzenie mówić o przestrzeni projektowej. Właśnie tak to rozumiem. Sprawy praktyczne też by miały znaczenie, ale jak o tym myślę, to podoba mi się podejście z ASP, gdzie jest zadawany temat np. martwa natura a ludzie malują. Potem na ten temat się rozmawia tak, by nie rozmawiać w oderwaniu od faktycznych prac studentów. Naniesione zostają korekty i sprawy posuwają się do przodu. |
M. Kasperski, A. Boguska-Torbicz Projektowanie stron WWW. Użyteczność w praktyce, Helion 2008.
M. Kasperski, Sztuczna Inteligencja, Helion 2003.
D. Casacuberta, Umysł. Czym jest i jak działa, Świat Książki 2007.
T. Stafford, M. Webb, 100 sposobów na zgłębienie tajemnic umysłu, Onepress 2006.
J. Hawkins, S. Blakeslee, Istota inteligencji, Onepress 2005.
Co do samego wyboru projektanta, to zgadzając się na uproszczenia zgodzę się z tezą Andy'ego. Czyli można przyjąć, że przekroczenia budżetu, bardzo często są konsekwencją słabej oceny zawartości zakupionej butelki ;-) W końcu wino albo smakuje, albo nie. A czemu tak?
Zbyt ogólny brief? Na pewno. Oglądanie głównie metki z ceną? No tak. Ale ja chyba jestem zwolennikiem tezy, że wino-wającą jest często sprzedający to wino - zwykle (ja się z takimi spotkałem wiele razy...) mający prócz niewątpliwej ogromnej ilości wiedzy i doświadczenia, także poczucie swojej wyjątkowości i debilizmu klienta. Skoro klient się nie zna, to można dać mu cokolwiek, zupełnie nie wnikając. Projekt zrobiony, faktura wystawiona. (Nie)stety, z tej radości, w wycenie pomija się koszt ubezpieczenia od niesmacznego wina, czyli ryzyka związanego z poprawkami. ;-)
IMO-Ergo(wybaczcie słowotwórstwo ;-) konieczne jest zadanie sobie trudu doprecyzowania briefu. Szczególnie określenie CELu, a na tej podstawie zakresu prac. IMO-Ergo2 - Ignorancja? tak, ale to problem po obu stronach barykady.
Nie jestem przekonany, czy robienie szkoleń z oceny projektów internetowych ma sens (no poza chłytem martetingody, znaczy lansowaniem swojej firmy). Jestem raczej zwolennikiem profesjonalnego podejścia obu stron do projektu - z jednej strony klient ma zasrany obowiązek chociaż próbować wiedzieć po co mu to, co chce kupić, z drugiej projektant wyciągnięcia tej informacji.