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

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.

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 ...

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).

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.

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.

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.

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ę.

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.

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.