Etapy projektowania interfejsu potrzeb użytkownika. Strach przed pustą kartką przy projektowaniu interfejsów

Wykład 14.

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

Interfejs użytkownika to zbiór modelu informacyjnego obszaru problemowego, środków i metod interakcji użytkownika z modelem informacyjnym, a także komponentów zapewniających tworzenie modelu informacyjnego podczas działania systemu oprogramowania (slajd 14.1) .

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

Środki i metody interakcji z modelem informacyjnym zależą od składu sprzętu i oprogramowania dostępnego użytkownikowi oraz od charakteru rozwiązywanego problemu. Wydajność użytkownika zależy nie tylko od funkcjonalności sprzętu i oprogramowania, którymi dysponuje, ale także od dostępności tych możliwości dla użytkownika. Z kolei pełne wykorzystanie potencjalnych możliwości dostępnych zasobów zależy od jakości interfejsu użytkownika.

Jakość interfejsu użytkownika jest niezależną cechą oprogramowania, porównywalną pod względem znaczenia do jego wskaźników, takich jak niezawodność i efektywne wykorzystanie zasobów obliczeniowych.

Według badań przeprowadzonych przez firmę Xerox i jej pracownika Davida Liddle'a, interfejs użytkownika składa się z następujących głównych elementów, przedstawionych w postaci góry lodowej.

Według tego badania interfejs składa się z trzech głównych części – prezentacji informacji użytkownikowi, interakcji i relacji między obiektami. Co więcej, „widzialna” część góry lodowej jest znacznie mniejsza niż jej „niewidzialna” ukryta część. (slajd 14.2). Wierzchołek góry lodowej – informacje dla użytkowników (kolor, animacja, dźwięk, kształt obiektów, rozmieszczenie informacji na ekranie, grafika) to tylko 10% i wcale nie jest to najważniejszy element 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 dno góry lodowej (60%) modelu projektanta – jego najważniejsza część – to właściwości obiektów i powiązania między nimi.

14.1. Podstawowe zasady projektowania interfejsu użytkownika

Główną zaletą dobrego interfejsu użytkownika jest to użytkownik zawsze ma wrażenie, że to on kontroluje oprogramowanie, a nie to oprogramowanie kontroluje jego.

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.

Przyjazny interfejs (Zasada „przebaczenia użytkownikowi”)

Zasada „sprzężenia zwrotnego”.

Prostota interfejsu.

Elastyczność interfejsu.

Estetyczny wygląd.

Naturalność interfejsu. Naturalny interfejs to taki, który nie zmusza użytkownika do istotnej zmiany dotychczasowych 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ę na nowe zadania, szybciej opanowywać nowe aspekty, a tym samym skupić się na zadaniu, zamiast tracić czas na zrozumienie różnic w stosowaniu poszczególnych elementów sterujących, poleceń itp. Zapewniając ciągłość wcześniej zdobytej wiedzy i umiejętności, spójność sprawia, że interfejs 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, należy wziąć pod uwagę różne jego aspekty.

Spójność w produkcie. Ten sam zespół musi wykonywać te same funkcje, gdziekolwiek się znajdzie i w ten sam sposób.

Spójność w środowisku pracy. Zachowując spójność z interfejsem udostępnianym przez system operacyjny (np. Windows), aplikacja użytkownika może „budować” na wiedzy i umiejętnościach użytkownika, które nabył on wcześniej podczas pracy z innymi aplikacjami.

Konsekwencja w użyciu metafor. Jeśli zachowanie obiektu oprogramowania wykracza poza to, co zwykle sugeruje jego metafora, użytkownik może mieć trudności z pracą z tym obiektem.

Przyjazność interfejsu użytkownika (zasada „przebaczenia użytkownikowi”). Użytkownicy zazwyczaj uczą się funkcji pracy z nowym oprogramowaniem metodą prób i błędów. Efektywny interfejs musi uwzględniać to podejście. Na każdym etapie działania powinien umożliwiać jedynie 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ść cofania lub korygowania wykonanych czynności.

Nawet przy dobrze zaprojektowanym interfejsie użytkownicy mogą popełnić pewne błędy. Błędy te mogą mieć charakter „fizyczny” (losowy wybór niewłaściwego polecenia lub danych) lub „logiczny” (podjęcie błędnej decyzji o wyborze polecenia lub danych). Skuteczny interfejs powinien być w stanie zapobiegać sytuacjom, które mogą skutkować błędami. Powinien także potrafić dostosowywać się do potencjalnych błędów użytkownika i ułatwiać mu eliminację konsekwencji takich błędów.

Zasada „sprzężenia zwrotnego”. Zawsze powinieneś przekazywać informacje zwrotne na temat działań użytkownika. Każde działanie użytkownika powinno otrzymać wizualne, a czasami dźwiękowe potwierdzenie, że oprogramowanie zaakceptowało wprowadzone polecenie; w takim przypadku rodzaj reakcji, jeśli to możliwe, powinien uwzględniać charakter wykonywanej czynności.

Informacja zwrotna jest skuteczna, jeśli zostanie wdrożona terminowo, tj. możliwie najbliżej miejsca ostatniej interakcji użytkownika z systemem. Gdy komputer przetwarza przychodzące zadanie, przydatne jest udostępnienie użytkownikowi informacji o stanie procesu, a także możliwości przerwania procesu w razie potrzeby. Nic bardziej nie dezorientuje mniej doświadczonego użytkownika niż zablokowany ekran, który nie reaguje na jego działania. Typowy użytkownik może wytrzymać jedynie kilka sekund oczekiwania na odpowiedź ze strony swojego elektronicznego „rozmówcy”.

Prostota interfejsu. Interfejs powinien być prosty. Nie oznacza to uproszczenia, ale zapewnienie łatwości nauki i użytkowania. Ponadto musi zapewniać dostęp do całej listy funkcjonalności udostępnianych przez tę aplikację. Zapewnienie dostępu do bogatej funkcjonalności i zapewnienie łatwości obsługi są ze sobą sprzeczne. Zaprojektowanie efektywnego 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 są minimalnie potrzebne użytkownikowi do wykonania kolejnego kroku zadania. W szczególności należy unikać pełnych nazw poleceń lub komunikatów. Złe lub zbędne wyrażenia utrudniają użytkownikowi wydobycie odpowiednich informacji.

Innym sposobem na stworzenie prostego, ale efektownego interfejsu jest rozmieszczenie i prezentacja elementów na ekranie, z uwzględnieniem ich znaczenia semantycznego i logicznego powiązania. Pozwala to na wykorzystanie myślenia skojarzeniowego użytkownika podczas procesu pracy.

Innym sposobem kontrolowania złożoności wyświetlanych informacji jest użycie otwieranie sekwencyjne (okna dialogowe, sekcje menu itp.). Ujawnianie sekwencyjne polega na takim uporządkowaniu informacji, aby w danym momencie na ekranie znajdowała się tylko ta część, która jest niezbędna do wykonania kolejnego kroku. Zmniejszając ilość informacji prezentowanych użytkownikowi, zmniejsza się 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 wyższego poziomu.

Jedną z metodologicznych podstaw organizacji zarządzania procesem przetwarzania jest stosowanie „metafor” - znaczących analogii docelowego przetwarzania danych, ale w obszarach bardziej powszechnych dla człowieka niż automatyzacja.

Na przykład metafora „pulpitu” sugeruje, że interfejs zapewnia użytkownikowi dostęp do wielu różnych źródeł informacji i pozwala mu łatwo przełączać się z jednego źródła na drugie (tj. „przerzucanie papierów po biurku”), zmieniając jeden rodzaj zadanie (arkusz kalkulacyjny itp.) na inne (system przygotowywania tekstu). Jednocześnie użytkownik ma dostęp do wszelkich innych narzędzi, w tym pomocniczych (kalkulator, zegarek itp.).

Użytkownik może przenosić informacje z jednego dokumentu do drugiego, wstawiając odpowiednie fragmenty jednego dokumentu w odpowiednie miejsca w innym dokumencie. Wiąże się to z inną metaforą, „buforem przycinającym”. Przed pojawieniem się automatycznych systemów przetwarzania tekstu istniał tradycyjny sposób na ułatwienie układu: wklejanie wyciętego fragmentu zamiast ponownego wpisywania strony. Interfejsy WIMP zapewniają podobne możliwości wycinania i wklejania, ale bufor, w którym umieszczane jest wycięcie, umożliwia wklejenie dowolnej liczby kopii elementów danych.

Zasada metaforyczna leży także u podstaw technologii WISIWIG – natychmiastowej wizualizacji wyników działań na ekranie. Oznacza to, że ekran powinien imitować sposób druku, a jeśli użytkownik chce wydrukować część tekstu kursywą, to musi to wpisać 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 przekazuje użytkownikowi informację o stanie obiektu, potwierdzając wykonanie akcji. Można powiedzieć, że ta metafora dokładniej odpowiada formule „ Widzisz, co uzyskałeś w wyniku swoich działań.”.

Elastyczność interfejsu. Elastyczność interfejsu to jego zdolność do uwzględnienia poziomu umiejętności i produktywności użytkownika. Właściwość elastyczności oznacza możliwość zmiany struktury dialogu i/lub danych wejściowych. Elastyczna koncepcja (adaptacyjny) interfejs jest obecnie jednym z głównych obszarów badań nad interakcją człowiek-komputer. Głównym problemem nie jest to, jak zorganizować zmiany w dialogu, ale jakie znaki należy zastosować, aby określić potrzebę zmian i ich istotę.

Estetyczny wygląd. Prawidłowa reprezentacja wizualna 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 wiemy nie jest nieograniczona.

Jakość interfejsu trudno ocenić ilościowo, ale mniej lub bardziej obiektywną ocenę można uzyskać na podstawie konkretnych wskaźników podanych poniżej.

Czas potrzebny konkretnemu użytkownikowi na osiągnięcie danego poziomu wiedzy i umiejętności w pracy z aplikacją.

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

Szybkość rozwiązywania problemu za pomocą tej aplikacji; W tym przypadku nie należy oceniać szybkości działania systemu czy szybkości wprowadzania danych z klawiatury, ale czas potrzebny do osiągnięcia celu, jakim jest rozwiązywany problem. Na tej podstawie można sformułować kryterium oceny tego wskaźnika np. w następujący sposób: użytkownik musi w ciągu godziny przetworzyć co najmniej 20 dokumentów z błędem nie większym niż 1%.

Subiektywna satysfakcja użytkownika z pracy z systemem (którą można wyrazić ilościowo w procentach lub jako ocena w n-punktowej skali).

Na tym etapie zbierane i analizowane są dane użytkowników, formalizowana jest funkcjonalność i ustalane są obiektywne kryteria sukcesu projektu.

Formalizacja kontekstu użycia

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 konkurencyjnych systemów

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

Formalizacja kontekstu użycia

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

Charakterystyka użytkowników: ich doświadczenie z komputerami, wiedza z danej dziedziny, motywy, wielkość/znaczenie grup użytkowników, wzorce (typowe sytuacje) użytkowania;

Cele i zadania użytkowników;

Cele projektu: jaki był powód powstania projektu, etapy tworzenia projektu, jakie wyniki należy uzyskać, jakie informacje są potrzebne i kiedy;

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

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

Na wejściu: dostęp do istniejących i potencjalnych użytkowników systemu, ekspertów oraz dokumentacji projektowej.

Wynik: opis kontekstu użycia systemu, ewentualnie bardziej szczegółowy opis właściwości użytkownika.

w górę do treści

Formalizacja obiektywnych kryteriów sukcesu.

Na tym etapie identyfikowane są obiektywne kryteria oceny ergonomii interfejsu, takie jak wskaźniki wydajności, produktywności, satysfakcji użytkownika (na wcześniejszych etapach nie da się zidentyfikować tych kryteriów).

W związku z tym na tym etapie powstaje prawdziwe zadanie zaprojektowania interfejsu. Na przykład:

Skład grupy użytkowników stale się zmienia, a schemat zamierzonego użycia jest stosowany rzadko. Należy skupić się na łatwości zrozumienia interfejsu.

To samo zadanie powtarza się wiele razy, a grupa użytkowników jest dość duża. Należy skupić się na efektywności użytkowania.

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

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

Wynik: lista obiektywnych kryteriów sukcesu.

w górę do treści

Analiza celu

Programista musi jasno zrozumieć, że użytkownicy nie potrzebują samych narzędzi, a jedynie wyników swojej pracy. Nikt nie potrzebuje edytora tekstu - potrzebna jest mu możliwość wygodnego pisania tekstów. Nikt nie potrzebuje programu do obróbki obrazu – potrzebne są już przetworzone obrazy. Oznacza to, że same funkcje nie są ani potrzebne, ani ważne. Ludzie w ogóle potrzebują środków, które umożliwią wykonanie dowolnej pracy.

Różnicę w podejściu do wyboru funkcjonalności wygodnie jest zilustrować na przykładzie tostera. Podejście standardowe, w którym funkcje są dobierane praktycznie dowolnie, w najlepszym przypadku doprowadzi do następującego zadania: „Potrzebujesz pudełka z wąskim prostokątnym otworem i grzejnikiem w środku”.. Analiza celów użytkownika doprowadzi do innego sformułowania: „Potrzebujemy chleba tostowego. Wydaje się, że najłatwiej to osiągnąć, tworząc pudełko z otworem w kształcie kawałka chleba i grzałką w środku. Z drugiej strony wydaje się, że ta metoda nie jest jedyna.”. Opcja druga, przy pełnym rozwinięciu tej metody, może doprowadzić do powstania nie tylko tostera, ale także brytfanny (czyli urządzenia, w którym można opiekać nie tylko chleb).

Wynikiem tego procesu powinna być lista celów, np. w przypadku tostera ostateczna lista celów powinna wyglądać bardzo prosto: „Muszę smażyć małe kawałki jedzenia, głównie chleb”..

Wynik: zalecenia dotyczące optymalizacji interfejsu, lista udanych i nieudanych rozwiązań interfejsu (nacisk położony jest na nieudane rozwiązania). Jeżeli na tym etapie przeprowadzono badania użyteczności aktualnej wersji, raport zawiera krótkie protokoły oraz listę wyników badań.

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

Wynik: lista celów wprowadzenia nowego interfejsu z charakterystyką wagową każdego z nich.

w górę do treści

Formalizacja 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ż w ramach jednej roli nie zaleca się uwzględniania funkcji z innej roli w nawigacji. Odpowiednio na tym etapie identyfikowane są główne role użytkowników wraz z funkcjami związanymi z tymi rolami. Również na tym etapie przeprowadza się wywiady z każdym z przedstawicieli danej roli, aby zidentyfikować cechy tej roli i dowiedzieć się, 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, czyli systemu konkurentów (jeśli występują) i obiektów ś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 wynik pracy jest praktycznie niezależny od użytego narzędzia, oznacza to, że jedynie funkcjonalność, która miała potrzebny jest wpływ na wynik (tzn. funkcje, których nikt nie używał, nie są potrzebne).

Zwykle istnieje kilka różnych sposobów implementacji tej samej funkcji. Analiza działań użytkowników pozwala określić, która metoda powinna zostać wdrożona. Ponieważ na tym etapie dowiadujemy się dokładnie, jaka funkcjonalność jest potrzebna dla każdej roli biznesowej, możemy wybrać właściwą ścieżkę w myśl zasady „im mniej działań wymaga od użytkownika, tym lepiej”.

Wynik: opis ról biznesowych użytkowników.

w górę do treści

Formalizacja funkcjonalności

Na tym etapie, w oparciu o informacje wygenerowane we wcześniejszych etapach, ostatecznie tworzona jest lista możliwości funkcjonalnych nowej wersji systemu. Wcześniej wygenerowane specyfikacje techniczne czasami nie zawierają części wymaganej funkcjonalności lub zawierają funkcjonalność, która tak naprawdę nie jest wymagana 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 (zwykle nie tworzy się raportu z realizacji tego etapu prac, zamiast tego unowocześnia się już utworzoną specyfikację techniczną).

w górę do treści

Formalizacja scenariuszy działań użytkownika

Na tym etapie częściowo bada się i częściowo opracowuje typowe scenariusze działań użytkownika: sformalizowane są dane niezbędne użytkownikom do wykonania pracy, kolejność samej pracy oraz kryteria ukończenia tej pracy.

Celem tego etapu jest napisanie słownego opisu interakcji użytkownika z systemem, nie precyzując dokładnie, jak przebiega interakcja, ale zwracając jak największą uwagę na wszystkie cele użytkownika. Liczba scenariuszy może być dowolna, najważniejsze jest to, że muszą obejmować wszystkie rodzaje zadań stojących przed systemem i być nieco realistyczne. Scenariusze można łatwo rozpoznać po imionach występujących w nich fikcyjnych postaci.

Załóżmy, że musisz opracować skrypty dla przyszłego programu pocztowego. Najwyraźniej do tego zadania potrzebne są trzy scenariusze:

Elizaveta Petrovna uruchamia program pocztowy. Obejmuje proces pobierania nowej poczty. Po otrzymaniu 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 nowej poczty. Otrzymawszy wiadomość, czyta ją. Przekazuje jedną wiadomość innemu odbiorcy, po czym ją usuwa i drukuje kolejną. Następnie przechodzi do innego zadania.

Nadeszła nowa wiadomość, a 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.

Skrypty te mają podwójną wartość. Po pierwsze, przydadzą się do późniejszych testów, gdyż testowane jest nie wykonanie abstrakcyjnych zadań, a wykonanie konkretnych operacji uwzględnionych w tych scenariuszach. Po drugie, sam fakt ich napisania zwykle, choć nie zawsze, prowadzi do lepszego zrozumienia konstrukcji projektowanego systemu, co skłania do natychmiastowej optymalizacji przyszłej interakcji. W takich scenariuszach niepotrzebne kroki są bardzo 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ą i dopiero potem przeczytać. Oczywiste jest, że te niepotrzebne kroki można bezpiecznie wyeliminować na 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 użytkownika (opracowane scenariusze przedstawiane są zazwyczaj w formie schematów blokowych opisujących cały proces wykorzystania systemu do realizacji określonego zadania).

w górę do treści

Przegląd interfejsu konkurencyjnych systemów

Większość odbiorców dowolnego systemu ma umiejętności korzystania z kilku konkurencyjnych systemów; jeśli opracowywany interfejs będzie zupełnie inny niż u konkurencji, użytkownicy będą musieli się uczyć na nowo. Ponadto konkurencyjne systemy często zawierają skuteczne rozwiązania, które warto zastosować (lub częściej uwzględnić przy projektowaniu interfejsu).

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

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

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

w górę do treści

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

Na tym etapie badane są subiektywne oczekiwania użytkowników wobec systemu. Bez tych badań trudne lub niemożliwe jest przewidzenie postaw użytkowników wobec przyszłego systemu.

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

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

Podstawowe wymagania stawiane interfejsowi WWW zostały sformułowane przez Jakoba Nielsena w formie, która nie straciła na aktualności od roku 1990, kiedy to zostały po raz pierwszy opublikowane. Następnie lista ta została sfinalizowana, rozszerzona, sformalizowana i stała się podstawą

Heurystyka i standard opisują zasady, które mają zastosowanie przy projektowaniu i rozwoju zdecydowanej większości interfejsów. Są proste, zrozumiałe i logiczne do tego stopnia, że na ich podstawie ukształtowały się już wzorce zachowań – użytkownicy są bardziej przyzwyczajeni i wygodniejsi do interakcji z interfejsami zaprojektowanymi zgodnie z ogólnymi zasadami i jasnymi standardami.

5 etapów tworzenia interfejsu

W zależności od potrzeb Klienta i stopnia gotowości projektu możemy zaprojektować:

logika – jak system rozwiązuje problemy użytkownika, podstawowy poziom, od którego zaczyna się praca projektanta,
funkcjonalność – w jaki sposób człowiek wchodzi w interakcję z interfejsem użytkownika serwisu, co dokładnie, w jakiej kolejności i przy użyciu jakich środków technicznych to robi, jak różne części systemu współdziałają ze sobą,
reprezentacja graficzna - wizualizacja projektu: układ bloków, kolorystyka i inne rozwiązania projektowe, wykorzystanie grafiki do kontrolowania uwagi.

Niezależnie od tego, czy interfejs serwisu powstaje od podstaw pod nowy projekt, czy jest przeprojektowywany pod istniejący system, identyfikowane są standardowe etapy, według których formowane są zadania i sprinty dla specjalistów.

Analiza

W celu gromadzenia, badania i analizy wszystkich informacji niezbędnych do stworzenia interfejsu internetowego:

Potrzeby biznesowe: po co powstaje projekt, jakie problemy biznesowe powinien rozwiązać, w jaki sposób będzie on monetyzowany w przyszłości.
Potrzeby odbiorców: dlaczego odbiorcy potrzebują projektu, czego dokładnie chcą użytkownicy, jakie dokładnie ich problemy i bóle rozwiązuje projekt.
Podstawowe cechy i unikalne zalety projektu na poziomie pomysłu: dlaczego ten konkretny projekt może rozwiązać problem lepiej niż konkurenci, co jest do tego potrzebne.
Punkty styku: tam, gdzie krzyżują się interesy odbiorców i biznesu – szukamy czynników pozwalających stworzyć optymalne scenariusze użytkownika.

Co dokładnie studiujemy:

biznes – zaczynając od oferty, a kończąc na cechach pracy z klientami w tej konkretnej niszy,
użytkownicy – rysujemy portrety klientów, analizujemy typowe wzorce i scenariusze zachowań,
konkurenci – jakie rozwiązania są już na rynku, dlaczego wyglądają tak, jak wyglądają,
projekt oryginalny – jeśli interfejs tworzony jest dla już istniejącego projektu, analityka może dostarczyć wielu przydatnych informacji.

Głównym zadaniem jest zebranie w jednym dokumencie wszystkich dostępnych informacji na stronie, przetworzenie ich i ostatecznie podjęcie decyzji, gdzie dokładnie i jak się poruszać w dalszej pracy.

Wydajność

Formułujemy koncepcję przyszłego projektu, zastanawiamy się i tworzymy historie użytkowników.
Opracowujemy architekturę informacji i ustalamy funkcjonalność systemu.
Przemyślamy scenariusze użytkownika i cechy interakcji użytkownika z interfejsem.

Na tym etapie powstaje szkielet interfejsu oraz ustalane są zasady i reguły wewnętrznego działania systemu oraz jego interakcji z użytkownikami. W rzeczywistości jest to najważniejszy etap projektowania, ponieważ tutaj ustalana jest podstawowa logika projektu.

Błędy i niedociągnięcia popełniane na tym etapie mnożą się wykładniczo w miarę kontynuowania dalszych prac nad projektem – a ich wyeliminowanie w gotowym produkcie często jest albo w zasadzie niemożliwe, albo nieracjonalnie kosztowne.

Prototypowanie

Bezpośrednie stworzenie prototypu interfejsu strony internetowej, jego renderowanie w Axure, edytorze graficznym lub dowolnym innym programie. Na tym etapie potrzebne są już pomysły i rozwiązania

Zwykle dla jednego interfejsu opracowywanych jest kilka równoważnych wersji. Podczas testów A/B, na podstawie wyników wywiadów i ankiet internetowych, wybierane są rozwiązania, które są bardziej spójne z celami biznesowymi i potrzebami odbiorców.

W rezultacie niedziałające pomysły są odrzucane i pozostają tylko te, które przeszły próbę publiczności. Już na tym etapie staje się jasne, jak punkty styku ustalone w trakcie analizy przedprojektowej odpowiadają rzeczywistości.

Złe wieści: Być może będziesz musiał wrócić do początku i przeprowadzić więcej badań.

Dobre wieści: Jeśli na tym etapie znajdziesz i usuniesz wady, nie będziesz musiał ich poprawiać w gotowym produkcie, co kosztuje o rząd wielkości więcej.

Projektowanie i rozwój

Na podstawie wyników badań użyteczności oraz na podstawie zatwierdzonego z klientem prototypu tworzony jest projekt graficzny interfejsu. Na tym samym etapie rozwijana jest funkcjonalność i backend projektu.

W zależności od specyfiki projektu projekt strony internetowej przechodzi kilka iteracji zmian: z jednej strony korekty wprowadza właściciel projektu – bezpośredni klient, z drugiej – wszystkie teorie i pomysły są nadal testowane i weryfikowane przy zaangażowaniu przedstawicieli grupy docelowej – przyszłych realnych użytkowników – jako respondentów.

Na tym etapie powstaje gotowy produkt – interfejs w takiej formie, w jakiej użytkownicy będą z nim wchodzić w interakcję po wydaniu. W większości przypadków po zakończeniu tego etapu podpisywane są protokoły odbioru, a pliki i prawa do korzystania z produktu przekazywane są klientowi. Jeśli jednak podejdziesz do procesu odpowiedzialnie i zgodnie ze wszystkimi zasadami, to na tym praca nad zaprojektowaniem interfejsu się nie zakończy.

Analityka

Gotowy produkt po wypuszczeniu na rynek przechodzi najważniejszy test – w świecie rzeczywistym. Użytkownicy z reguły wchodzą w interakcję z interfejsem w sposób naturalny – nie ogranicza ich zakres badania, nie wywiera na nich presji konieczność sporządzenia raportu z wyników testów, nie zastanawiają się nad tym, jak one wyglądają w oczach organizatora badania.

Interakcja człowieka z interfejsem serwisu w warunkach bojowych pozwala zrozumieć, czy jest to proste, czy złożone, które scenariusze przebiegają zgodnie z planem, a które różnią się od planowanych, co idzie łatwo, a w czym utkną użytkownicy.

Analityka internetowa pozwala nam ocenić, na ile udało nam się rozwiązać zadania, które zostały postawione na etapach analityki przedprojektowej i prezentacji. A to daje powód do ulepszenia interfejsu i uczynienia go jeszcze bardziej przyjaznym dla użytkownika.

Wnioski końcowe

Podstawowe zasady projektowania interfejsów opisane są w heurystyce Nielsena oraz w normie ISO 9241-110.
Projektowanie odbywa się na trzech poziomach: logika, funkcjonalność, reprezentacja graficzna.
Proces można podzielić na 5 etapów: analiza przedprojektowa, prezentacja, prototypowanie, projektowanie i rozwój, analityka.
Testowanie i walidacja pomysłów, teorii i rozwiązań jest procesem ciągłym i zaczyna się od momentu, w którym mamy pierwsze szkice i prototypy.
Gotowy interfejs testowany jest zarówno przy udziale respondentów, jak i przy pomocy analityki internetowej na rzeczywistych użytkownikach – na podstawie wyników testów generowana jest specyfikacja techniczna w celu jego późniejszego udoskonalenia.

Jeśli nadal masz pytania dotyczące etapów projektowania i tworzenia interfejsów stron internetowych, zadaj je w komentarzach, na pewno odpowiemy.

Rozwój interfejsu użytkownika (UI) odbywa się równolegle z rozwojem oprogramowania jako całości i zazwyczaj poprzedza jego wdrożenie. Proces tworzenia ergonomicznego interfejsu użytkownika dzieli się na następujące etapy:

1. Opis problemu.

Na tym etapie zbierane i analizowane są dane użytkowników, formalizowana jest funkcjonalność i ustalane są obiektywne kryteria sukcesu projektu.

Formalizacja kontekstu użycia

Opisano następujące właściwości odbiorców systemowych:

Charakterystyka użytkowników: ich doświadczenie z komputerami, wiedza z danej dziedziny, motywy, wielkość/znaczenie grup użytkowników, wzorce (typowe sytuacje) użytkowania;

Cele i zadania użytkowników;

Cele projektu: jaki był powód powstania projektu, etapy tworzenia projektu, jakie wyniki należy uzyskać, jakie informacje są potrzebne i kiedy;

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

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

Formalizacja obiektywnych kryteriów sukcesu.

Identyfikuje się obiektywne kryteria oceny ergonomii interfejsu, takie jak wskaźniki wydajności, produktywności i satysfakcji użytkownika (nie da się tych kryteriów zidentyfikować na wcześniejszych etapach).

Analiza celu

Programista musi jasno zrozumieć, że użytkownicy nie potrzebują samych narzędzi, a jedynie wyników swojej pracy.

Nikt nie potrzebuje edytora tekstu - potrzebna jest mu możliwość wygodnego pisania tekstów. Nikt nie potrzebuje programu do obróbki obrazu – potrzebne są już przetworzone obrazy. Oznacza to, że same funkcje nie są ani potrzebne, ani ważne. Ludzie w ogóle potrzebują środków, które umożliwią wykonanie dowolnej pracy.

Formalizacja ról biznesowych użytkowników

Formalizacja scenariuszy działań użytkownika

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

Celem tego etapu jest napisanie słownego opisu interakcji użytkownika z systemem, nie precyzując dokładnie, jak przebiega interakcja, ale zwracając jak największą uwagę na 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ć nieco realistyczne. Scenariusze można łatwo rozpoznać po imionach występujących w nich fikcyjnych postaci.

Przegląd interfejsu konkurencyjnych systemów

2. Projekt na wysokim poziomie

Na tym etapie rozpoczyna się właściwe projektowanie interfejsu; poprzednie etapy poświęcone są wyłącznie zbieraniu danych i formułowaniu problemu.

Projektowanie struktury ekranów systemowych

Na tym etapie w oparciu o scenariusze pracy i role użytkowników tworzona jest struktura ekranów systemu, tj. określa się liczbę ekranów, funkcjonalność każdego z nich, powiązania nawigacyjne między nimi, kształtuje się strukturę menu i innych elementów nawigacyjnych.

Zasadniczo na tym etapie identyfikowane są poszczególne bloki funkcjonalne. Przez bloki funkcjonalne rozumiemy funkcję lub grupę funkcji powiązanych celem lub zakresem w przypadku programu oraz grupę funkcji/elementów treści w przypadku strony internetowej.

Istnieją trzy główne typy komunikacji pomiędzy blokami. Są to połączenie logiczne, połączenie percepcji użytkownika i połączenie proceduralne.

Połączenie logiczne. Połączenie logiczne definiuje interakcję pomiędzy fragmentami systemu z punktu widzenia programisty. Powstałe połączenia mają bardzo istotny wpływ na nawigację w systemie (szczególnie gdy system jest wielookienkowy). Dlatego, aby nie przeciążać interfejsu, należy unikać zarówno bloków zbyt pojedynczych (trudno je znaleźć), jak i bloków powiązanych z dużą liczbą innych.

Komunikacja poprzez przesłanie użytkownika. Użytkownicy mają własne zdanie na temat systemu i ta opinia jest również ważną formą komunikacji. W systemach informatycznych, gdy konieczne jest, aby użytkownik znalazł wszystkie potrzebne mu informacje, konieczne jest ustanowienie połączeń między blokami w oparciu nie tylko o punkt widzenia programisty, ale także o poglądy użytkowników. Faktem jest, że najpopularniejsza metoda wyszukiwania, czyli wyszukiwanie według klasyfikacji cech, działa tylko wtedy, gdy użytkownicy zgadzają się z zasadami tej klasyfikacji. Większości pojęć nie da się jednoznacznie sklasyfikować ze względu na obecność zbyt wielu istotnych cech. Problemem jest także to, że faktyczne kryterium klasyfikacji może różnić się od powszechnie przyjętego. Na przykład pomidor, który wszyscy uważają za warzywo, w rzeczywistości jest jagodą. Nie mniej trudno rozpoznać arbuza jako jagodę. Oznacza to, że klasyfikacja akceptowalna przez botanika nie sprawdzi się u wszystkich innych i nie mniej prawdziwa jest sytuacja odwrotna.

Jest wyjście z tej sytuacji. Istnieje prosty sposób klasyfikacji – metoda sortowania kart. Wszystkie pojęcia wymagające sklasyfikowania są spisane na kartkach w oparciu o zasadę „jedno pojęcie – jedna karta”. Następnie grupa użytkowników z grupy docelowej jest proszona o posortowanie tych kart (w tym przypadku każdy badany otrzymuje swój własny zestaw kart). Powstałe stosy kart należy rozłożyć na części, a wyniki z różnych przedmiotów połączyć w jedną metodę klasyfikacji.

Połączenie proceduralne. Połączenie proceduralne opisuje interakcję, która nie jest całkowicie logiczna, ale naturalna dla istniejącego procesu.

Nawiązanie wysokiej jakości połączenia proceduralnego jest zwykle zadaniem dość trudnym, gdyż jedynym źródłem informacji jest obserwacja użytkownika. Jednocześnie nawiązanie takiego połączenia jest niezwykle przydatne. Po co np. rysować na ekranie skomplikowany system nawigacji, skoro wiadomo dokładnie, do którego bloku następnie przejdzie użytkownik? W tym sensie często uzasadnione jest narzucenie użytkownikowi pewnego rodzaju powiązania proceduralnego, rezygnując z wygody, ale zyskując na szybkości uczenia się (ponieważ użytkownik musi mniej myśleć). Połączenie zakodowane na stałe pomaga również zmniejszyć liczbę błędów. Klasycznym przykładem zakodowanego na stałe przepływu pracy jest urządzenie kreatora, które zmusza użytkownika do kliknięcia Dalej.

Projekt systemu nawigacji

W oparciu o wcześniej opracowaną strukturę ekranu, na tym etapie wybierany jest najodpowiedniejszy system nawigacji i opracowywany jest jego szczegółowy interfejs.

System nawigacji pokazuje mechanizm podziału funkcji i zadań pomiędzy oknami programu. System nawigacji określa, w jaki sposób użytkownicy mogą nawigować zarówno pomiędzy różnymi zadaniami, jak i w ramach jednego zadania. Na przykład, czy możliwe będzie opuszczenie częściowo zakończonego zadania i rozpoczęcie innego.

Projektowanie struktury systemu pomocy

Trwa opracowywanie systemu pomocy (na tym etapie znane są już wszystkie informacje niezbędne do opracowania struktury systemu pomocy, który nie tylko opisuje interfejs, ale także pomaga użytkownikowi w rozwiązywaniu jego problemów).

3. Projekt niskiego poziomu

Trwają prace nad interfejsami dla poszczególnych ekranów systemu (kompozycja, położenie względne i elementy interfejsu obsługujące tekst).

Projektowanie ekranów głównych

Na tym etapie trwają prace nad interfejsami głównych ekranów systemu.

Testowanie

W oparciu o obiektywne kryteria powodzenia interfejsu i scenariusze działań użytkownika opracowywane są zadania testowe, które wykonują użytkownicy, rejestrując wszystkie istotne cechy działania (takie jak wydajność pracy, liczba błędów ludzkich). Następnie obliczane są odpowiednie wskaźniki i porównywane z określonymi. Na podstawie otrzymanych danych interfejs zostaje albo ukończony, albo uznany za opracowany.

Projektowanie ekranów wtórnych

Na tym etapie opracowywane są interfejsy dla ekranów systemów wtórnych. Należą do nich okna dialogowe i różne komunikaty.

Testy końcowe

W oparciu o obiektywne kryteria powodzenia interfejsu i scenariusze działań użytkownika, pozostałe zadania testowe są opracowywane i wykonywane przez użytkowników, rejestrując wszystkie istotne cechy ich działań. Następnie obliczane są odpowiednie wskaźniki i porównywane z określonymi. Na podstawie otrzymanych danych interfejs zostaje albo ukończony, albo uznany za opracowany.

Najbardziej znane języki projektowania na rok 2010:

VHDL (angielski VHSIC (bardzo szybkie układy scalone) sprzętowy język opisu) to język opisujący wyposażenie szybkich układów scalonych. Język projektowania VHDL jest podstawowym językiem projektowania sprzętu dla nowoczesnych systemów komputerowych.

Został opracowany w 1983 roku na zlecenie Departamentu Obrony Stanów Zjednoczonych w celu formalnego opisu obwodów logicznych na wszystkich etapach rozwoju systemów elektronicznych, od modułów mikroukładów po duże systemy obliczeniowe.

Verilog to język opisu sprzętu używany do opisu i modelowania systemów elektronicznych. Język ten (znany również jako Verilog HDL) umożliwia projektowanie, weryfikację i implementację (np. w postaci VLSI) analogowych, cyfrowych i mieszanych systemów elektronicznych na różnych poziomach abstrakcji SystemC - język do projektowania i weryfikacji na poziomie systemowym modele, zaimplementowane jako biblioteka C+ z otwartym kodem źródłowym. Biblioteka zawiera jądro modelowania zdarzeń, które pozwala uzyskać wykonywalny model urządzenia. Język ten służy do budowania modeli transakcyjnych i behawioralnych, a także do syntezy wysokiego poziomu. SMOK (Przyjazny rosyjski język algorytmiczny, który

Zapewnia widoczność) to wizualny język algorytmiczny stworzony w ramach programu kosmicznego Buran. Rozwój tego języka rozpoczął się w 1986 roku pod przewodnictwem Władimira Paronjanowa. Rosyjska Agencja Kosmiczna (NPC Automatyki i Oprzyrządowania nazwany na cześć akademika N.A. Pilyugina, Moskwa) oraz

Rosyjska Akademia Nauk (Instytut Matematyki Stosowanej im. Akademika M.V. Keldysha).

Jednym z zadań postawionych przed twórcami było stworzenie jednego uniwersalnego języka, który miał zastąpić języki specjalistyczne PROL2 (do tworzenia zintegrowanych na pokładzie programów Buran), DIPOL (do tworzenia programów naziemnych Buran) i LAX (do tworzenia programów naziemnych Buran). do modelowania).

Prace nad rozwojem języka zakończono w 1996 roku. (3 lata po zamknięciu programu Buran), kiedy to stworzono zautomatyzowaną technologię projektowania systemów oprogramowania (technologia CASE).

Język DRAKON można z powodzeniem wykorzystać do określenia protokołów interakcji (np. klient-serwer). UML (skrót od Unified Modeling Language) to graficzny język opisu służący do modelowania obiektów w dziedzinie tworzenia oprogramowania. UML to język ogólny, otwarty standard, który wykorzystuje notację graficzną do tworzenia abstrakcyjnego modelu systemu, zwanego modelem UML. UML został stworzony, aby definiować, wizualizować, projektować i dokumentować przede wszystkim systemy oprogramowania.

Wniosek

Ważne jest, aby zrozumieć, że użytkownikami i konsumentami informacji są ludzie i urządzenia techniczne. Ludzie, jako użytkownicy informacji, to osoby, grupy osób lub organizacje korzystające z usług systemu informacyjnego w celu uzyskania potrzebnych im informacji. Ci z nich, którzy nie pracują bezpośrednio z systemem, ale wykorzystują wyniki jego funkcjonowania, nazywani są użytkownikami końcowymi.

Podczas interakcji z programami komputerowymi użytkownicy sprawiają wrażenie, jakby z nimi rozmawiali (prowadzili dialog). Realizowany jest za pomocą zestawu okien, formularzy, menu, aktywnych przycisków, ikon, systemów pomocy itp. Razem tworzą interfejs programu – wygląd jego poszczególnych elementów i widoków na ekranie komputera.

Najważniejszym zadaniem interfejsu jest wytworzenie takiej samej reakcji użytkownika na te same działania aplikacji, ich spójność. Interfejs ten nazywany jest interfejsem użytkownika. W technologii informacyjnej interfejs użytkownika lub interfejs użytkownika to elementy i komponenty programu, które wpływają na interakcję użytkownika z oprogramowaniem.

Do efektywnego funkcjonowania systemu informacyjnego niezbędny jest efektywny interfejs użytkownika, który posiada szereg właściwości (naturalność, spójność, przyjazność, odwracalność, prostota, elastyczność, estetyka) i spełnia wymagane kryteria jakościowe.

Interfejs użytkownika utożsamiany jest zazwyczaj z dialogiem pomiędzy dwojgiem ludzi. Dialog (dialog człowiek-maszyna) reprezentuje sekwencję żądań użytkownika, odpowiedzi komputera na nie i odwrotnie. Interfejs użytkownika jest realizowany przez system operacyjny i inne oprogramowanie.

Interfejs użytkownika obejmuje także programy szkoleniowe, materiały referencyjne, możliwość dostosowania wyglądu programów i zawartości menu do potrzeb użytkowników (indywidualne ustawienia) oraz inne usługi. Obejmuje to również projekt, wskazówki krok po kroku i wskazówki wizualne (przy użyciu „Pomocnika”). Odpowiednio zaprojektowany interfejs użytkownika oszczędza czas użytkowników i programistów.

Ponieważ programiści mogą tworzyć różne interfejsy podczas tworzenia oprogramowania, ogólnie przyjmuje się, że korzystają z istniejących zaleceń i standardów. Na poziomie międzynarodowym opracowywaniem standardów w dziedzinie technologii informatycznych zajmuje się m.in

Międzynarodowa Organizacja Normalizacyjna (ISO) i inne organizacje (ITU, IEC itp.). Zazwyczaj opracowywane przez nie standardy mają charakter doradczy.

Proces tworzenia ergonomicznego interfejsu użytkownika dzieli się na następujące etapy:

1. Sformułowanie problemu, podczas którego zbierane i analizowane są dane o użytkownikach, formalizowana jest funkcjonalność i ustalane są obiektywne kryteria powodzenia projektu.

2. Projektowanie wysokiego poziomu, od którego rozpoczyna się właściwe projektowanie interfejsu. Poprzedni etap poświęcony jest wyłącznie zbieraniu danych i formułowaniu problemu.

3. Projektowanie niskopoziomowe, w którym opracowywane są interfejsy poszczególnych ekranów systemu (kompozycja, układ względny i elementy interfejsu wspierające tekst).

Większość oprogramowania zorientowanego na użytkownika końcowego działa w trybie konwersacyjnym interakcji z użytkownikiem, podczas którego wymieniane są komunikaty mające wpływ na przetwarzanie danych. Projektując PI należy określić:

1. Struktura dialogu.

2. Możliwy scenariusz rozwoju dialogu.

4. Atrybuty wizualne wyświetlanych informacji (składnia komunikatu)

Wykaz używanej literatury

1. Bakanov A.S., Oboznov A.A. Projekt interfejsu użytkownika: podejście ergonomiczne - M.: Wydawnictwo "Instytut Psychologii RAS", 2009. - 184 s.

2. Blagodatskikh V.A. Standaryzacja tworzenia oprogramowania: Podręcznik. dodatek. - M.: Finanse i statystyka, 2003. - 288 s.

3. Burtseva E.V., Seleznev A.V., Terekhov A.V. Systemy informacyjne: Podręcznik. dodatek. - Tambow: Wydawnictwo Tamb. państwo technologia Uniwersytet, 2009. - 128 s.

4. Volkov A.K. Informatyka (dla ekonomisty): Podręcznik. - M.: INFRA-M, 2001. - 310 s.

5. Gavrilov M.V. Informatyka i technologie informacyjne: Podręcznik dla uniwersytetów. - M.: Gardariki, 2006.

6. http://www.km.ru/referats/6893BB3095D64A08BC33DCF5ADB20A88

7. http://www.km.ru/referats/6893BB3095D64A08BC33DCF5ADB20A88

Chciałbym dać Ci prostą, ale paradoksalną radę: Nie wierz we wszystko, co mówią o projektowaniu.

Rzecz w tym, że projektowanie w tworzeniu stron internetowych, z wielu historycznych powodów, rozwinęło się na nowo i nadal jest niejasną, słabo opisaną i słabo rozumianą definicją. Sytuacja w ostatnich latach powoli się poprawia, ale pracy wyjaśniającej jest jeszcze sporo – dlatego każdy, kto chce zrozumieć projektowanie, powinien uzbroić się w głowę i nie bać się kwestionować każdego pozornie truizm.

Takich „truizmów” jest wiele, a razem dają początek okropnemu i strasznemu zestawowi mitów na temat designu - o najważniejszych z nich chciałbym dziś porozmawiać.

Mit nr 1. Projektowanie to usługa dodatkowa.

Projektant zaangażowany w ważną społecznie użyteczną pracę

Wiele osób uważa, że etap projektowania to usługa dodatkowa, którą można pominąć. To jest źle.

Dlaczego tworzymy produkty IT? Jeśli jesteśmy przy zdrowych zmysłach i mamy dobrą pamięć, tworzymy je w celu rozwiązywania problemów biznesowych (własnych lub naszych klientów - to nie jest takie ważne); rozwiązanie tych problemów biznesowych polega z kolei na stworzeniu produktu, który będzie spełniał zadania użytkownika, z uwzględnieniem warunków rynkowych, ograniczeń technologicznych i wszystkiego innego.

Aby produkt spełniał wszystkie warunki, należy zgromadzić wiele sprzecznych, niejasnych i trudno dostępnych informacji – porozmawiać ze wszystkimi aktorami, przestudiować związane z nimi procesy biznesowe, zapoznać się z systemami zewnętrznymi, przyjrzeć się konkurentów itd., więc dobrze byłoby zapisać zebrane informacje i zebrać je w jedną całość, tak aby wszyscy członkowie zespołu równie dobrze rozumieli dane wejściowe.

Następnie na podstawie zebranych informacji trzeba wymyślić produkt i to tak, aby nie był sprzeczny z warunkami zadania, a wręcz przeciwnie, przyczyniał się do ich realizacji – i taki produkt to złożony organizm, w którym wszystkie części są ze sobą połączone. Wynaleziony produkt ponownie trzeba odpowiednio zarejestrować, aby zarówno klient, jak i programista zrozumieli, co ostatecznie otrzymają (a w przyszłości mogli udoskonalić ten produkt).

Czy możliwe jest stworzenie złożonego i użytecznego produktu bez przejścia wszystkich tych etapów? Zgadzam się: mało prawdopodobne. Tymczasem wszystkie opisane procesy składają się na to, co powszechnie nazywa się projektowaniem – analizę (analiza warunków problemowych), syntezę (tworzenie produktu) i utrwalanie (stworzenie prawidłowej dokumentacji projektowej).

Projektowanie nie może być usługą dodatkową, o ile jest to istota tworzenia stron internetowych i ma na celu wyraźny wynik, a nie kontrolowanie budżetów lub walkę o dobro ze złem.

Mit nr 2. Design jest drogi.

Kierownik projektu pobiera budżet od klienta

Istnieje opinia, że etap projektowania tylko podnosi cenę produktu.

W związku z tym uwielbiam cytować Karla Wiegersa - patriarchę inżynierii systemów, autora wspaniałej książki „Inżynieria wymagań oprogramowania” i po prostu mądrego człowieka.

Karl Wiegers przeprowadził kiedyś badanie amerykańskiego rynku rozwoju IT i obliczył to średnio 40% budżetów na rozwój jest marnowanych, a pieniądze te są tracone nie z winy nieuczciwych programistów lub złych klientów, ale po prostu dlatego, że obie strony – klient i deweloper – po prostu nie mogliśmy się ze sobą zgodzić.

Czterdzieści procent - i to dla Ameryki, gdzie między klientem a deweloperem panują zupełnie inne relacje! Wydaje mi się, że w przypadku Rosji liczba ta jest jeszcze wyższa – około półtora raza.

Jednocześnie na prawidłowe zaprojektowanie systemu, według tych samych obliczeń Wigersa, przypada 15-20% budżetów rozwojowych (co w pełni potwierdza nasze doświadczenie).

Uzyskuje się ciekawy efekt: wydajemy stałe 15-20% na projektowanie, ale jednocześnie minimalizujemy wydatki „odpadowe” (te same 40% budżetu), które mogłyby potencjalnie pogrzebać projekt, a w dodatku ogromnie go opóźnić ramy czasowe na uzyskanie wykonalnego produktu.

Zatem koszt odpowiedniego projektu paradoksalnie wpływa na koszt całego projektu: z jednej strony etap projektowania nie jest darmowy i pochłania pewną część budżetu, ale z drugiej strony zmniejsza koszty całego projektu jako całości, usuwając ryzyka związane ze słabo przemyślanym i przez to nieprzewidywalnym produktem.

Mit nr 3. Design to pisanie specyfikacji technicznych

Słoń wykonany zgodnie ze specyfikacją

Często słyszy się, że projektowanie to proces tworzenia specyfikacji technicznych, które można załączyć do umowy. To jest źle.

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

projektowanie pozwala uwzględnić interesy użytkowników (a tym samym zminimalizować ryzyko rozwojowe);
projekt pozwala uwzględnić interesy klienta (a tym samym zminimalizować ryzyko rozwojowe);
projekt pozwala uwzględnić wszystkie istotne czynniki zewnętrzne (a tym samym zminimalizować ryzyka rozwojowe);
projekt pozwala stronom uzyskać wspólną wizję produktu (a tym samym zminimalizować ryzyko rozwojowe);
design pozwala dokładnie przewidzieć czas i koszt opracowania (i tym samym… cóż, rozumiesz).

Pisanie specyfikacji technicznych- to tylko jedno z narzędzi, które pozwala jednoznacznie, dostatecznie, systematycznie i w sposób zbywalny rejestrować wymagania dotyczące produktu w formacie zrozumiałym dla dewelopera. Tak, to narzędzie można nazwać najważniejszym, ale etap projektowania ma znacznie ważniejsze zadanie - i o tym trzeba pamiętać.

Mit nr 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 kojarzone z interfejsami.

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

Czy na tej podstawie interfejsy można uznać za jedyny godny cel projektowy? Oczywiście, że nie: interfejs to tylko wierzchołek góry lodowej produktu i jeśli mówimy o odpowiednim projekcie, który realnie minimalizuje ryzyko rozwojowe, to musimy też zająć się tym, co dzieje się wewnątrz produktu: strukturą jego danych, logika jego zachowania, połączenia z systemami zewnętrznymi, interfejsy administracyjne i wiele więcej.

Interfejs użytkownika to tylko jeden ze składników produktu, który umożliwia użytkownikom dostęp do funkcji i danych produktu. Ważne jest, aby to zaprojektować, ale ograniczanie się do tego jest szkodliwe.

Mit nr 5. Menedżer też potrafi projektować

Menedżer zaangażowany w podstawową działalność

Jak już się przekonaliśmy, projektowanie to złożony proces związany z żmudną, delikatną pracą. Aby projekt spełnił swoje cele, praca ta musi zostać wykonana tak efektywnie i przemyślanie, jak to tylko możliwe. Projektowanie inaczej mówiąc wymaga od wykonawcy posiadania bardzo specyficznego systemu wartości, w którym najważniejsza będzie jakość pracy i osobista odpowiedzialność.

Jednocześnie projektowanie często oddawane jest w ręce menadżerów jako osoby skupiające wszystkie procesy i wątki rozwoju. Wydawać by się mogło, że wszystko jest logiczne i poprawne, jednak nie bierze się pod uwagę jednego istotnego punktu: dobrzy menadżerowie mają zupełnie inny system wartości, gdzie na pierwszy plan wysuwa się harmonogram realizacji projektu i jego budżet.

W przypadku dużych projektów, a w szczególności niestandardowych projektów, jest to bardzo okrutny żart dla menedżerów: jeśli menedżer staje przed dylematem rozwiązania problemu związanego z projektem jako całością (na przykład wyciągnięcie projektanta z upijanie się - nawiasem mówiąc, całkowicie prawdziwa historia) lub rozwiązanie problemu związanego z projektowaniem (określ protokół danych bardziej szczegółowo w specyfikacjach technicznych), wtedy każdy menedżer wybierze rozwiązanie, które ugasi szalejące tu pożary i Teraz. W rzeczywistości niedokończona specyfikacja techniczna będzie miała skutki w dłuższej perspektywie, ale pożar projektu, który nie zostanie ugaszony na czas, doprowadzi do utraty projektu już w chwili obecnej. No i w końcu jak tu spokojnie pisać specyfikacje techniczne, kiedy klienci ciągle rozpraszają Cię drobiazgami?

I tak będzie przez cały okres rozwoju. Jeśli do tego aspektu wartości dodamy aspekt zawodowy (w końcu projektant musi umieć wiele z tego, o czym menadżer nie musi wiedzieć), to łatwo zrozumieć, dlaczego projektowaniem powinna zajmować się osobna, specjalnie wyszkolona osoba posiadająca własny system wartości.

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

Mit nr 6. Projektowaniem powinni zająć się psycholodzy

Zawartość techniczna produktu według psychologa

Część firm – nawet tych największych – uważa, że projektowaniem powinny zajmować się osoby z wykształceniem psychologicznym. Mit ten wyrasta z przekonania, że projektant ma chronić wyłącznie interesy użytkowników. Jak już się przekonaliśmy, tak nie jest – projektant zajmuje się całym produktem jako całością i bierze pod uwagę zarówno interesy użytkowników, jak i klienta, nie mówiąc już o specyfice systemu. Wszystko to wymaga umiejętności technicznych, których najczęściej brakuje psychologom.

Inna sprawa, że psychologowie mogą zajmować się wąską częścią projektu – pracą z interfejsami czy analizowaniem preferencji użytkownika – ale to wszystko powinno odbywać się pod okiem projektanta produktu, który uwzględni wszystkie techniczne subtelności i niuanse.

Mit nr 7. Projekt powinni wykonać inżynierowie.

W przeciwieństwie do mitu o psychologach, istnieje mit o inżynierach – mówią, że projektant musi być programistą. Jak już się zapewne domyślasz, jest to również zła opcja - programista sferyczny 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ć potrzeby klienta wymagania. Rzeczywiście, spotkałem takich programistów, ale według ich mentalności byli to raczej projektanci, którzy przez nieporozumienie zostali programistami.

Podobnie jak w przypadku poprzedniego mitu, w projekt można zaangażować programistów - ale tylko nad strukturą danych i opisami funkcjonalnymi produktu pod okiem projektanta (choć 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 ten sposób.

Warto pogodzić się z faktem, że nigdzie jeszcze nie uczą „porządnego” projektanta systemów.
Najczęściej odpowiedni projektant rodzi się na styku konwencjonalnych nauk humanistycznych i technicznych.
Najczęściej dobry projektant nie wie, że jest dobrym projektantem i pracuje w lewicowej specjalizacji, która nie sprawia mu radości.
Taki „nieaktywowany” dobry projektant ma schizofrenię, wykształcenie niemal techniczne, szerokie horyzonty i mentalność 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.

Osobiście z mojego doświadczenia wynika, że koncepcja projektanta jest raczej wrodzona. mi To prawda: projektanta można stosunkowo szybko przeszkolić w zakresie niezbędnych narzędzi i technik (poważnie, od trzech do sześciu miesięcy), ale zainwestowanie w niego niezbędnego systemu wartości i sposobu myślenia jest prawie niemożliwe.

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

Nie ma jednego podejścia do projektowania

Projektant nie może znieść intensywności pasji przy projekcie

Istnieje wiele podejść do projektowania, a niedoświadczony czytelnik może łatwo oszaleć od mnóstwa technik, podejść i skrótów, obficie doprawionych bałaganem terminologicznym (wszystkie te UX, UI, CX, HCD i inne IDDQD z krzywymi rosyjskojęzycznymi odpowiednikami ).

Niektórzy jednak próbują wyprowadzić uniwersalne modele projektowania, ale ostatecznie okazuje się, że próbując połączyć istniejących 20 (warunkowo) podejść do projektowania, otrzymujemy 21 podejść - i metodologie, jak się wydaje, zaczynają się reprodukować się.

Eksperci na tej podstawie wnioskują, że nie ma jednego podejścia do projektowania i nie może być – mówią, wszystko jest ściśle indywidualne, a zatem nie ma co systematyzować.

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

Zamiast wniosków

Czego więc się dzisiaj dowiedzieliśmy?

Projektowanie kosztuje i pozwala zmniejszyć budżet na rozwój.
Projekt minimalizuje ryzyko rozwojowe.
Projekt broni interesów produktu jako całości.
Projektowaniem powinni zajmować się projektanci (to prawda, prawda?).
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 nawet na słowo – będzie mi miło, jeśli się ze mną nie zgodzisz i będziesz bronić swojego punktu widzenia: będzie to powód do pożytecznej i wspaniałej rozmowy, podczas której może ujawnić się inna prawda pojawiają się - i czy to nie wspaniałe?