Wykład 14.

Projekt interfejs użytkownika... Podstawowe zasady i etapy projektowania interfejsu użytkownika: wybór struktury dialogu, opracowanie scenariusza dialogu, zdefiniowanie i umieszczenie elementów wizualnych. Elastyczne interfejsy. Narzędzia wsparcia użytkownika, systemy pomocy

Interfejs użytkownika Jest zbiorem modelu informacyjnego obszaru problemowego, środków i metod interakcji użytkownika z modelem informacyjnym, a także komponentów zapewniających ukształtowanie się modelu informacyjnego w procesie pracy system oprogramowania (slajd 14.1) .

Model informacyjny rozumiany jest jako warunkowa reprezentacja obszaru problemowego, utworzona za pomocą komputerowych (wizualnych i dźwiękowych) obiektów, które odzwierciedlają kompozycję i interakcję rzeczywistych składników obszaru problemowego.

Środki i metody interakcji z modelem informacyjnym są określone przez skład sprzętu i oprogramowania dostępnego dla użytkownika oraz przez naturę rozwiązywanego problemu. O wydajności pracy użytkownika decyduje nie tylko funkcjonalność sprzętu i narzędzia programowe, ale także dostępność tych możliwości dla użytkownika. Z kolei kompletność wykorzystania potencjalnych możliwości dostępnych zasobów zależy od jakości interfejsu użytkownika.

Jakość interfejsu użytkownika jest niezależną cechą produktu programowego, porównywalną pod względem ważności z takimi wskaźnikami, jak niezawodność i efektywność wykorzystania zasobów obliczeniowych.

Według badań firmy Xerox i jej współpracownika Davida Liddle'a, interfejs użytkownika składa się z następujących głównych komponentów, przedstawionych jako góra lodowa.

Zgodnie z tym opracowaniem interfejs składa się z trzech głównych części - prezentacji informacji użytkownikowi, interakcji i relacji między obiektami. W tym przypadku „widoczna” część góry lodowej jest znacznie mniejsza niż jej „niewidoczna”, ukryta część (slajd 14.2). Szczyt góry lodowej - informacje dla użytkowników (kolor, animacja, dźwięk, kształt obiektów, położenie informacji na ekranie, grafika) to tylko 10% i nie jest bynajmniej najważniejszym elementem interfejsu użytkownika. Kolejną częścią interfejsu użytkownika (30% modelu projektanta) jest technika komunikacji z użytkownikiem i informacja zwrotna od niego. I wreszcie dolna część góry lodowej (60%) modelu projektanta - najważniejsza jej część to właściwości obiektów i relacje między nimi.

14.1. Podstawowe zasady projektowania interfejsu użytkownika

Główną zaletą dobrego interfejsu użytkownika jest to użytkownik zawsze czuje, że obsługuje oprogramowanie, a nie oprogramowanie nim steruje.

Aby wywołać u użytkownika takie poczucie „wewnętrznej wolności”, interfejs musi posiadać szereg właściwości. (slajd 14.4) :

Naturalność interfejsu.

Spójność interfejsu.

Łatwość obsługi interfejsu (zasada „przebaczenia użytkownikowi”)

Zasada „informacji zwrotnej”.

Prostota interfejsu.

Elastyczność interfejsu.

Estetyczny wygląd.

Naturalność interfejsu. Interfejs naturalny to taki, który nie zmusza użytkownika do znaczącej zmiany zwykłych sposobów rozwiązywania problemu. Oznacza to w szczególności, że komunikaty i wyniki generowane przez aplikację powinny być oczywiste.

Spójność interfejsu. Spójność pozwala użytkownikom przenosić istniejącą wiedzę do nowych zadań, szybciej opanować nowe aspekty, a tym samym skupić uwagę na rozwiązywanym problemie, a nie tracić czasu na zrozumienie różnic w stosowaniu niektórych elementów sterujących, poleceń itp. Zapewniając ciągłość dotychczasowej wiedzy i umiejętności, spójność sprawia, że \u200b\u200binterfejs jest rozpoznawalny i przewidywalny.

Spójność jest ważna dla wszystkich aspektów interfejsu, w tym nazw poleceń, wizualnej prezentacji informacji i zachowania elementów interaktywnych. Aby zaimplementować właściwość spójności w tworzonym oprogramowaniu, konieczne jest uwzględnienie różnych jego aspektów.

Konsystencja w produkcie.Ten sam zespół powinien pełnić te same funkcje, gdziekolwiek się spotkają i w ten sam sposób.

Spójność w środowisku produkcyjnym.Zachowując spójność z interfejsem zapewnianym przez system operacyjny (na przykład system operacyjny Windows), niestandardowa aplikacja może opierać się na wiedzy i umiejętnościach, które użytkownik nabył wcześniej w innych aplikacjach.

Konsekwencja w stosowaniu metafor.Jeśli zachowanie obiektu oprogramowania wykracza poza to, co zwykle rozumie się przez odpowiadającą mu metaforę, użytkownik może mieć trudności z pracą z tym obiektem.

Łatwość obsługi interfejsu (zasada „przebaczenia użytkownikowi”). Użytkownicy zwykle poznają specyfikę pracy z nowym oprogramowaniem metodą prób i błędów. Efektywny interfejs musi uwzględniać to podejście. Na każdym etapie pracy powinien zezwalać tylko na odpowiedni zestaw działań i ostrzegać użytkowników o sytuacjach, w których mogą uszkodzić system lub dane; jeszcze lepiej, jeśli użytkownik ma możliwość cofnięcia lub skorygowania podjętych działań.

Nawet przy dobrze zaprojektowanym interfejsie użytkownicy mogą popełniać błędy. Błędy te mogą mieć charakter „fizyczny” (losowy wybór niewłaściwego polecenia lub danych) i „logiczny” (podejmowanie złej decyzji o wyborze polecenia lub danych). Skuteczny interfejs powinien być w stanie zapobiegać sytuacjom, które mogą prowadzić do błędów. Musi także być w stanie dostosować się do potencjalnych błędów użytkownika i ułatwiać proces eliminacji konsekwencji takich błędów.

Zasada „informacji zwrotnej”. Zawsze należy przekazywać informacje zwrotne dotyczące działań użytkownika. Każde działanie użytkownika musi otrzymać wizualne, a czasem dźwiękowe potwierdzenie, że oprogramowanie zaakceptowało wprowadzone polecenie; rodzaj reakcji powinien w miarę możliwości uwzględniać charakter wykonywanej czynności.

Informacja zwrotna jest skuteczna, jeśli jest wdrażana terminowo, tj. jak najbliżej punktu ostatniej interakcji użytkownika z systemem. Gdy komputer przetwarza przychodzące zadanie, przydatne jest dostarczenie użytkownikowi informacji o stanie procesu, a także o możliwości jego przerwania w razie potrzeby. Nic tak nie myli niedoświadczonego użytkownika, jak zablokowany ekran, który w żaden sposób nie reaguje na jego działania. Typowy użytkownik może wytrzymać tylko kilka sekund oczekiwania na odpowiedź od swojego elektronicznego „rozmówcy”.

Prostota interfejsu. Interfejs powinien być prosty. Nie oznacza to nadmiernego uproszczenia, ale zapewnienie łatwości w jego badaniu i stosowaniu. Ponadto musi zapewniać dostęp do całej listy funkcjonalnośćdostarczane przez tę aplikację. Dostęp do bogatej funkcjonalności i łatwość obsługi są ze sobą sprzeczne. Zaprojektowanie skutecznego interfejsu ma na celu zrównoważenie tych celów.

Jednym z możliwych sposobów zachowania prostoty jest przedstawienie na ekranie informacji, które stanowią minimum niezbędne do wykonania przez użytkownika kolejnego kroku zadania. W szczególności należy unikać pełnych nazw poleceń lub komunikatów. Słabe lub niepotrzebne frazy utrudniają użytkownikowi wydobycie odpowiednich informacji.

Innym sposobem na stworzenie prostego, ale efektywnego interfejsu jest ułożenie i zaprezentowanie elementów na ekranie z uwzględnieniem ich znaczenia semantycznego i relacji logicznej. Pozwala to na wykorzystanie w procesie asocjacyjnego myślenia użytkownika.

Innym sposobem zarządzania złożonością wyświetlanych informacji jest użycie spójne ujawnianie (okna dialogowe, sekcje menu itp.). Ujawnianie sekwencyjne zakłada taką organizację informacji, w której w każdym momencie na ekranie znajduje się tylko ta ich część, która jest niezbędna do wykonania kolejnego kroku. Zmniejszając ilość informacji prezentowanych użytkownikowi, a tym samym zmniejszając ilość informacji do przetworzenia. Przykładem takiej organizacji jest menu hierarchiczne (kaskadowe), którego każdy poziom wyświetla tylko te pozycje, które odpowiadają jednej wybranej przez użytkownika pozycji na wyższym poziomie.

Jedną z metodologicznych podstaw organizacji zarządzania procesem przetwarzania jest wykorzystanie „metafor” - znaczących analogów przetwarzania danych docelowych, ale w obszarach bardziej powszechnych dla ludzi niż automatyzacja.

Na przykład metafora „pulpit” sugeruje, że interfejs zapewnia użytkownikowi możliwość dostępu do wielu różnych źródeł informacji i pozwala mu łatwo przełączać się z jednego źródła na inne (to znaczy „przesuwać dokumenty na stole”), zmieniać jeden typ zadania (arkusz kalkulacyjny ) do innego (system przygotowania tekstu). W takim przypadku użytkownik ma również dostęp do wszelkich innych środków, w tym pomocniczych (kalkulator, zegar itp.).

Użytkownik może przenosić informacje z jednego dokumentu do drugiego, umieszczając żądane części jednego dokumentu w odpowiednich miejscach w innym dokumencie. Jest to związane z inną metaforą - „schowkiem”. Przed pojawieniem się zautomatyzowanych systemów przetwarzania tekstu istniał tradycyjny sposób na ułatwienie układu: wklejenie wycinanki zamiast przepisywania strony. Interfejsy WIMP zapewniają podobne możliwości wycinania i wklejania, ale schowek, do którego wstawia się wycięcie, umożliwia wstawienie dowolnej liczby kopii elementów danych.

Zasada metaforyczna jest również podstawą technologii WISIWIG - natychmiastowej wizualizacji wyników działań na ekranie. Oznacza to, że ekran musi symulować sposób drukowania, a jeśli użytkownik chce wydrukować część tekstu kursywą, to również musi być napisany na ekranie kursywą. Jeśli plik zostanie zniszczony, użytkownik widzi, że plik znika z listy plików wyświetlanej na ekranie. Interfejs w naturalny sposób dostarcza użytkownikowi informacji o stanie obiektu, potwierdzając, że akcja została podjęta. Można powiedzieć, że ta metafora bardziej pasuje do formuły „ Widzisz, co otrzymałeś w wyniku swoich działań ”.

Elastyczność interfejsu. Elastyczność interfejsu to jego zdolność do uwzględnienia poziomu wyszkolenia i produktywności użytkownika. Właściwość elastyczność implikuje możliwość zmiany struktury okna dialogowego i / lub danych wejściowych. Elastyczna koncepcja (adaptacyjny) interfejs jest obecnie jednym z głównych obszarów badań interakcji między człowiekiem a komputerem. Głównym problemem nie jest to, jak uporządkować zmiany w dialogu, ale jakie znaki należy użyć, aby określić potrzebę zmian i ich istotę.

Estetyczny wygląd. Prawidłowa wizualna reprezentacja zastosowanych obiektów zapewnia przekazanie bardzo ważnych dodatkowych informacji o zachowaniu i interakcji różnych obiektów. Jednocześnie należy pamiętać, że każdy element wizualny pojawiający się na ekranie potencjalnie wymaga uwagi użytkownika, która, jak wiadomo, nie jest nieograniczona.

Jakość interfejsu jest trudna do oceny za pomocą cech ilościowych, ale jego mniej lub bardziej obiektywną ocenę można uzyskać na podstawie następujących szczegółowych wskaźników.

Czas, w jakim określony użytkownik osiągnie określony poziom wiedzy i umiejętności korzystania z aplikacji.

Zachowanie nabytych umiejętności pracy po określonym czasie (np. Po tygodniowej przerwie użytkownik musi wykonać określoną sekwencję czynności w zadanym czasie).

Szybkość rozwiązania problemu za pomocą tej aplikacji; w tym przypadku nie należy oceniać szybkości działania systemu i nie szybkości wprowadzania danych z klawiatury, ale czas potrzebny do osiągnięcia celu rozwiązanego problemu. Na tej podstawie kryterium oceny tego wskaźnika można sformułować np. Następująco: użytkownik musi przetwarzać co najmniej 20 dokumentów na godzinę z błędem nie większym niż 1%.

Subiektywna satysfakcja użytkownika z pracy z systemem (wyrażona ilościowo jako procent lub ocena w n-punktowej skali).

Na tym etapie gromadzone i analizowane są dane użytkowników, sformalizowana funkcjonalność i ustalone obiektywne kryteria sukcesu projektu.

Sformalizowanie kontekstu użytkowania

Formalizacja obiektywnych kryteriów sukcesu

Analiza celu

Formalizacja ról biznesowych użytkowników

Formalizacja funkcjonalności

Formalizacja scenariuszy działań użytkownika

Przegląd interfejsu systemu konkurencyjnego

Sformalizowanie nawyków i oczekiwań użytkowników

Sformalizowanie kontekstu użytkowania

Na tym etapie zbierana jest większość informacji o użytkownikach. Opisano następujące właściwości odbiorców systemowych:

Charakterystyka użytkownika: doświadczenie z komputerem, znajomość tematyki, motywy, wielkość / znaczenie grup użytkowników, wzorce (typowe sytuacje) użytkowania;

Cele i zadania użytkownika;

Cele projektu: jaka była przyczyna powstania projektu, etapy powstawania projektu, jakie rezultaty należy uzyskać, jakie informacje są potrzebne i kiedy;

Rozwój technologii i platformy, na której będą pracować użytkownicy;

Środowisko, w którym projekt będzie tworzony i wykorzystywany (fizyczne, rynkowe, organizacyjne i kulturowe).

Przy wejściu: dostęp do obecnych i potencjalnych użytkowników systemu, ekspertów i dokumentacji projektowej.

Na wyjściu: opis kontekstu korzystania z systemu, możliwy jest bardziej szczegółowy opis właściwości użytkownika.

w górę do spisu treści

Formalizacja obiektywnych kryteriów sukcesu.

Na tym etapie wyróżnia się obiektywne kryteria oceny ergonomii interfejsu, takie jak wskaźniki wydajności, produktywności, satysfakcji użytkowników (nie można wyodrębnić tych kryteriów na wcześniejszych etapach).

W związku z tym na tym etapie tworzone jest rzeczywiste zadanie projektowania interfejsu. Na przykład:

Grupa użytkowników ciągle się zmienia, a zamierzony wzorzec użytkowania nie jest często używany. Konieczne jest skupienie się na łatwości zrozumienia interfejsu.

To samo zadanie jest powtarzane wielokrotnie, a grupa użytkowników jest dość duża. Konieczne jest skupienie się na efektywności użytkowania.

zmniejszyć liczbę błędów ludzkich o 20%.

Przy wejściu: dostęp do użytkowników, ekspertów i dokumentacji projektowej.

Wynik: lista obiektywnych kryteriów sukcesu.

w górę do spisu treści

Analiza celu

Deweloper musi jasno zrozumieć, że użytkownicy nie potrzebują samych narzędzi, potrzebne są tylko wyniki ich pracy. Nikt nie potrzebuje edytora tekstu - potrzebuje umiejętności wygodnego pisania tekstów. Nikt nie potrzebuje programu do przetwarzania obrazu - potrzebują już przetworzonych obrazów. Oznacza to, że same funkcje nie są dla nikogo potrzebne ani ważne. Ogólnie rzecz biorąc, ludzie potrzebują narzędzia, które umożliwi wykonanie każdego rodzaju pracy.

Różnicę w podejściu do wyboru funkcjonalności wygodnie zilustruje przykład tostera. Standardowe podejście, w którym funkcje są wybierane praktycznie dowolnie, doprowadzi w najlepszym przypadku do tego zadania: „Potrzebujemy pudełka z wąskim prostokątnym otworem i grzejnikiem w środku”.... Analiza celów użytkownika doprowadzi do innego sformułowania: „Potrzebuję tosty. Wydaje się, że najłatwiej to osiągnąć, tworząc pudełko z otworem w kształcie kawałka chleba i grzejnikiem w środku. Z drugiej strony wydaje się, że ta metoda nie jest jedyną ”... Druga opcja, przy pełnym rozwinięciu tej metody, może doprowadzić nie tylko do powstania tostera, ale także brytfanny (czyli urządzenia, w którym można opiekać nie tylko chleb).

Rezultatem tego procesu powinna być lista celów, na przykład dla tostera, ostateczna lista celów powinna wyglądać bardzo prosto: „Trzeba smażyć małe kawałki jedzenia, głównie chleb”..

Dane wyjściowe: zalecenia dotyczące optymalizacji interfejsu, lista udanych i nieudanych rozwiązań interfejsu (główny nacisk kładziony jest na rozwiązania, które się nie powiodły). Jeśli na tym etapie przeprowadzono testy użyteczności aktualnej wersji, raport zawiera krótkie protokoły oraz listę wyników badań.

Przy wejściu: dostęp do użytkowników, ekspertów i dokumentacji projektowej

Wynik: lista celów dla wdrożenia nowego interfejsu z charakterystykami wagi każdego z nich.

w górę do spisu treści

Formalizowanie ról biznesowych użytkowników

Funkcjonalność dowolnego systemu jest podzielona na kilka ról użytkowników: różni użytkownicy potrzebują różnych bloków funkcjonalności (w systemach automatyki role te nazywane są rolami biznesowymi). Nawigacja w systemie zależy bezpośrednio od tych ról, ponieważ nie jest pożądane włączanie funkcji z roli obcej do nawigacji w ramach jednej roli. W związku z tym na tym etapie rozróżnia się główne role użytkowników wraz z funkcjami związanymi z tymi rolami. Również na tym etapie odbywają się wywiady z każdym z przedstawicieli o określonej roli w celu zidentyfikowania cech tej roli i ustalenia, jakie dodatkowe (w stosunku do formalnych) możliwości należy zapewnić.

Na tym etapie można zastosować metodę obserwacji osób wykonujących swoje zadanie z wykorzystaniem istniejących narzędzi, a dokładnie systemu konkurentów (jeśli istnieją) i obiektów ze świata rzeczywistego. Dobrym źródłem materiału do analizy często nie jest nawet obserwacja ludzi, ale analiza wyników ich pracy - jeśli okaże się, że efekt pracy praktycznie nie zależy od zastosowanego narzędzia, to oznacza, że \u200b\u200bpotrzebna jest tylko ta funkcjonalność, która miała wpływ na wynik (tj. funkcje, których nikt nie używał, są niepotrzebne).

Zwykle jest ich kilka różne sposoby realizować tę samą funkcję. Analiza działań użytkownika pozwala tylko określić, która metoda powinna zostać wdrożona. Ponieważ na tym etapie dowiemy się dokładnie, jaka funkcjonalność jest potrzebna dla każdej roli biznesowej, możemy wybrać właściwą ścieżkę zgodnie z zasadą „im mniej działań wymaga od użytkownika, tym lepiej”.

Wynik: opis ról biznesowych użytkownika.

w górę do spisu treści

Formalizacja funkcjonalności

Na tym etapie, na podstawie informacji wygenerowanych w poprzednich etapach, ostatecznie powstaje lista funkcjonalności nowej wersji systemu. Wcześniej utworzony TK czasami nie zawiera części niezbędnej funkcjonalności lub zawiera funkcje, które nie są tak naprawdę wymagane przez użytkowników.

Na wejściu: dostęp do użytkowników, ekspertów i dokumentacji projektowej, znajomość głównych aspektów tematyki.

Wynik: opis funkcjonalności systemu (raport z realizacji tego etapu prac zwykle nie jest tworzony, zamiast tego aktualizowane jest już utworzone zadanie techniczne).

w górę do spisu treści

Formalizacja scenariuszy działań użytkownika

Na tym etapie typowe scenariusze działań użytkownika są częściowo badane, częściowo opracowywane: sformalizowane są dane niezbędne użytkownikom do wykonania pracy, kolejność samej pracy, kryteria wykonania tej pracy.

Celem tego etapu jest napisanie werbalnego opisu interakcji użytkownika z systemem, bez dokładnego określania, jak ma miejsce interakcja, ale płacąc więcej uwagi wszystkie cele użytkowników. Liczba scenariuszy może być dowolna, najważniejsze jest to, że muszą obejmować wszystkie rodzaje zadań stojących przed systemem i być w pewnym stopniu realistyczne. Bardzo wygodne jest rozróżnianie skryptów po nazwach uczestniczących w nich fikcyjnych postaci.

Załóżmy, że musisz opracować skrypty dla przyszłego programu pocztowego. Najwyraźniej to zadanie wymaga trzech scenariuszy:

Elizaveta Petrovna uruchamia program pocztowy. Obejmuje proces pobierania nowej poczty. Po odebraniu poczty czyta wszystkie wiadomości, następnie usuwa część z nich i odpowiada na jedną wiadomość. Następnie wyłącza program pocztowy.

Andrey Fedorovich aktywuje okno już otwartego programu pocztowego i rozpoczyna proces pobierania nowa poczta... Po odebraniu wiadomości czyta ją. Przekazuje jedną wiadomość innemu adresatowi, następnie usuwa ją i drukuje następną. Następnie przechodzi do innego zadania.

Nadeszła nowa wiadomość i administrator systemu Andrey dostrzega odpowiedni wskaźnik. Uaktywnia okno programu pocztowego i otwiera otrzymaną wiadomość. Czyta go, a następnie przenosi do innego folderu. Następnie przechodzi do innego zadania.

Te skrypty mają podwójną wartość. Po pierwsze, będą przydatne do późniejszego testowania, ponieważ testowane jest nie wykonanie abstrakcyjnych zadań, ale wykonanie konkretnych operacji zawartych w tych scenariuszach. Po drugie, sam fakt ich napisania zwykle, choć nie zawsze, prowadzi do lepszego zrozumienia projektu projektowanego systemu, skłaniając do natychmiastowej optymalizacji przyszłych interakcji. W takich scenariuszach niepotrzebne kroki są bardzo dobrze widoczne. Na przykład w trzecim scenariuszu administrator systemu Andrey po otrzymaniu wskaźnika nie mógł od razu otworzyć nowej wiadomości, ale musiał otworzyć okno systemowe, znaleźć żądaną wiadomość, otworzyć ją, a dopiero potem przeczytać. Oczywiste jest, że te niepotrzebne etapy można bezpiecznie wyeliminować już na tym wczesnym etapie projektowania.

Na wejściu: dostęp do użytkowników, ekspertów i dokumentacji projektowej, znajomość głównych aspektów tematyki.

Wynik: scenariusze pracy użytkowników (opracowane scenariusze z reguły przedstawiane są w postaci schematów blokowych opisujących cały proces wykorzystania systemu do wykonania określonego zadania).

w górę do spisu treści

Przegląd interfejsu systemu konkurencyjnego

Większość odbiorców dowolnego systemu ma umiejętności korzystania z kilku konkurujących ze sobą systemów; jeśli opracowywany interfejs jest całkowicie odmienny od konkurencji, użytkownicy będą musieli nauczyć się od nowa. Ponadto konkurencyjne systemy często zawierają efektywne rozwiązania, które są przydatne do przyjęcia (lub częściej do uwzględnienia przy projektowaniu interfejsu).

Podobnie jak w przypadku eksperckiej oceny obecnego interfejsu systemu, raport z realizacji tego etapu prac zawiera listę udanych i nieudanych rozwiązań interfejsowych; Ogólnie jednak w raporcie bardziej skupiono się na dobrych rozwiązaniach.

Przy wejściu: dostęp do konkurencyjnych systemów.

Wynik: przegląd zalet i wad interfejsu konkurujących systemów.

w górę do spisu treści

Sformalizowanie nawyków i oczekiwań użytkowników

Na tym etapie badane są subiektywne oczekiwania użytkowników systemu. Bez tych badań trudno lub niemożliwe jest przewidzenie, jak użytkownicy będą się czuć o przyszłym systemie.

Przy wejściu: dostęp dla użytkowników.

Na wyjściu: opis cech, które musi spełniać interfejs, aby zwiększyć subiektywną satysfakcję, lista cech systemu, które są istotne dla użytkowników. W zależności od wybranej metody badawczej zawiera dane liczbowe lub szacunkowe.

Ten artykuł będzie przydatny dla tych, którzy dopiero zaczynają tworzyć interfejsy - zorientujesz się, w jakim kierunku iść. Doświadczonym nie obiecujemy niczego nowego, maksimum - Twoja wiedza stworzy spójny obraz. Od czego więc zacząć projektowanie?

Bieganie po czytanie książek i artykułów Google w poszukiwaniu inspiracji nie jest najlepszy pomysł... Interfejsy do czytania nie są projektowane samodzielnie i nie stają się lepszej jakości. Oczywiście teoria jest dobra, ale jak w każdym biznesie teoria „nie zajdzie daleko”. Nie ma też sensu odwoływanie się do materiałów referencyjnych na początkowym etapie - należy to zrobić z konkretnymi pytaniami. Niekończące się poszukiwanie programów do projektowania nie zwiększa produktywności.

Więc co robisz, aby zacząć projektować?

Po pierwsze, kiedy zabierasz się do pracy, powinieneś pomyśleć o wyniku: obrazach (czyli interfejsach) i działaniach. Po drugie, pomogą konkretne kroki: zrozumieć problem, sformułować zadanie, stworzyć przynajmniej coś, a następnie poprawić, napisać historie (opowiem o nich poniżej w tekście) lub zasięgnąć porady doświadczonych osób.

Brak doświadczenia i brak odpowiedzi na pytanie „Od czego zacząć?” pojawia się strach. Strasznie jest zrobić coś nowego, ale nie ma sensu siedzieć bez końca. Pierwszy naleśnik nadal będzie grudkowaty. Nie bój się mówić o swoim pierwszym doświadczeniu. Każdy utworzony interfejs - nawet jeśli jest okropny - może być nadal używany.

Tworzenie historii

Pierwszą rzeczą do zrozumienia jest to, że interfejsy to język, który już znamy. Każdy użytkownik może czytać i pisać w tym języku. Oczywiście z błędami, ale może. Jak każdy język, istnieją interfejsy do przesyłania myśli. Wśród ludzi zwyczajem jest spójne wypowiadanie się, więc pierwszym krokiem jest sformułowanie pomysłów i stworzenie fabuły, która przykuwa słuchacza i nadaje impuls wszystkiemu, co się dzieje.

Aby zrozumieć, co rozumiemy przez termin „historia”, wyobraźmy sobie: Maxim zostaje klientem salonu Star of the Newa - kupił sobie nowy samochód. Zawierając umowę w siedzibie firmy, pracownicy dealera informują go o istnieniu systemu online dla klientów, w którym może zobaczyć swoje płatności, spłaty kredytu, przypomnienia o przeglądzie technicznym i ubezpieczeniu, a także nowości z salonu samochodowego.

Przy takim podejściu zaczynamy „kręcić” historię. Najważniejszą rzeczą w procesie tworzenia historii jest wypracowanie wszystkich możliwych scenariuszy rozwoju wydarzeń.

Po wejściu do systemu Maxim widzi swoją pierwszą wypłatę w salonie samochodowym, charakterystykę swojego samochodu, dokumenty do samochodu, nazwisko swojego kierownika. Jeśli jego zakup objęty jest jakąkolwiek promocją, w systemie pojawi się informacja o warunkach promocji (np. Bezpłatna myjnia klasy luksusowej w sierpniu).

Będąc w domu, Maxim coraz lepiej poznaje system. W trakcie poznawania system dostosowuje się do Maxima i pokazuje mu najważniejsze informacje.

Bez historii nie ma produktu, projektu, interfejsu. Spójna historia pomoże wyjaśnić zachowanie użytkownika i zrozumieć, czego mu brakuje.

W interakcji z komputerem osoba stara się nie zamienić się w maszynę, a wręcz przeciwnie, humanizować system. Bez względu na to, jaką funkcję dołączysz, bez emocji, osoba nie będzie zainteresowana. Ludzie oczekują od komputera nowych doświadczeń i reakcji. Dobre historie wywołują reakcję emocjonalną: czy ci się to podoba, czy nie, szybko i powoli, chcesz lub nie.

Spal czasownikiem

Zanim zaczniesz coś rysować, omów z zespołem spójną historię, którą zamierzasz uchwycić. Dodaj czasowniki, aby pokierować fabułą, aby szybko ujawnić scenariusz zachowania użytkownika. Na szczególną uwagę zasługuje element literowy. Przeanalizuj słowa i sformułowania: bez względu na to, jakie przymiotniki i rzeczowniki pojawiają się w opowieści, nic się nie wydarzy bez czasowników.

Rozpraszania w stylu „fajnie byłoby tu zrobić guziki” powinny zostać odcięte, ponieważ odciągają myśl od spójnej historii. Pracując nad interfejsem, każdy powinien znać fabułę interakcji użytkownika z usługą i przewijać ją w głowie. Bez spójnej historii nie ma spójnych interfejsów.

Niech gra!

Popularną prowizją, na którą można wejść, jest powiedzenie „do diabła z teorią, zagrajmy!” Oczywiście jest to także sposób na naukę projektowania: opanowujemy narzędzie i po drodze zdobywamy umiejętność. Problem w tym, że narzędzie nie pozwoli Ci poprawnie rozwiązać problemu, wiedza i doświadczenie zwykle w tym pomagają. Aby nie tracić czasu na przeglądanie programów, krótko o nich opowiemy.

Tworzenie złożonego i dobrego interfejsu to proces skupiający ekspertów z różnych dziedzin. Zajmuje to dużo czasu, dlatego tworzenie witryny lub interfejsu programu jest podzielone na określone etapy.

Proponowany podział nie jest uniwersalny. Każdy z etapów można podzielić na podetapy. I dalej podpodstagów - to sprawia, że \u200b\u200bproces wygląda jeszcze bardziej skomplikowanie, przez co w oczach klientów jest droższy :-)

1. Gromadzenie danych

Gromadzenie danych jest potrzebne, aby jasno zrozumieć, na jakim rodzaju produktu istnieje ten momentco nie odpowiada klientowi i jakiego efektu oczekuje od współpracy. Na tym etapie tworzenia interfejsu programu projektant:

• komunikuje się z klientemzrozumienie znaczenia i filozofii programu;
• przygląda się rozwojowi: gotowe prototypy (nawet jeśli istnieją tylko na serwetce);
• analizuje programy konkurencji (i ewentualnie przeprowadzenie testów użyteczności programów konkurencji);
• prowadzi ustrukturyzowane wywiady z klientami lub potencjalnych klientów.

2. Projekt

Na tym etapie tworzenia interfejsu programu projektant:

• definiuje siatkę, kolory, czcionki i tło;
• a także często tworzy niestandardowe kontrolki, takie jak menu rozwijane.

Oczywiście na każdym etapie jest dyskusja i, jeśli to konieczne, bezpłatna powtórka. Twoje zamówienie otrzymasz jako pliki graficzne w formacie Photoshopalub w formularzu Kod HTML lub XAML.

4. Wdrożenie

Kiedy wszystko jest jasne w interfejsie, pozostaje niewiele rzeczy :) Z reguły nasi klienci zatrudniają programistów na pełny etat, a nas przyciąga do różnych prac związanych z interfejsem użytkownika, od projektowania po tworzenie ikon. Jednak tym klientom, którzy nie mają własnych programistów, oferujemy tworzenie i testowanie aplikacji webowych i mobilnych na iOS. Posiadamy stały dział programistów i testerów. Gwarantujemy: brak freelancingu.

Na etapie wdrożenia trwają prace nad rozwojem i testowaniem (QA, a nie użyteczności) programu. Deweloperzy to zrobią zrozumiałejak zrobić coś na podstawie pliki graficzne (szkice) i wyjaśnienia do nich. W przeciwnym razie narysujemy i dodamy.

Oczywiście rozwój jest podzielony na etapy, ale nie będziemy ich tutaj opisywać dla zwięzłości.

5. Testy użyteczności

Zaangażowanie w projekt dobrego projektanta interfejsów nie wyeliminuje konieczności systematycznego przeprowadzania testów użyteczności. Poleganie wyłącznie na „genialnym projektancie interfejsu” jest szkodliwe z następujących powodów:

• oczywiście do prac nad projektem należy starać się zaangażować najlepszych projektantów interfejsów (np. VisualPharm :), ale niestety nie zawsze jest to możliwe. Czasami ludzie biorą udział w Twoim projekcie tych ludzi, których możesz przyciągnąća nie te, o których marzysz;
• projektowanie nie jest nauką ścisłą; nawet jeśli twój projektant jest geniuszem, nie wszystkie jego pomysły są sobie równe. Dlatego też, aby zmniejszyć ryzyko, logiczne byłoby poddanie wszystkich tych pomysłów testom w warunkach rzeczywistych z udziałem prawdziwych użytkowników. (pamiętaj, nowe pomysły można przetestować z minimalny koszt przy użyciu technik, takich jak papierowy prototyp);
• w jaki sposób projektanci front-endu stają się w ogóle dobrymi projektantami? To bardzo proste: uczenie się z doświadczenia, które pomysły działają, a które nie. Ale potrzebne są testy, aby zdobyć to doświadczenieprowadzone przez specjalistów ds. użyteczności;
• nawet najlepsi projektanci mogą stworzyć udany produkt tylko wtedy, gdy dobrze wykonają swoją pracę. Cudowny interfejs nie pomoże, jeśli funkcjonalność jest zbudowana niepiśmiennie. I w jaki sposóbprojektanci interfejsówdowiedz się, czego potrzebują użytkownicy? Odpowiedź jest prosta: poprzez badania użyteczności;
• nikt nie jest doskonały. Nawet więcej dobry projekt można poprawić, przechodząc przez stopniowy proces poprawy jakości. Na każdym etapie przeprowadzasz testy z użytkownikami i na podstawie wyników krok po kroku poprawiasz jakość interfejsu użytkownika.

• szybki: 2-7 dni na test;
• tani - jeden lub dwa rzędy wielkości tańsze niż duże badania;
• wśród docelowych odbiorców... Znajdziemy ją. Czy potrzebujesz Amerykanów z Środkowego Zachodu w wieku 30-55 lat zainteresowanych rosyjskimi narzeczonymi? Zapraszamy.

Możesz przeprowadzić testy użyteczności zarówno prototypu, jak i gotowego produktu. Zalecenie ogólne - zrobić wiele małych testów iteracyjnych zamiast jednego dużego testu... Wykonane, przetestowane, poprawione, ponownie przetestowane. Pozwoli ci to znaleźć i naprawić nieoczywiste błędy.

wyczucie czasu

Czas pracy zależy na liczbę ekranów... Tyle samo czasu zajmuje zaprojektowanie i zaprojektowanie jednego ekranu. Zwykle potrzebujemy dwa dnitworzyć prototyp (lub projekt) jednego ekranui kolejne pięć dni na realizację całego zamówienia. Dlatego opracowanie (zaprojektowanie lub zaprojektowanie) pięciu ekranów zajmie 15 dni roboczych.

Dokonywanie poprawek na Twoją prośbę zajmie dodatkowy czas. Chociaż nie pobieramy dodatkowych opłat za edycje, mogą one wpłynąć na czas realizacji projektu. Często zmiany trwają dłużej niż samo tworzenie ekranów.

Przewodzić test użytecznościpotrzeba około 6 dni roboczych... Wszystko zależy od tego, czy chodzi o testowanie całej aplikacji, czy o małe testy iteracyjne.

Koszt

Projekt i konstrukcja pojedynczego ekranu również kosztuje tyle samo:

• projekt / projekt pierwszego ekranu wartość 48 800 RUR... Pierwszy ekran jest droższy, ponieważ definiuje dla całej aplikacji. Tworząc ją, musimy wziąć pod uwagę strukturę całej aplikacji;
• projektowanie / projektowanie innych ekranów – 18 350 RUB... dla każdego.

Zatem opracowanie prototypu (lub projektu) pięciu ekranów będzie kosztować 48 800 rubli + 18 350 rubli. x 4 \u003d 122 200 RUR

Orientacyjny koszt testów użyteczności wynosi 52 500 rubli. - 126000 rubli.

Duże projekty

Powyższy opis dotyczy małych projektów interfejsu oprogramowania. Duże projekty będzie przydatne do rozbicia na podzadaniai cykl dla każdego z nich. Na przykład, gdybyśmy opracowywali interfejs Skype, moglibyśmy wyróżnić następujące moduły:

• berło komunikacja głosowa;
• interfejs komunikacji wideo;
• zarządzanie listą kontaktów;
• itp.

Dla każdego z wymienionych modułów wskazane jest przejście przez wszystkie etapy , a następnie przejdź do następnego modułu. Ta metoda rozwoju nosi nazwę Zwinny (czytaj „zwinny”). Ta metodologia jest zwykle szanowana i wymieniana za każdym razem, gdy chcesz zaimponować klientom i pięknym dziewczynom :-)

Chciałbym udzielić prostej, ale paradoksalnej rady: nie wierz we wszystko, co mówią o projektowaniu.

Chodzi o to, że projektowanie w programowaniu stron internetowych, z wielu powodów historycznych, rozwinęło się za pomocą kikuta i nadal stanowi niejasną, słabo opisaną i mało zrozumiałą definicję. Sytuacja powoli się poprawia ostatnie lata, ale jest dużo pracy wyjaśniającej - dlatego każdy, kto chce zrozumieć projekt, musi się odwrócić i nie bać się kwestionować każdej pozornie powszechnej prawdy.

Takich „pospolitych” prawd jest wiele, a razem tworzą okropny i okropny zbiór mitów o designie - chciałbym dziś opowiedzieć o najważniejszych z nich.

Mit nr 1. Projektowanie to usługa dodatkowa

Projektant zaangażował się w ważny biznes pożytku publicznego

Wiele osób uważa, że \u200b\u200bfaza projektowania to dodatkowa usługa, którą można zaniedbać. To nie jest prawda.

Dlaczego tworzymy produkty IT? Jeśli mamy dobry umysł i dobrą pamięć, tworzymy je dla rozwiązywania problemów biznesowych (własnych lub naszych klientów - to nie jest takie ważne); Z kolei rozwiązanie tych zadań biznesowych polega na wykonywaniu zadań użytkownika przez tworzony produkt, biorąc pod uwagę uwarunkowania rynkowe, ograniczenia technologiczne i wszystko inne.

Aby produkt spełniał wszystkie warunki, konieczne jest zebranie razem wielu sprzecznych, niespecyficznych i trudnych do znalezienia informacji - porozmawiaj ze wszystkimi aktorami, przestudiuj towarzyszące procesy biznesowe, zapoznaj się z systemami zewnętrznymi, przyjrzyj się konkurentom itd., A zebrane informacje dobrze byłoby uchwycić i zebrać razem tak, aby wszyscy członkowie zespołu mieli równie dobre zrozumienie wkładu.

Co więcej, na podstawie zebranych informacji należy wymyślić produkt i wymyślić go w taki sposób, aby nie był sprzeczny z warunkami zadania, a wręcz przeciwnie, ułatwiał jego realizację - a taki produkt to złożony organizm, w którym wszystkie części są ze sobą połączone. Wynaleziony produkt ponownie musi zostać odpowiednio naprawiony, aby zarówno klient, jak i programista wiedzieli, co ostatecznie otrzymają (i mogli udoskonalić ten produkt w przyszłości).

Czy można zrobić coś złożonego i użytecznego produktu, omijając wszystkie te etapy? Zgadzam się: mało prawdopodobne. Tymczasem wszystkie opisane procesy stanowią tzw. Projektowanie - analizę (analizę warunków problemowych), syntezę (tworzenie produktu) i utrwalanie (sporządzenie prawidłowej dokumentacji projektowej).

Projekt nie może być usługi dodatkowe , ponieważ jest to istota tworzenia stron internetowych i ma na celu uzyskanie zrozumiałego wyniku, a nie opanowanie budżetów lub walkę o dobro ze złem.

Mit nr 2. Projekt jest drogi.

Kierownik projektu wybija budżet klienta

Istnieje opinia, że \u200b\u200bfaza projektowania tylko zwiększa koszt produktu.

W związku z tym z przyjemnością cytuję Karla Wiegersa, patriarchę inżynierii systemów, autora wspaniałej książki Development of Requirements for oprogramowanie„I po prostu mądra osoba.

Karl Wigers przeprowadził kiedyś badanie amerykańskiego rynku rozwoju IT i obliczył to średnio 40% budżetów rozwojowych jest marnowanych, a te pieniądze są tracone nie z winy nieuczciwych programistów lub złych klientów, ale po prostu dlatego, że dwie strony - klient i deweloper - po prostu nie mogli dojść między sobą.

Czterdzieści procent - i to dla Ameryki, gdzie panuje zupełnie inna relacja między klientem a deweloperem! Wydaje mi się, że w przypadku Rosji liczba ta jest jeszcze wyższa - 1,5 raza.

Jednocześnie poprawne zaprojektowanie systemu, według obliczeń tych samych Wigerów, zajmuje 15-20% budżetu na rozwój (a liczba ta w pełni potwierdza nasze doświadczenie).

Okazało się ciekawy efekt: wydajemy stałe 15-20% na projekt, ale jednocześnie minimalizujemy wydatki „marnotrawstwa” (te same 40% budżetu), które mogą potencjalnie pogrzebać projekt, a ponadto niezwykle opóźniamy czas uzyskania wykonalnego produktu.

Tak więc koszt poprawnego projektu paradoksalnie wpływa na koszt całego projektu jako całości: z jednej strony faza projektowania nie jest darmowa i pochłania określoną kwotę budżetu, ale z drugiej zmniejsza koszt całego projektu jako całości eliminując ryzyko związane ze źle przemyślanym i dlatego nieprzewidywalny produkt.

Mit numer 3. Projekt pisze TK

Słoń TK

Często słyszymy, że projektowanie to proces pisania specyfikacji technicznej, którą można dołączyć do umowy. To nie jest prawda.

Jak dowiedzieliśmy się podczas analizy poprzedniego mitu, projektowanie minimalizuje ryzyko rozwoju. Będziesz się śmiał, ale to jego jedyny i główny cel - wszystko inne harmonijnie wypływa z tego faktu:

• projekt pozwala uwzględniać interesy użytkowników (a tym samym minimalizować ryzyko rozwoju);
• projekt pozwala uwzględnić interesy klienta (a tym samym minimalizować ryzyko rozwojowe);
• projekt pozwala uwzględnić wszystkie istotne czynniki zewnętrzne (a tym samym zminimalizować ryzyko rozwoju);
• projekt pozwala stronom uzyskać ujednoliconą wizję produktu (a tym samym zminimalizować ryzyko rozwoju);
• projekt pozwala dokładnie przewidzieć czas i koszt rozwoju (a tym samym ... cóż, masz pomysł).

Pisanie TK - to tylko jedno z narzędzi, które pozwala jednoznacznie, dostatecznie, systematycznie i trwale ustalić wymagania dotyczące produktu w formacie zrozumiałym dla dewelopera. Tak, to narzędzie można nazwać najważniejszym, ale faza projektowania niesie ze sobą znacznie ważniejsze zadanie - i należy o tym pamiętać.

Mit 4. Projektowanie dotyczy interfejsów użytkownika.

Produkt z przemyślanym, przyjaznym dla użytkownika interfejsem

Z wielu powodów projektowanie na naszym (i nie tylko) rynku tworzenia stron internetowych jest silnie związane z interfejsami.

Rzeczywiście, interfejsy są najbardziej widoczną częścią produktu: to z nim będą się kontaktować użytkownicy, którzy będą wykonywać swoje zadania przy użyciu produktu, a tym samym przyczyniać się do realizacji zadań klienta.

Czy na tej podstawie interfejsy można uznać za jedyne wartościowe cele projektowe? Oczywiście, że nie: interfejs to tylko wierzchołek góry lodowej produktu, a jeśli mówimy o poprawnym projekcie, który naprawdę minimalizuje ryzyko rozwojowe, to musimy także poradzić sobie z tym, co dzieje się wewnątrz produktu: strukturą jego danych, logiką jego zachowania, połączeniami z zewnętrznymi systemy, interfejsy administracyjne i nie tylko.

Interfejs użytkownika to tylko jeden z elementów produktu, który zapewnia użytkownikom dostęp do funkcji i danych produktu. Zaprojektowanie go jest ważne, ale ograniczanie się tylko do niego jest szkodliwe.

Mit 5. Menedżer może również projektować

Menedżer zajęty aktywnością profilu

Jak już się przekonaliśmy, projektowanie to złożony proces związany z żmudną, delikatną pracą. Aby projekt spełniał swoje zadania, praca ta musi być wykonana tak wydajnie i starannie, jak to tylko możliwe. Innymi słowy, projektowanie wymaga od wykonawcy bardzo specyficznego systemu wartości, w którym jakość pracy i osobista odpowiedzialność będą nadrzędne.

Jednocześnie projektowanie często pozostaje w rękach menedżerów jako ludzi, którzy łączą wszystkie procesy i wątki rozwoju. Wydawałoby się, że wszystko jest logiczne i poprawne, ale nie jest brane pod uwagę ważny punkt: w dobrzy menedżerowie zupełnie inny system wartości, w którym czas realizacji projektu i jego budżet są na czele.

W dużych projektach, a zwłaszcza w rozwoju niestandardowym, jest to bardzo okrutny żart z menedżerami: jeśli menedżer stanie przed dylematem, rozwiąż problem związany z projektem jako całością (na przykład wyciągnięcie projektanta z obłędu to zresztą całkowicie prawdziwa historia) lub rozwiąż problem związane z projektowaniem (dokładniej zapisz protokół danych w specyfikacji technicznej), wtedy każdy kierownik wybierze rozwiązanie, które ugasi szalejące tu i teraz pożary. W rzeczywistości niedokończony TK wpłynie gdzieś w dłuższej perspektywie, ale projektowany pożar, który nie zostanie ugaszony na czas, doprowadzi w tej chwili do utraty projektu. I na koniec, jak możesz spokojnie pisać TK, skoro klienci nieustannie rozpraszają Cię drobiazgami?

I tak będzie przez cały czas rozwoju. Jeśli do tego aspektu wartości dodamy aspekt zawodowy (w końcu projektant musi umieć robić wiele rzeczy, o których menedżer nie musi wiedzieć), to łatwo jest zrozumieć, dlaczego w projektowanie miałaby angażować się osobna, specjalnie przeszkolona osoba z własnym systemem wartości.

Jedynym wyjątkiem od tej reguły jest rozwój wewnętrzny. W warunkach, gdy menedżer ma tylko jeden projekt, a problem terminowości i budżetów nie jest tak dotkliwy, menedżer może przejąć funkcje projektanta. To prawda, że \u200b\u200bw tym przypadku zostaje managerem produktu - a to osobna historia, która zasługuje na własny artykuł.

Mit 6. Projektowaniem powinni zajmować się psychologowie

Zawartość techniczna produktu według psychologa

Niektóre firmy - w tym te największe - uważają, że projekt powinni wykonać osoby z wykształceniem psychologicznym. Mit ten wyrasta z przekonania, że \u200b\u200bprojektant powinien być wyłącznie interesem użytkowników. Jak już się dowiedzieliśmy, tak nie jest - projektant zajmuje się całością produktu jako całością i bierze pod uwagę interesy zarówno użytkowników, jak i klienta, nie wspominając o specyfice systemu. Wszystko to wymaga umiejętności technicznych, których psychologom w większości brakuje.

Inna sprawa, że \u200b\u200bpsychologowie mogą być zaangażowani w wąską część projektu - pracę z interfejsami lub analizę preferencji użytkownika - ale wszystko to powinno odbywać się pod okiem projektanta produktu, który weźmie pod uwagę wszystkie techniczne subtelności i niuanse.

Mit 7. Projekt powinien być wykonany przez inżynierów.

W przeciwieństwie do mitu o psychologach istnieje mit o inżynierach - mówią, że projektant musi być programistą. Jak już chyba się domyślacie, jest to również zła opcja - sferyczny programista w próżni jest w stanie przemyśleć ogólną architekturę produktu, ale jest mało prawdopodobne, aby był w stanie dokładnie wyczuć użytkowników i zrozumieć wymagania klienta. Właściwie trafiłem na takich programistów, ale w ich sposobie myślenia byli raczej projektantami, którzy przez nieporozumienie zostali programistami.

Podobnie jak w przypadku poprzedniego mitu, programiści mogą brać udział w projektowaniu - ale tylko w zakresie struktury danych i opisy funkcjonalne produkt pod nadzorem projektanta (chociaż w razie potrzeby projektant musi to zrobić sam).

Kim jest projektant?

Kim powinni być projektanci? To bardzo trudne pytanie, na które mogę krótko odpowiedzieć w następujący sposób.

• Warto przyjąć do wiadomości, że „poprawnych” projektantów systemów nie uczy się jeszcze nigdzie.
• Najczęściej właściwy projektant rodzi się na styku konwencjonalnych nauk humanistycznych i technicznych.
• Najczęściej dobry projektant nie wie, że jest dobrym projektantem i pracuje w lewicowej specjalności, która go nie zadowala.
• Taki „nieaktywny” dobry projektant ma schizofreniczne osiągnięcia, zaplecze techniczne, szerokie spojrzenie i sposób myślenia dobrego klasycznego inżyniera.
• Projektant musi rozumieć projektantów, programistów, klientów i użytkowników.
• Projektant musi umieć komunikować się z ludźmi.

Moje osobiste doświadczenia pokazują, że projektant jest koncepcją raczej wrodzoną. mimożliwe jest stosunkowo szybkie nauczenie projektanta niezbędnych narzędzi i technik (poważnie, od trzech do sześciu miesięcy), ale zainwestuj w to żądany system wartości i sposób myślenia są prawie niemożliwe.

Ale są tacy ludzie - i to dla ich poszukiwań i formacji stworzyłem kiedyś Gildię Wolnych Projektantów i to też jest osobny temat do rozmowy.

Nie ma jednego podejścia projektowego

Projektant nie może znieść upału projektu

Istnieje wiele podejść do projektowania, a niedoświadczony czytelnik może łatwo oszaleć z powodu bogactwa technik, podejść i skrótów, hojnie doprawionych bałaganem terminologicznym (wszystkie te UX, UI, CX, HCD i inne IDDQD z zakrzywionymi rosyjskimi odpowiednikami).

Niektórzy próbują jednak wyprowadzić uniwersalne modele projektowe, ale w końcu okazuje się, że próbując połączyć istniejące 20 (warunkowo) podejść do projektowania, otrzymujemy 21 podejść - a metodologie, jak się wydaje, zaczynają się rozmnażać.

Eksperci konkludują na tej podstawie, że nie ma jednego podejścia do projektowania i nie może być - mówią, że wszystko jest ściśle indywidualne, dlatego nie ma co usystematyzować.

To także mit, którego osobiście absolutnie nie lubię. Istnieje wspólne podejście do projektowania, ale wymaga ono osobnej, obszernej i bardzo osobistej rozmowy; więc za Waszą zgodą obalimy ten mit nieco później - pod koniec września, kiedy w Cossie ukaże się mój długi artykuł na ten temat.

Zamiast zakończenia

Więc czego się dzisiaj dowiedzieliśmy?

• Projekt jest wart swojej ceny i pozwala zmniejszyć budżet na rozwój.
• Projekt minimalizuje ryzyko rozwoju.
• Wzornictwo działa na rzecz całości produktu.
• Projektanci powinni być zaangażowani w projektowanie (to prawda, co?).
• Projektowanie to duży i złożony proces, który ma swoje własne wzorce i wspólne podejścia.
• Nie wierz w to, co piszą o designie - nie bój się myśleć samodzielnie, przedstawiać swoje poglądy i bronić swojej wizji.

I ostatnia prośba: nie wierz mi na słowo - będę tylko zadowolony, jeśli nie zgodzisz się ze mną i nie bronisz swojego punktu widzenia: będzie to okazja do pożytecznej i wielkiej rozmowy, podczas której może pojawić się inna prawda - i czy to nie najlepiej?