Makiety: kodowanie kontra rysunek?

9

Nie chodzi o projektowanie stron internetowych, ale ogólnie o projektowanie interfejsów. Czy lepiej kodować makiety interfejsu lub „rysować” je w programie graficznym, takim jak GIMP, Photoshop itp.?

website-design interface-design design-process Krzysztof
źródło
3
Zawsze pojawia się komunikat „naszkicuj swój interfejs, jeśli zrobisz to w Photoshopie lub cokolwiek innego, kto pomyśli, że jesteś dalej niż w rzeczywistości. Zostaw makiety wyglądające szkicowo, po prostu zapoznaj się z podstawami, aby Twój klient wiedział, czego się spodziewać, a następnie rozwinąć w interfejsie użytkownika później ”.
Hanna,
1
To całkowicie zależy od projektu. Nie ma uniwersalnej „najlepszej” odpowiedzi.
DA01

Odpowiedzi:

14

Zadaj sobie następujące pytania:

  • Ile układów / opcji interfejsu użytkownika można odkryć w ciągu 30 minut, kodując? Ile można odkryć, szkicując?

  • Jak często otrzymujesz projekt interfejsu użytkownika dokładnie przy pierwszej próbie? Jeśli nie bardzo często, jak szybko / łatwo można zmienić szkic w porównaniu do zakodowanej makiety?

  • Czy potrafisz natychmiast zidentyfikować kolor, po prostu patrząc na jego kod szesnastkowy / rgb (nie tylko zgadnij, ale dokładny odcień / kolor)? Kiedy wyobrażasz sobie kolor w swoim umyśle, czy możesz od razu przełożyć go na hex? Jak szybko można wybrać schemat kolorów, wpisując kody szesnastkowe, a nie używając prawdziwego próbnika kolorów?

Fakt, że zadajesz to pytanie, mówi mi, że najprawdopodobniej jesteś programistą, a nie projektantem. Gdybyś był projektantem, byłoby to absurdalne jak tworzenie aplikacji bez planowania struktury klas, projektowania baz danych, architektury aplikacji itp. I po prostu przeskakiwania do kodowania - a jeśli jesteś doświadczonym programistą, to wiesz jakie problemy powoduje ten rodzaj oddolnego rozwoju.

Podobnie, jeśli przejdziesz od razu do kodu, nie projektując najpierw interfejsu użytkownika, wyniki nie będą ładne, choćby dlatego, że niepraktyczne jest udoskonalenie dobrego projektu poprzez ślepe kodowanie.

Lèse majesté
źródło
OP może myśleć o użyciu edytora kodu WYSIWYG, dzięki któremu możesz wybierać kolory, a nawet „rysować” obiekty ...
jackJoe
2
W rzeczywistości kodowanie bez uprzedniego zaprojektowania interfejsu użytkownika jest dość prawidłową techniką. Oczywiście, jeśli „kodowanie” nie oznacza interfejsu użytkownika ani części interfejsu użytkownika :). Większość interfejsów API i bibliotek zostało zaprojektowanych bez uwzględnienia interfejsu użytkownika - byłoby to po prostu niepraktyczne.
thebodzio
1
@ lese, rzucasz metodę wodospadu. Co może być OK, ale obecnie trendem jest zwinność, w której bardzo prawdopodobne jest, że pracujesz w kodzie od pierwszego dnia.
DA01
@ DA01: Pracujesz nad kodem od pierwszego dnia, ale nadal stosujesz metodologię odgórną. W zwinnym nie ma nic, co mówi, że nie można zaplanować architektury danych ani zdefiniować interfejsu użytkownika przed kodowaniem (co myślę, że większość zwinnych firm woli od UML, diagramów klas itp.).
Lèse majesté
2
@thebodzio: Tak, oczywiście, po to jest rozdzielenie obaw. Ale nie mam na myśli kodowania backendu. Kiedy mówię o kodowaniu w kategoriach projektowania pytania (a nie o analogii programowania, którą stosowałem do zilustrowania tej kwestii - wiem, to trochę mylące), mam na myśli kodowanie makiety (CSS + HTML lub jakikolwiek inny język interfejsu użytkownika) ).
Lèse majesté
5

Najpierw głosowałbym na „rysowanie”. W GUI kluczem jest odpowiedni układ / prezentacja, która wymaga zaprojektowania wizualnych środków. Wizualne projektowanie GUI pozwala szybko zmienić projekt bez konieczności „wyobrażania sobie” każdej zmiany, „przetłumaczenia na kod” i wreszcie przetestowania. Drugi sposób jest również możliwy, ale rzadko jest lepszy (np. Projekt jest bardzo mały, jak tylko kilka przycisków i jesteś znany i przyzwyczajony do pracy na poziomie „kodu”; podczas projektowania mogą pojawić się pewne wzorce, które mogą być po prostu ponownie użyte z niewielkimi modyfikacjami).

Jeśli projektujesz konkretny zestaw narzędzi do widgetów, możesz także użyć aplikacji „GUI designer”, jeśli jest dostępna. Przyspieszy to jeszcze więcej procesu projektowania GUI, ponieważ oba pokazują dokładnie, jak będzie wyglądał zaprojektowany GUI w uruchomionym programie, i mogą eksportować gotowy do użycia opis GUI na poziomie prezentacji.

thebodzio
źródło
2
”i znasz i przyzwyczajasz się do pracy na poziomie„ kodu ”-> Ważne jest, aby zespół interfejsu użytkownika / UX mógł pracować na poziomie kodu. Każdy projektant nie musi być programistą, ale zespół musi być w stanie zbudować wszystko, co zaprojektuje i zrozumieć inżynierię tak samo, jak projekt wizualny.
DA01
Mogę się zgodzić, o ile masz na myśli zespół jako całość. Myślę, że kiedy projektujesz UI / UX, a nie kodujesz, znajomość wewnętrznych mechanizmów kodu może cię powstrzymać, ponieważ będziesz unikać pewnych potencjalnych rozwiązań tylko dlatego, że będziesz uważał je za „zbyt trudne do wprowadzić w życie". Oznacza to, że twoje projekty mogą być pozbawione genialnych pomysłów, ponieważ „myślenie na podstawie zestawu narzędzi” zablokuje część twojej wyobraźni. Z drugiej strony… to tylko jedna strona ostrza :) Poza tym pytanie dotyczyło tylko „makiet”.
thebodzio
1
Często słyszę argument „wstrzymaj się”, ale okazuje się, że pochodzi on wyłącznie od projektantów wizualnych, którzy uparcie sprzeciwiają się nauce kodu warstwy prezentacji. Ci ludzie również dążą do robienia wszystkiego we Flashu. :) Lubię sugerować, że nie różni się niczym od projektu wydruku. Wiedza o tym, jak działa drukowanie, nie „powstrzymuje cię” jako projektanta druku. Przeciwnie, zapobiega tworzeniu plików, które dławią procesor RIP lub powodują, że drukarka krzyczy na ciebie, aby uzyskać 300% pokrycie atramentem. Chodzi tylko o zrozumienie medium i związanych z nim ograniczeń.
DA01
1
WYSIWYG nie służy do ułatwiania „myślenia wzrokowego”. To pozwala ludziom, którzy nie chcą się uczyć, utykają. ;) Jeśli chodzi o ograniczenia, określają one medium. Architekt, który potrafi rysować wspaniałe obrazy, ale nie rozumie podstaw obciążeń i rozpiętości, jest w dużym stopniu powstrzymywany ... ponieważ nic, co narysują, nie może być zbudowane.
DA01,
1
(i wiele moich opinii powstało przy współpracy z zespołami UX lub z nimi, którzy nie mają pojęcia, jak zbudować cokolwiek, co wymyślą. Przez większość czasu nie wprowadzają innowacji ... ale projektują tylko na wpół przemyślane rozwiązania, które nie są praktyczne pod względem implementacji, harmonogramów, użytkowników lub budżetów [wszystkie są dodatkowymi ograniczeniami, które zamiast być „ścianami”, które pomagają zdefiniować rozwiązanie projektowe]) PS: dobra dyskusja!
DA01
3

Do projektowania interfejsu użytkownika mam trzy etapy o różnych celach:

  1. Szkicowanie Po pierwsze, chcesz uzyskać podstawowe wyobrażenie o tym, jakie będą elementy i jak będą do siebie pasować. Każdy drobny szczegół lub estetyczny perfekcjonizm na tym etapie jest rozpraszający. Używam tablicy i długopisu, który można wymazywać, więc nie można rozproszyć się zbyt dużą ilością szczegółów i łatwo napisać mnóstwo różnych pomysłów i zacząć od nowa w dowolnym momencie. Słyszałem o ludziach, którzy szkicują tylko małe karteczki samoprzylepne lub używają tylko swojej ręki (np. Lewej ręki, jeśli jesteś praworęczny), aby zmusić się do nie zwracania uwagi na estetykę i skupienie się w 100% na pomysł i funkcję. (zdjęcie nie moje, autorstwa Franka Prendegasta )

Zdjęcie szkieletu tablicy

  1. (2!) Symulowanie.Po drugie, chcesz spojrzeć w dół i uzyskać informacje zwrotne, dowiedzieć się jak najwięcej o intuicjach ludzi i niepomyślnych odpowiedziach, zanim zaczniesz czasochłonne prace wdrożeniowe. Powinno to dotyczyć tego, w czym pracujesz najbardziej efektywnie, ponieważ jeśli robisz to dobrze, powinieneś często „wracać do tablicy kreślarskiej”, szukając krytyki i starając się jak najwcześniej zidentyfikować jak najwięcej nieoczekiwanych problemów. Jeśli jesteś szaloną maszyną do kodowania i pracujesz w niej najwygodniej, kodowanie jest w porządku, ale większość ludzi będzie pracować szybciej w czymś takim jak Fireworks, Photoshop, dedykowane oprogramowanie do wireframingów, a może narzędzie do tworzenia interfejsów oparte na interfejsie użytkownika, takie jak Flash Catalyst (w porządku, jeśli produktem końcowym nie jest Flash, celem jest uzyskanie dobrych opinii przed rozpoczęciem implementacji).

  2. (3!) Wdrażanie. Wreszcie, wdrażasz rzecz i dążysz do tego w sposób, który pozwala na częstsze i częstsze uzyskiwanie informacji zwrotnych.

Te trzy części cyklu projektu mają różne cele, więc jeśli jest to duży projekt, warto zastosować najbardziej odpowiednie narzędzie do pracy na każdym etapie.

user56reinstatemonica8
źródło
2

To pytanie jest nieco niejasne i jako takie, podobnie jak odpowiedzi.

Ponadto projekty będą się bardzo różnić, podobnie jak zespoły.

To powiedziawszy, nie ma „najlepszego”. Chodzi o używanie wszystkich narzędzi w przepływie pracy, który jest najbardziej sensowny dla Ciebie i Twojego zespołu.

Ogólnie rzecz biorąc, powiedziałbym, że jest to typ przepływu pracy, do którego należy dążyć:

  1. Naszkicować. Ołówek + papier. Tablice. Powtarzać. Pracuj z jak największą liczbą członków zespołu.
  2. makiety niskiej rozdzielczości. Może to być PSD, może być Visio. Może być papier. Użytkownik je przetestuje.
  3. Przejdź do budowania prototypów. W tym miejscu chcesz zacząć robić jak najwięcej w działającym kodzie. Wskakuj do Photoshopa, jak potrzebujesz, i wstawiaj go do kodu tak szybko, jak to możliwe. Kontynuuj testowanie / iterowanie użytkowników.
DA01
źródło