Czy grafik powinien stworzyć grafiki? Tak. Projektować UX? Niekoniecznie. Wydaje mi się, że cały czas się trochę rozmijamy w definicjach. Nikt nie mówi, że programista powinien przygotowywać grafiki. Ale tak samo nie każdy grafik powinien przygotowywać wireframe’y (dla uściślenia: http://en.wikipedia.org/wiki/Website_wireframe). Wbrew pozorom nie każdy grafik zna się na UX. Dodatkowo przy projektowaniu UX potrzeba często bardzo dużo pracy zanim usiądziemy do jakiegokolwiek narzędzia. Trzeba poznać daną dziedzinę, potrzeby użytkowników, zastanowić się co powinno być wyeksponowane bardziej, a co mniej itp. itd.
Wbrew jakim pozorom? 
Grafik ma taką samą szansę znać się na UX jak programista.
W ogóle, skąd tu się wzięły dyskusje o grafikach w tym temacie? Przecież to nie ma nic wspólnego z projektowaniem…
Stąd mój apel: nie mylcie UX/UI DESIGN z VISUAL DESIGN. To na tyle różne rzeczy co kod w Ruby i kod pocztowy.
Zresztą w niektórych projektach dzięki twitter bootstrapowi grafik przestaje być potrzebny. Co o tym sądzicie?
ta, jasne. Nikt poważny się w takie coś nie bawi – to zwykłe bagno.
[quote]Wbrew jakim pozorom? Grafik ma taką samą szansę znać się na UX jak programista.
W ogóle, skąd tu się wzięły dyskusje o grafikach w tym temacie? Przecież to nie ma nic wspólnego z projektowaniem…
Stąd mój apel: nie mylcie UX/UI DESIGN z VISUAL DESIGN. To na tyle różne rzeczy co kod w Ruby i kod pocztowy.[/quote]
+miljon!!11oneoneone
jasne - przy stronie domowej(programisty), stronie jakiegoś gema, lub na wczesnym etapie tworzenia aplikacji (gdy jeszcze nie masz dostarczonych gotowych ekranów).
Ogólnie twitter bootstrap to dla mnie taki „this page is under construction” XXI wieku.
Właśnie dlatego w Polsce “sekretarka” jeździ autobusem a w stanach nowym “Mercedesem”. Nie nazywaj ludzkiej pracy bagnem bo chyba jesteś mało zorientowany w temacie poważny kolego.
To że kogoś stać na rok darmowej pracy przy projekcie bez żadnych zarobków za udziały w zyskach nazwał bym odwagą a nie bagnem.
a czy ja gdziekolwiek nazwałem ludzką pracę bagnem? Bagnem nazwałem układ, gdzie w celu ograniczenia kosztów, wykonujesz usługi w celu zgarnięcia części późniejszych (hehe) zysków – tak działają gimnazjaliści.
A ja głupotą. Tzn inaczej – jeśli kogoś stać na to, to nazwałbym to komfortem finansowym. Ale pracowanie przez rok z kimś, tylko dlatego, że nie było go stać na moje usługi, w celu późniejszych ewentualnych zysków to głupota. Chyba nie będę wyjątkiem na forum, jeśli powiem, że miałem kilka/kilkanaście propozycji tego typu. Nie słyszałem, żeby którakolwiek wypaliła, a którykolwiek pomysłodawca jeździł mercedesem.
Tak myśli 95 % polaków i dlatego w Polsce przysłowiowa sekretarka śmiga autobusem a w stanach i nie tylko stać ją na to żeby kupić sobie nowy samochód z segmentu premium ale i na dom wakacje itp… nie dlatego że jest sekretarką tylko dla tego że zgodziła się pracować za udziały w rozwijającej się firmie. Ale nie ma o czym mówić bo pracowanie za % to absurd i głupota więc nie ma “mercedesów” ;).
[quote]Ale pracowanie przez rok z kimś, tylko dlatego, że nie było go stać na moje usługi, w celu późniejszych ewentualnych zysków to głupota.[/quote]
Jeżeli ty dajesz 100% siebie twój wspólnik 0% to głupota ale jeżeli układ jest zdrowy każdy daje jakąś część swojej wiedzy i zaangażowania to jest ok.
Skoro uważasz zysk za głupotę hahaha to ok.
P.s chyba trochę zeszliśmy z tematu może założymy nowy wątek “Praca za % udziału w projekcie” niech się ludzie wypowiedzą
Ten wątek chyba staje się coraz głupszy.
Chyba tak. Zamykamy !
Na szczęście w naszej branży już coraz mniej.
Osobiście uważam, że fajnie jest jak programista zna podstawy UI / UX, szczególnie jeśli chodzi o aplikacje internetowe. Na przykład podstawa podstaw - “Don’t make me think”, jest niedługa, fajnie napisana, zmienia patrzenie na pewne rzeczy - na pewno żadnemu programiście RoR to nie zaszkodzi ;).
Co nie zmienia faktu, że idealnie jest, gdy w projekcie jest ktoś od UX.
Hmm… ja do startupu nawet dopłacałem, i to sporo, tzn. że jestem debilem? 
Pewnie stąd:
Oszczędza kupe roboty, zwłaszcza jeśli np robi się tylko część administaratora/cmsową itp, gdzie to jak wygląda nie ma aż takiego znaczenia dla klienta, liczy sie jak działa.
@sarniak:
w cytowanym zdaniu pisałem ni mniej, ni więcej, że niedpłatna praca(a w zasadzie wolontariat) u kogoś przez rok, bo go nie stać na wyłożenie jakiejkolwiek kasy, z mglistą obietnicą (najczęściej) średnio skonkretyzowanych zysków(bo gdy ktoś jest naprawdę łebski, ma świetny pomysł, a brakuje mu tylko kasy, to idzie do VC/banku/konkursu startupów/pożycza od cioci z ameryki, która wozi się mercedesem, mimo, że jest sekretarką) jest poprostu absurdalna.
@drogus: nie znam zbyt wielu kulisów stoliczka, wiem mniej–więcej tyle, ile usłyszałem na wroclove. Ale jak słusznie wspomniałeś, dopłacałeś kasę, a nie szukałeś grafika, który zrobi Ci grafikę dla nieistniejącej jeszcze strony, a w zamian za to będzie miał procent w zyskach – o ile się pojawią. I nie, nie uważam Cię za debila – bynajmniej
Ciekawie się rozwinęła dyskusja Zaczęło się od projektowania aplikacji, przeszło na grafików i UX, skończyło się (jak na razie) na formach zatrudnienia i zasadach udziału w projekcie
Wracając do oryginalnego tematu, tj. projektowania czegokolwiek dla klienta, trzeba zacząć od pytania, o którym już ktoś wspominał: Jaki problem aplikacja ma rozwiązać lub jakie procesy ma wspomagać.
Idealny klient wie, że aplikacja ma pobierać dane z dokładnie wskazanych źródeł, przechodzić przez dobrze opisane procedury i na końcu dać efekt, którym jest zestaw danych zasilających istniejące już rozwiązania, zwykły raport z przebiegu procesu lub inną dobrze opisaną formę.
Idealny menadżer projektu/architekt aplikacji (czy inna decyzyjna osoba) słucha klienta, potrafi doradzić odpowiednie rozwiązanie, ale nie narzucać swoich rozwiązań. Zna ograniczenia technologii i wie jakich rozwiązań, powodujących problemy zarówno klientowi jak i programistom, unikać.
Najczęściej spotykany klient, nie ma pojęcia do czego mu w ogóle aplikacja będzie potrzebna. Najczęściej słyszał gdzieś, że coś takiego można zrobić w jakiś sposób, który z punktu widzenia implementacji i funkcjonalności nie ma większego sensu.
Człowiek, z którym pracowałem, będący kierownikiem działu uzurpował sobie prawo do wszechwiedzy. Klient jest głupi i nie wie czego chce, zrobimy mu tak (bo wygodniej) i będzie zadowolony. Jak nie będzie, to mu powiemy, że inaczej się nie da. Będziemy mu to powtarzać tak długo, aż w to uwierzy i będzie zadowolony. Jak się kończyły wszystkie projekty, nie chce mi się pisać, ale raczej się domyślicie.
Zapotrzebowanie na aplikacje wynika zawsze z czegoś, zwykle potrzeby usprawnienia zachodzących procesów. Podstawą udanego projektu jest zrozumienie przez programistów potrzeb klienta, ograniczenie do minimum interakcji użytkownika z aplikacją (mniej interakcji, mniej miejsca na błędy, mniejsza frustracja użytkowników), ale też zrozumienie przez klienta ograniczeń i wymagań jakie będą występowały przy użytkowaniu aplikacji. Gdzieś między klientem a programistą musi wystąpić mediator rozumiejący procesy klienta, które będą wspierane aplikacją i ograniczenia wybranej technologii.
Ze swojej 10 letniej obserwacji i uczestnictwa w projektach zauważyłem, że często programiści zupełnie nie rozumieją co aplikacja ma robić. Często konfrontacja programisty z użytkownikiem przypominała rozmowę dwóch ślepych o kolorach. Osoba, która odpowiadała za kontakt z klientem często nie rozumiała ograniczeń wynikających z zastosowanych technologii przy jednoczesnym obiecywaniu klientowi wszystkiego o co poprosił.
Efektem tego były aplikacje, które:
- Zupełnie nie przystawały do potrzeb klienta
- Powodowały wydłużenie procesu, zamiast jego usprawnienie
- Wywoływały u użytkownika odruch mało cenzuralny, kiedy prosta operacja np. przekazania wiadomości do innego użytkownika wymagała 15 kliknięć myszką w 5 różnych okienkach i na końcu podania pinu czy innego identyfikatora
- dużo innych emocji na linii użytkownik - administrator, administrator - kierownictwo, kierownictwo - menadżer projektu itd.
Podsumowując, jak wiele znacie firm, które projektowanie aplikacji zaczynają od kilkumiesięcznej pracy u klienta, z przyszłymi użytkownikami aplikacji, analizując każdy krok w procesie związanym z pracą konkretnego użytkownika?
Ile razy spotkaliście się z dokumentacją opisującą procedury związane z procesami wspomaganymi projektowaną aplikacją z dokładnym opisem każdego kroku i sposobu interakcji z użytkownikiem?
Moim zdaniem, rozpoczynanie projektowania czegokolwiek modelu danych, formularzy, przepływów itd. bez porządnego przygotowania papierologii, zapoznania się z problemami jakie aplikacja ma rozwiązać i procesami jakie ma wspomagać, to strata czasu. Prowadzi zwykle do poprawiania poprawionych poprawek i często lepiej zacząć wszystko od początku niż wprowadzać kolejne zmiany. O dokumentacji poprawek do poprawianych poprawek lepiej już nie wspominać
Takie mam doświadczenie z pracy (na szczęście z byłej pracy)