Jak programiści mogą poprawić swoje umiejętności obsługi interfejsu użytkownika? [Zamknięte]

Jako programiści możemy rozwiązywać bardzo złożone problemy, ale kiedy musimy zaprojektować interfejs użytkownika, zwykle nie udaje nam się ułatwić ich obsługi.

W małych firmach nie stać ich na projektantów i ekspertów UX, programiści muszą robić prawie wszystko w oprogramowaniu. Ale interfejsy te rzadko są intuicyjne ( klasyczny przykład ).

Jaki jest problem? W jaki sposób programiści mogą doskonalić swoje umiejętności projektowania dobrych doświadczeń użytkowników?

Spotkałem ten problem wiele razy w mojej karierze - sztuczka polega na tym, aby najpierw zdawać sobie sprawę, że jest to problem, i uznać go. Gdy to zrobisz, łatwiej przestać tworzyć zbyt skomplikowane interfejsy.

Interfejs użytkownika jest również częścią inżynierii oprogramowania, ale być może dla wielu inżynierów oprogramowania nie jest tak interesujący. Jednak wiąże się z tym wiele interesujących wyzwań i z mojego doświadczenia mogą być równie interesujące, jak wyzwania techniczne.

Użyteczność, projektowanie interfejsu użytkownika (UX), interakcja człowiek-komputer (HCI) - to nie jest magiczne i jest częścią procesu tworzenia oprogramowania.

Moja wskazówka to:

• potwierdź swoje ograniczenia
• pytaj i słuchaj ludzi, którzy twierdzą, że wiedzą o tych rzeczach
• jeśli nie jesteś pewien, przejrzyj go w Google i poszukaj autorytatywnych odpowiedzi

Postępując zgodnie z tymi prostymi zasadami przez lata, zgromadziłem przydatne informacje o tym, jak budować interfejsy użytkownika, jak ludzie wchodzą w interakcje z oprogramowaniem i jak myślą, kiedy go używają. W żadnym wypadku nie jestem ekspertem, ale prawdopodobnie wiem trochę więcej niż przeciętny programista.

Tl; dr: KISS

Jest biologiczny.

• Interfejs użytkownika i wszystkie inne zadania związane z projektowaniem dotyczą właściwego mózgu .
• Zadanie programowania dotyczy lewego mózgu .

Mają różne cele.

Bardzo rzadko być dobrym w obu przypadkach. Przynajmniej w tym samym czasie.

AKTUALIZACJA: Niedawno dowiedziałem się, że istnieją inne czynniki, takie jak doświadczenie. Oprócz niektórych odziedziczonych czynników, rozwijasz zdolności umysłowe w zależności od tego, jak jesteś wyzwalany w dzieciństwie. Na przykład maltretowane dzieci są średnio bardziej kreatywne niż grupa kontrolna, ponieważ w snach uczą się odłączać od swojej okropnej rzeczywistości.

Przypuszczam, że możesz spierać się o to, jak programiści i projektanci mają różne nastawienia lub różne osobowości, lub spierać się o lewy mózg kontra prawy mózg i kreatywność kontra logika, ale tak naprawdę istnieją trzy podstawowe kwestie:

1. Praca programistów to ich oprogramowanie. Dbają o to; poświęcają na to uwagę; mogą się tym ekscytować. Praca użytkowników to coś innego ; oprogramowanie jest tylko narzędziem, które ułatwi robienie czegoś innego, i chcą spędzić tak mało czasu jak to możliwe, zwracając uwagę na to, aby mogły one zamiast koncentrować się o tym, co zrobić zależy. Dopóki programiści nie zrozumieją tego, będą podejmować niewłaściwe kompromisy w projektowaniu interfejsu użytkownika. (Aby uzyskać więcej informacji na ten temat, zobacz „Kontrolowanie środowiska czyni cię szczęśliwym” Joela Spolsky'ego lub „Podstawowe prawa” Davida S. Platta .)
2. Programiści dokładnie znają swoje oprogramowanie. Są wygodne z jego szczegółami i złożonością; rozumieją, dlaczego tak się dzieje, ponieważ mają kompletny model mentalny. Użytkownicy nie mają okazji (ani zainteresowania; patrz punkt 1), aby poznać każdy szczegół, i nie mogą mieć pełnego modelu mentalnego, ponieważ nie mają dostępu ani nie rozumieją kodu źródłowego. (Aby dowiedzieć się więcej na temat znaczenia modeli mentalnych, być może mógłbyś przeczytać The Design of Everyday Things Donanda Normana ; chociaż nie jest specyficzny dla komputerów, jest to dobra książka na temat projektowania interfejsu).
3. Kompromisy programistów różnią się od użytkowników. Programiści mogą łatwo zdecydować się na pozostawienie funkcji zbyt złożonej lub tylko częściowo zautomatyzowanej lub w inny sposób mniej użytecznej, ponieważ dla programisty łatwiej jest poradzić sobie z brakiem użyteczności niż poprawnie ją zakodować. Użytkownik nie dba (dużo) o to, ile wysiłku wymaga programista, aby go poprawnie zakodować i wolałby, aby był w pełni użyteczny.

Trzeci problem można rozwiązać, utrzymując wystarczającą dyscyplinę, aby nie uciec się łatwo. Nie jestem pewien, czy pierwsze dwa problemy można rozwiązać; im bliżej jesteś do pracy, tym trudniej jest dostrzec ją tak, jak robi to osoba z zewnątrz. Dlatego testowanie użyteczności - nawet proste, nieformalne rzeczy, takie jak złapanie kogoś na korytarzu i posadzenie go przed aplikacją - jest tak ważne.