Makiety: kodowanie kontra rysunek?

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

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.

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.

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 )

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

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

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.

To, co działa dla mnie, to tworzenie makiet za pomocą programu, który podkreśla, że nie należy tworzyć układów w pikselach. Dla mnie to makiety Balsamiq, które można sprawdzić na stronie http://www.balsamiq.com/products/mockups