Czy programista powinien wykonywać makiety interfejsu użytkownika, jeśli w projekcie nie ma projektantów?

57

Współpracuję z małym zespołem, który tworzy zastrzeżoną aplikację internetową, a UX nie ma większego znaczenia, ponieważ nasi ludzie będą nią zarządzać, ale staramy się ułatwiać im pracę.

Czy jako programista powinienem utworzyć makietę interfejsu użytkownika, zanim zacznę tworzyć nowy ekran? Nic nadzwyczajnego, głównie ogólny układ, aby omówić go z kolegami i mieć model referencyjny. Porównywałem to do tworzenia niektórych diagramów UML, zanim zacząłem ślepo pisać kod.

Jeden z moich współpracowników mówi, że to niedorzeczne i nie jest to moja praca.

Konstantine
źródło
51
Jeśli nie masz projektantów, a to nie jest praca programistów, to kto powinien to zrobić? Może woźny?
GrandmasterB
10
Z pewnością możesz, może powinieneś, ale nie jest to wcale niezwykłe i zdecydowanie nie „niedorzeczne”, jak to ujął twój zbyt dramatyczny współpracownik. W zależności od sytuacji i środowiska lepiej być może robić celowo makietę, a nie coś, co zbyt przypomina produkt gotowy. Balsamiq jest dobrym narzędziem do tego, podobnie jak rysowanie makiety na papierze lub tablicy.
Joe Ballard,
3
Zakładam, że naprawdę masz na myśli „makieta”? „Kpina” to coś innego .
Robert Harvey,
23
User Experience Design wykracza poza to, że wygląda ładnie. Programiści powinni być w to bardzo zaangażowani.
JeffO
2
niedorzeczna jest reakcja twoich współpracowników. jest to bardzo powszechne
Claudiu Creanga

Odpowiedzi:

74

Bardzo często pracuję w takich projektach, a odpowiedź brzmi: TAK i jak najwcześniej.

Ludziom znacznie łatwiej jest krytykować ulepszenie niektórych projektów, niż wymyślić rozwiązanie od zera. Dlatego zaczynam szkicować wcześnie z dwóch powodów:

  • Spraw, by eksperci od spraw mieli wrażenie, jak można przedstawić te informacje.
  • Pokaż moje obecne zrozumienie problemu i struktur informacyjnych.

W rzadkich przypadkach miło było mieć jakiś dowód, że faktycznie dostarczyłem to, co uzgodniliśmy ...

Stefan Schmiedl
źródło
16
I szczerze mówiąc, o wiele łatwiej jest napisać kod, jeśli masz przed sobą przynajmniej szkic serwetki.
Kathy
9
Punkt 2) jest niezwykle ważny, jeśli biznes nie jest trywialny!
bigstones
4
Ponieważ ktoś, kto pracował w UX przez 3 lata, sam szkic, aby porozmawiać z ludźmi (programistami, klientami, użytkownikami końcowymi) jest niezwykle przydatny i ważny. Zaoszczędzi Ci to dużo czasu, gdy nie musisz całkowicie przerabiać strony, ponieważ ktoś się frustrował!
Gnomejon
39

Makiety są fantastyczne i nie ma powodu, dla którego deweloper nie powinien tego robić. (Może być nawet przydatne dla deweloperów, aby wykonać wstępny szkic układu interfejsu użytkownika, nawet jeśli w projekcie są projektanci interfejsu użytkownika).

Gorąco polecam, aby nie robić makiet, które wyglądają jak rzeczywiste ekrany. Jeśli udostępnisz je użytkownikom końcowym, którzy często skupiają się na rzeczach, które nie mają znaczenia, takich jak kolory i motywy. To, co polecam, to tworzenie szkiców ręcznie na papierze lub tablicy. Lub jeśli chcesz je na komputerze, użyj czegoś takiego jak Pencil Project lub Visio ( oto kilka szablonów Visio od Jonathana Abbetta, które wyglądają na rysowane ręcznie).

Matthew Whited
źródło
6
Możesz nawet ręcznie rysować nakładki, okna dialogowe itp., Wycinać je nożyczkami i umieszczać na wierzchu ręcznie rysowanego ekranu głównego, gdy użytkownik dotknie ręcznie rysowanego przycisku. Bardzo szybko daje wyobrażenie o tym, co uważają za intuicyjne, ile przycisków faktycznie potrzebujesz i tak dalej.
RemcoGerlich,
To tylko szalona rozmowa ... właściwie robi scenorysy. Droga do starej szkoły dla tych nowych facetów: P
Matthew Whited
1
„nie rób makiet, które wyglądają jak rzeczywiste ekrany” to bardzo głęboki wgląd.
Andrew Myers,
1
Pamiętam anegdotę, że użytkownicy oceniliby zakończenie projektu na podstawie tego, jak dopracowane były zrzuty ekranu. W przypadku użytkowników nietechnicznych, którzy nie dokonują rozróżnienia między prezentacją a funkcjonalnością, utrzymanie szkicu jest bardzo ważne, aby przekazać „nie zrobiono tego”.
Matthieu M.,
1
@Andrew ... to jedna z rzeczy, których nauczyłem się, gdy szydziłem z aplikacji w Access i VB. Pokazujesz komuś coś, co wygląda jak zrzut ekranu, a oni oczekują, że możesz go wysłać :)
Matthew Whited
11

Tak, absolutnie.

Nie pozwól, aby ktoś inny powiedział ci, jak wykonać swoją pracę. I masz rację, to bardzo przypomina tworzenie UML dla twojego modelu danych. Zakładając, że jesteś programistą, Twoim zadaniem jest dostarczanie wysokiej jakości oprogramowania. Jeśli makiety pomogą ci to zrobić, to jest to część twojej pracy.

Wykonuj makiety niskiej jakości - nie sprawiaj, że wyglądają jak prawdziwe ekrany. Zmarnujesz zbyt dużo czasu na dostosowywanie czcionek, pikseli i ramek, a twoi użytkownicy będą obsesyjni nad takimi szczegółami, zamiast skupiać się na funkcjonalności. Coś takiego jak balsamiq jest do tego świetne, bez wątpienia inne podobne narzędzia. Dzięki makiecie znacznie łatwiej jest omawiać funkcje projektu z użytkownikami i innymi członkami zespołu programistów.

Bryan Oakley
źródło
Oczywiście, jak mówisz, mówię o makietach o niskiej wierności. Draw.io osobiście używam jako superlekkiego rozwiązania do łatwego udostępniania między kolegami.
Konstantine
10

Projektując „nowy ekran”, musisz najpierw omówić ogólne założenia interfejsu użytkownika z użytkownikiem i / lub współpracownikami. Nie możesz omawiać tego z użytkownikiem „w kodzie” lub „w UML”, który po prostu nie działa (nie będzie nawet działał między programistami). I powinieneś spodziewać się, że musisz wyrzucić pierwsze dwa lub trzy szkice lub przynajmniej mocno zmienić układ elementów interfejsu.

Więc jeśli masz graficzne narzędzie do projektowania interfejsu użytkownika, które pozwala to zrobić szybko, warto go użyć. Jeśli jednak konieczne jest ręczne kodowanie elementów interfejsu użytkownika, a wyrzucenie lub zmiana układu elementów interfejsu wymaga dużego wysiłku, wtedy oczywiście rozsądniej jest nie „kodować” interfejsu użytkownika w pierwszej kolejności. Znacznie bardziej efektywne będzie tworzenie oddzielnych makiet, za pomocą graficznego narzędzia do rysowania lub po prostu za pomocą ołówka i papieru.

Doktor Brown
źródło
5

Niekoniecznie. Są co najmniej dwa powody, dla których makiety mogą być mało przydatne.

Po pierwsze, jeśli istnieją ugruntowane praktyki branżowe dotyczące robienia rzeczy, które zamierzasz robić, możesz po prostu iść do przodu i zrobić dokładnie to. Nie będziesz popychał sztuki projektowania interfejsu użytkownika, ale to również dobrze.

Po drugie, użytkownicy końcowi często nie wiedzą, co jest dla nich dobre i dlaczego. Po prostu nie potrafią powiedzieć, dopóki nie zaczną używać programu (z rzeczywistymi lub próbnymi danymi). Nie pomoże w tym żadna liczba statycznych makiet.

Dzięki skromnie elastycznemu frameworkowi sieciowemu „tylko kolejny ekran interfejsu użytkownika, taki jak poprzednie N ekrany”, możesz zacząć od działającego prototypu i zmieniać jego kolejność. Zrób makietę i przedyskutuj z kolegami za każdym razem, gdy masz zamiar zrobić coś wyjątkowego.

Eugene Ryabtsev
źródło
Półprawda, że ​​użytkownicy końcowi nie wiedzą, co jest najlepsze. Ale nie możesz nawet szczerze powiedzieć, że wiesz, co jest najlepsze, dopóki nie zobaczysz układu i przepływu aplikacji. Największym problemem związanym z używaniem interfejsu użytkownika jako makiety jest oczekiwane ustawienie. Ludzie coś widzą i narzekają na drobne rzeczy, które nie mają znaczenia, lub po prostu zastanawiają się, dlaczego tak długo zajmujesz się czymkolwiek innym.
Matthew Whited,
@MatthewWhited Czy skarżą się na drobne rzeczy, kiedy przychodzą, aby omówić interfejs użytkownika, czy narzekają na nie, gdy proponujesz użyć produktu do wykonania ich pod ręką? Raczej oczekuję, że późniejszy przypadek byłby bardziej konstruktywny, a to dobrze nadaje się do wewnętrznej aplikacji internetowej z zainstalowaną bazą 1.
Eugene Ryabtsev
3

ZAWSZE!

Pracuję dla małej firmy i jestem jedyną „miękką” osobą IT. Robię wszystkie wymagania, projektuję, koduję, testuję (choć ktoś zawsze sprawdza moje testy), projektuję bazę danych itp.

NIGDY NIE CIĘĆ NAROŻNIKÓW NA KROKACH PROJEKTOWYCH - Twoi użytkownicy końcowi będą Ci wdzięczni. Będziesz również wdzięczny sobie, ponieważ Skończysz przerabiać go, aby uszczęśliwić użytkowników końcowych. Nawet jeśli twoja makieta jest niczym więcej niż tylko ręcznie wypisanym kawałkiem papieru, daje wyobrażenie o tym, czego się spodziewać. Poświęcenie 10 minut na zapisanie czegoś może zaoszczędzić tygodniowy czas (byłem tam, zrobiłem to)

Pomaga również w kodowaniu. Daje to szansę zastanowienia się nad tym, co musisz zrobić, najskuteczniejszym sposobem na osiągnięcie tego, a także ewentualnymi przeszkodami.

Na przykład może się okazać, że ten „prosty” raport, który należy utworzyć, jest trudniejszy, niż początkowo sądzono, ponieważ nie przechwytuje się daty w tabeli xyz. Rozszerza również twoje horyzonty i pokazuje twojemu zespołowi, przełożonym, a nawet może być wykorzystany do potencjalnych przyszłych karier, które robisz więcej niż absolutne minimum i może wyjść poza to pole „to nie moja praca” (<--- poważnie, NIE bądź tym facetem, wszyscy go nienawidzimy) lub daje to szansę na dodatkową naukę.

Jon Milliken
źródło
2

Spójrzmy na to w bardziej ogólny sposób:

  • Czy tworzenie szkiców to dobry pomysł?
  • Kto powinien tworzyć projekty?

Czy tworzenie szkiców to dobry pomysł?

Tworzenie szkiców zapewnia głównie 2 korzyści. Po pierwsze, zapewnia skupienie, co prowadzi do przyspieszenia faktycznej pracy. Po drugie, znacznie ułatwia omawianie kierunku pracy przed ukończeniem pracy.

Minusem tworzenia wersji roboczej jest to, że wymaga czasu. Nie ma sensu spędzać 2 godzin na tworzeniu skomplikowanego szkicu dla czegoś, co zajmuje 4 godziny.

W twoim przypadku poziom makiety musi uwzględniać szacunkową ilość pracy, która trafia do projektu, oraz korzyści z projektu. W zależności od nich makieta może znajdować się w dowolnym miejscu między 10-sekundową bazgrołą na post-it a w pełni interaktywną stroną internetową. W przypadku bardzo dużych i kosztownych projektów nierzadko zdarza się, że całe zespoły pracują nad wersją roboczą od tygodni i jednocześnie przygotowują wersje robocze swoich wersji roboczych.

Kto powinien tworzyć projekty?

Tutaj nie ma potrzeby szczegółowej odpowiedzi: jeśli korzystasz z tworzenia wersji roboczej, tworzysz wersję roboczą. Jeśli korzystasz z kogoś, kto przygotowuje dla ciebie projekt, poproś kogoś innego o przygotowanie projektu dla ciebie.

Piotr
źródło
Naprawdę fajna uwaga na temat znaczenia porównania czasów tworzenia. Nie ma sensu podwoić wymaganego czasu tylko dlatego, że robiliśmy projekty.
Konstantine
-2

Twój kolega jest absolutnie poprawny. Aplikacje wewnętrzne mają z góry określony wygląd. Również dla takich aplikacji użytkownicy nie szukają najnowocześniejszego interfejsu użytkownika. Chcą tylko czegoś, co działa i jest dość łatwe w użyciu. Jeśli nie planujesz radykalnej zmiany interfejsu użytkownika (odradzam zdecydowanie ... w przypadku aplikacji wewnętrznych), po prostu postępuj zgodnie z istniejącym wyglądem. Makiety są świetne, ale w twoim przypadku tylko zwiększy twój ból.

Kshitij Upadhyay
źródło
1
Makiety nie są przeznaczone do tworzenia najnowocześniejszych interfejsów użytkownika, lecz do kpowania z układu i zachowania ekranu. W rzeczywistości w większości przypadków nie są tak ładne. Po prostu się nie zgadzam
Kieren Johnstone
3
Uznałem, że makiety są przydatne w konkretnej aplikacji wewnętrznej, którą opracowywałem. Pomysł nie polegał na zaprojektowaniu wyglądu lub wynalezieniu nowego paradygmatu interfejsu użytkownika (jak mówisz, nie było to konieczne), ale drażnienie użytkowników, jakie są wymagania, ponieważ interfejs użytkownika daje coś konkretnego do omówienia.
James_pic
@KierenJohnstone Całkowicie się z tobą zgadzam. Jednak sam mówi, że „UX nie ma większego znaczenia”. O ile nie jest on dość starszym członkiem zespołu, jego nagrody nie będą odpowiadały wysiłkom (tworzenie makiet). Makiety są świetne. Ale nie w jego sytuacji.
Kshitij Upadhyay
Nie zgadzam się - makiety są naprawdę przydatne w tej sytuacji - w większości sytuacji - aby zobaczyć, jak aplikacja będzie działać, jeśli ma to sens i jeśli wymaganie zostanie zrozumiane przez programistę - zanim nastąpi kosztowna część (pisanie kodu)
Kieren Johnstone,
1
Nasz zespół liczy około 3 osób. Jest jeden starszy członek / lider zespołu, ja i inny facet, którzy zostali zakontraktowani do pracy nad projektem. Szkic powstał głównie w celu omówienia nowego ekranu z liderem zespołu. Nie było też żadnego z góry określonego wyglądu, ponieważ celem nowego ekranu było ulepszenie istniejącego, co było uciążliwe w użyciu, więc wszystko musiało zostać zrobione ponownie.
Konstantine