Model szkieletowy

Model szkieletowy to mało wierna reprezentacja interfejsu, która pokazuje strukturę, priorytet treści i funkcjonalność bez angażowania się w projekt wizualny. Zazwyczaj renderowany w skali szarości z tekstem zastępczym i prostymi ramkami, służy do podejmowania decyzji o tym, co ma się pojawić na ekranie, w jakiej kolejności i z jaką względną wagą, zanim ktokolwiek zainwestuje wysiłek w typografię, kolory, grafikę lub szczegóły interakcji.

Celem usunięcia wizualnego dopracowania jest zmiana toku dyskusji. Mając do dyspozycji gotowy projekt, interesariusze omawiają dobór kolorów, fotografii i czcionek, ponieważ to właśnie te cechy dają najwięcej możliwości do wyrażenia opinii. Mając do dyspozycji szkielet, chętniej dyskutują o tym, czy treść jest odpowiednia, czy sekwencja ma sens i czy działanie główne jest właściwe. Celowa niedopracowanie jest cechą charakterystyczną, ponieważ sygnalizuje, że praca ma charakter tymczasowy i zachęca do krytyki strukturalnej, która jest na tym etapie najbardziej przydatna.

Modele szkieletowe pozwalają również na tanie iterowanie. Zmiana układu pudełek zajmuje minuty, podczas gdy zmiana układu gotowej kompozycji trwa godziny i wywołuje emocjonalny opór przed zmianami ze względu na już włożony wysiłek. Eksperymentowanie z kilkoma podejściami strukturalnymi do tego samego problemu jest zatem realistyczne na etapie modelu szkieletowego i rzadko zdarza się po rozpoczęciu prac o wysokiej wierności. Dlatego zespoły, które rezygnują z tworzenia modeli szkieletowych, zazwyczaj od razu oddają pierwszy pomysł strukturalny, jaki kiedykolwiek wpadł im do głowy.

Wierność powinna odpowiadać zadanemu pytaniu. Wstępne szkice są odpowiednie do wczesnych analiz, gdy w grę wchodzi kilka kierunków. Bardziej szczegółowe diagramy szkieletowe z rzeczywistą treścią, precyzyjną hierarchią i realistycznymi wolumenami danych są odpowiednie po wybraniu kierunku, ponieważ tekst zastępczy ukrywa problemy ujawniane przez rzeczywistą treść: niepasujące nagłówki, niezręcznie zawijające się nazwy produktów, puste stany, których nikt nie brał pod uwagę, oraz listy, które zachowują się inaczej przy trzech elementach niż przy trzystu.

Najczęstszym błędem jest traktowanie makiet jako obowiązkowego produktu, a nie narzędzia do myślenia. Stworzenie kompletnego zestawu makiet dla każdego ekranu, następnie kompletnego projektu wizualnego, a następnie kompletnego prototypu to sekwencja kaskadowa, która pochłania tygodnie i opóźnia kontakt z rzeczywistymi użytkownikami. Współczesne praktyki skłaniają się ku selektywnemu tworzeniu makiet, koncentrując się na ekranach, których struktura jest rzeczywiście niepewna, i przechodząc od razu do bardziej precyzyjnych rozwiązań, gdzie ustalone wzorce już odpowiadają na pytanie, szczególnie gdy system projektowy dostarcza gotowe komponenty.

Modele szkieletowe są również przydatne jako narzędzie komunikacji z inżynierami, a ich zastosowanie jest często pomijane. Artefakt strukturalny pokazujący, jaka treść istnieje, skąd pochodzi i jakie są stany poszczególnych regionów, stanowi lepszą podstawę do wczesnych dyskusji o wykonalności niż projekt wizualny, ponieważ ujawnia pytania, na które inżynierowie faktycznie potrzebują odpowiedzi: jakie dane są wymagane, co się dzieje, gdy ich brakuje, jak region zachowuje się wraz ze zmianą objętości treści oraz które części są statyczne, a które spersonalizowane. Prowadzenie tej rozmowy na etapie modelu szkieletowego często zmienia projekt, ponieważ struktura wymagająca nieistniejących danych lub zapytanie, którego nie można wykonać, jest lepiej identyfikowane przed pracami wizualnymi niż po rozpoczęciu implementacji.

Modele szkieletowe są również odpowiednim artefaktem do wczesnych testów. Problemy strukturalne, takie jak etykiety nawigacji, których użytkownicy nie rozumieją, lub przepływ, którego sekwencja nie jest zgodna z oczekiwaniami, można wykryć przy użyciu wstępnych artefaktów i są one znacznie tańsze do naprawienia na tym etapie niż po wdrożeniu. Przeprowadzenie wczesnych sesji koncepcyjnych badania użytkowników Na etapie szkieletu projektu zazwyczaj zmienia się kierunek projektu bardziej niż testy po projektowaniu wizualnym, gdy koszty zmian strukturalnych wzrosły, a zapotrzebowanie na nie spadło. projekt produktu zaangażowanie, ta wczesna walidacja strukturalna zwykle decyduje o tym, czy ostateczna wersja rozwiązuje właściwy problem.