Wykład 14.

Projekt interfejs użytkownika. Podstawowe zasady i etapy konstrukcji interfejsu użytkownika: wybór struktury dialogu, rozwój skryptu okna dialogowego, definicję i umieszczenie elementów wizualnych. Elastyczne interfejsy. Środki wsparcia użytkownika, systemy odniesienia

Interfejs użytkownika - Jest to kombinacja modelu informacji obszaru problemowego, funduszy i metod interakcji użytkownika model informacji., a także komponenty zapewniające tworzenie modelu informacji w procesie pracy system oprogramowania (Slide 14.1) .

Model informacji jest warunkową reprezentacją obszaru problemowego, utworzonego przez obiekty komputerowe (wizualne i dźwiękowe) odzwierciedlające kompozycję i interakcję prawdziwych składników obszaru problemowego.

Środki i metody interakcji z modelem informacji są określane przez skład sprzętu i oprogramowania dostępnego do dyspozycji użytkownika i o charakterze rozwiązania zadania. Wydajność użytkownika jest określana nie tylko przez funkcjonalność sprzętu dostępnego do dyspozycji oprogramowanie, ale także dostępność dla użytkownika tych funkcji. Z kolei pełnia wykorzystania potencjalnych zasobów istniejących zasobów zależy od jakości interfejsu użytkownika.

Jakość interfejsu użytkownika jest niezależną cechą produktu oprogramowania, porównywalne do znaczenia z jego wskaźnikami, takimi jak niezawodność i wydajność przy użyciu zasobów obliczeniowych.

Według badań przeprowadzonych przez Xerox i jego pracownik David Liddle, interfejs użytkownika składa się z następujących podstawowych elementów reprezentowanych jako lodowa.

Zgodnie z tym badaniem interfejs składa się z trzech głównych części - zgłoszenie do użytkownika, interakcji i powiązań między obiektami. Jednocześnie "widoczna" część góry lodowej jest znacznie mniejsza niż jego "niewidoczna", ukryta część (Slide 14.2). Top Aisberga - informacje dla użytkowników (kolor, animacja, dźwięk, forma obiektów, lokalizacja informacji na ekranie, grafice) wynosi zaledwie 10% i jest w żadnym zakresie najważniejszym elementem interfejsu użytkownika. Kolejną częścią interfejsu użytkownika (30% modelu projektanta) jest techniką komunikacji z użytkownikiem i informacją o opinii. Wreszcie dolna część góry lodowej (60%) modelu projektanta jest najważniejszą częścią tego - są to właściwości obiektów i komunikacji 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 zarządza oprogramowaniem, a nie oprogramowanie ich zarządza.

Aby utworzyć użytkownika takiego uczucia "wolności wewnętrznej", interfejs musi mieć wiele właściwości. (Slide 14.4) :

Naturalny interfejs.

Spójność interfejsu.

Życzliwość interfejsu (zasada "przebaczenia użytkownika")

Zasada "opinii".

Łatwy interfejs.

Elastyczność interfejsu.

Apel estetyczny.

Naturalny interfejs. Naturalny interfejs jest taki, że nie zmusza użytkownika do znacznego zmiany zadania w zakresie regulowania. W szczególności oznacza, że \u200b\u200bwiadomości i wyniki wydane przez wniosek nie powinny wymagać dodatkowych wyjaśnień.

Spójność interfejsu. Spójność pozwala użytkownikom przenieść istniejącą wiedzę na nowe zadania, rozwijają nowe aspekty szybsze, a dzięki temu koncentrując się na rozwiązaniu zadania, a nie spędzać czasu na wyjaśnienie różnic w stosowaniu pewnych kontroli, poleceń itp. Zapewnienie ciągłości uprzednio uzyskanej wiedzy i umiejętności, spójność sprawia, że \u200b\u200binterfejs rozpoznawalny i przewidywalny.

Spójność jest ważna dla wszystkich aspektów interfejsu, w tym nazwy zespołów, wizualnej prezentacji informacji i zachowania elementów interaktywnych. Aby wdrożyć właściwości spójności w utworzonej oprogramowaniu, konieczne jest uwzględnienie różnych aspektów.

Spójność w produkcie.Ten sam zespół musi wykonać te same funkcje, gdziekolwiek się spotyka, a to samo w ten sam sposób.

Spójność w środowisku pracy.Wspieranie spójności z interfejsem dostarczonym przez system operacyjny (na przykład Windows), aplikacja użytkownika może "polegać na" w tej wiedzy i umiejętnościach użytkownika, który zdobył wcześniej podczas pracy z innymi aplikacjami.

Spójność w stosowaniu metafory.Jeśli zachowanie pewnego obiektu oprogramowania wykracza poza to, co zwykle sugerowano pod adresem metafory, użytkownik może mieć trudności podczas pracy z takim obiektem.

Życzliwość interfejsu (zasada "przebaczenia użytkownika"). Użytkownicy zazwyczaj zbadają funkcje pracy z nowym produktem oprogramowania według wersji próbnej i błędu. Efektywny interfejs powinien wziąć pod uwagę to podejście. Na każdym etapie pracy musi zezwolić na odpowiedniego zestawu działań i ostrzegają użytkowników o tych sytuacjach, w których mogą uszkodzić system lub dane; Jeszcze lepiej, jeśli użytkownik ma możliwość anulowania lub poprawienia wykonywanych działań.

Nawet przy obecności dobrze zaprojektowanego interfejsu użytkownicy mogą dokonać pewnych błędów. Błędy te mogą być jak "fizyczny" typ (losowy wybór nieprawidłowego polecenia lub danych) oraz "Logika" (wprowadzanie nieprawidłowe rozwiązanie do wyboru polecenia lub danych). Efektywny interfejs powinien umożliwić zapobieganie sytuacji, które prawdopodobnie są łączone przez błędy. Powinien być również w stanie dostosować się do potencjalnych błędów użytkowników i ułatwiać proces eliminowania konsekwencji takich błędów.

Zasada "opinii". Musisz zawsze przekazać informacje zwrotne dla działań użytkowników. Każda akcja użytkownika powinna otrzymać wizualne, a czasem słyszalne potwierdzenie, że oprogramowanie dostrzegło wprowadzone polecenie; Jednocześnie rodzaj reakcji, jeśli to możliwe, należy rozważyć charakter wykonywanych działań.

Informacje zwrotne są skuteczne, jeśli jest on wdrażany w odpowiednim czasie, tj. Jak najbliżej do punktu ostatniej interakcji użytkownika z systemem. Gdy komputer przetwarza otrzymane zadanie, warto dostarczyć użytkownikowi informacji dotyczących stanu procesu, a także zdolność do przerywania tego procesu w razie potrzeby. Nic nie myli bardzo doświadczonego użytkownika jako zablokowanego ekranu, który nie odpowiada na jego działania. Typowy użytkownik jest w stanie wytrzymać tylko kilka sekund oczekiwań odpowiedzi na elektroniczny "rozmówca".

Łatwy interfejs. Interfejs musi być prosty. Nie oznacza to nie uproszczenia, ale zapewnić łatwość nauki i użytkowania. Ponadto musi zapewnić dostęp do wszystkiego funkcjonalnośćprzewidziane w tej aplikacji. Wdrożenie dostępu do obszernej funkcjonalności i zapewnienie łatwości pracy sprzecznej się nawzajem. Rozwój efektywnego interfejsu ma na celu zrównoważenie tych celów.

Jednym z możliwych sposobów utrzymania prostoty jest widok na ekranie informacji, minimalnie niezbędne do wykonania następnego zadania użytkownika. W szczególności należy unikać różnych nazw dowodzenia lub wiadomości. Niedyginalne lub nadmierne frazy utrudniają wyodrębnianie istotnych informacji dla użytkownika.

Inną ścieżką do tworzenia prostego, ale efektywnego interfejsu jest umieszczenie i reprezentację elementów na ekranie, biorąc pod uwagę ich wartość semantyczną i logiczne połączenie. Umożliwia to wykorzystanie asocjacyjnego myślenia użytkownika podczas pracy.

Innym sposobem zarządzania złożonością wyświetlanych informacji jest użycie sekwencyjne ujawnienie (Okno dialogowe, partycje menu itp.). Spójne ujawnienie obejmuje taką organizację informacji, w których potrzebna jest tylko jedna część na ekranie na ekranie, który jest niezbędny do następnego kroku. Poprzez zmniejszenie ilości informacji przesłanych przez Użytkownika, w ten sposób zmniejsza ilość informacji do przetworzenia. Przykładem takiej organizacji jest menu hierarchiczne (kaskadowe), którego każdy poziom wyświetla tylko te elementy odpowiadające użytkownikowi, element wyższego poziomu.

Jedną z metodologicznych podstaw organizacji zarządzania procesami przetwarzania jest stosowanie "metafory" - znaczących analogów ukierunkowanych przetwarzania danych, ale na obszarach są bardziej zwyczajne dla ludzi niż automatyzacja.

Na przykład metafora "Desktop" zakłada, że \u200b\u200binterfejs zapewnia użytkownikowi możliwość dostępu do różnych źródeł informacji i pozwala na łatwe przełączenie z jednego źródła do innego (np. "Papier Shock na tabeli"), zmień jeden rodzaj zadania (arkusz kalkulacyjny) na innym (system przygotowania tekstu). Jednocześnie wszelkie inne środki są również dostępne dla użytkownika, w tym pomocniczego (kalkulator, zegar itp.).

Użytkownik może przesyłać informacje z jednego dokumentu do innego, włączając żądane części jednego dokumentu do odpowiednich miejsc innego dokumentu. Wiąże się z inną metaforem - "bufor przycinający". Przed pojawieniem się zautomatyzowanych systemów przetwarzania tekstu wystąpił tradycyjny sposób złagodzenia układu: sklejanie cięcia fragmentu zamiast przedrukować stronę. Interfejsy Wimp zapewniają podobne możliwości cięcia i wkładania, ale bufor, w którym znajduje się rzeźbiony fragment, umożliwia wstawienie tak wielu kopii przedmiotów danych w razie potrzeby.

Zasada metaforyczna opiera się na podstawie technologii Wisiwig - natychmiastowa wizualizacja na ekranie wyników działania. Oznacza to, że ekran musi symulować środki drukowania, a jeśli użytkownik chce wydrukować część tekstu w nim wewnętrznie, należy go zastosować do ekranu. Jeśli plik zostanie zniszczony, użytkownik widzi, że plik znika z listy plików pokazanych na ekranie. Interfejs w formularzu naturalnym zapewnia użytkownikowi informacje o stanie obiektu, potwierdzając, że działanie przeprowadzono. Można powiedzieć, że ta metafora dokładniej odpowiada wzorze " Widzisz, co mam w wyniku moich działań. ".

Elastyczność interfejsu. Elastyczność interfejsu jest jego zdolność do uwzględnienia poziomu przygotowania i wydajności użytkownika. Właściwość elastyczności obejmuje możliwość zmiany struktury dialogu i / lub danych wejściowych. Elastyczna koncepcja (Adaptive) interfejs jest obecnie jednym z głównych obszarów badania interakcji ludzkiej i komputera. Głównym problemem nie jest zorganizowanie zmian w dialogu, ale w jakich funkcjach należy użyć do określenia potrzeby wprowadzania zmian i ich istoty.

Apel estetyczny. Prawidłowa wizualna reprezentacja zastosowanych obiektów zapewnia przeniesienie wysoce ważnych dodatkowych informacji o zachowaniu i interakcji różnych obiektów. Jednocześnie należy pamiętać, że każdy element wizualny, który pojawia się na ekranie potencjalnie wymaga uwagi użytkownika, który jest znany, nie jest nieograniczony.

Jakość interfejsu jest trudna do oceny charakterystyki ilościowych, ale więcej lub mniej obiektywnych szacunków można uzyskać na podstawie następujących prywatnych wskaźników.

Potrzebny czas konkretny użytkownik Aby osiągnąć określoną wiedzę i umiejętności do pracy z aplikacją.

Zapisywanie umiejętności pracy po pewnym czasie wygaśnięcia (na przykład po cotygodniowej przerwie użytkownik musi wykonać określoną sekwencję operacji przez określony czas).

Rozwiązanie rozwiązania zadania za pomocą tej aplikacji; Jednocześnie prędkość systemu nie jest prędkością i szybkością wpisu danych z klawiatury, Aura, która jest niezbędna do osiągnięcia celu zadania rozwiązania. W oparciu o to, kryterium oceny tego wskaźnika można sformułować, na przykład w następujący sposób: Użytkownik musi przetwarzać co najmniej 20 dokumentów z błędem nie więcej niż 1%.

Subiektywna satysfakcja użytkownika podczas pracy z systemem (który ilościowo można wyrazić jako procent lub oszacowanie w skali N-punkt).

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

Formalizacja kontekstu użytkowania

Formalizacja obiektywnych kryteriów sukcesu

Analiza celów

Formalizacja ról biznesu użytkownika

Formalizacja funkcjonalności

Formalizacja scenariuszy działań użytkownika

Przegląd interfejsu systemów konkurencyjnych

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

Formalizacja kontekstu użytkowania

Na tym etapie zebrano większość użytkowników. Opisane są następujące właściwości publiczności:

Charakterystyka użytkowników: ich doświadczenie z komputerem, znajomość obiektu, motywy, rozmiar / znaczenie grup użytkowników, próbek (typowe sytuacje)

Cele i zadania użytkownika;

Zadania projektowe: Jaki był powód do tworzenia projektu, etapy tworzenia projektu, które należy uzyskać wyniki, które informacje są konieczne i gdy;

Technologia rozwoju i platforma, na których użytkownicy będą pracować;

Środowisko, w którym projekt (fizyczny, rynek, organizacyjny i kulturowy) zostanie utworzony i używany.

Przy wejściu: Dostęp do istniejących i potencjalnych użytkowników, ekspertów i dokumentacji projektu.

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

top do kategorii

Formalizacja obiektywnych kryteriów sukcesu.

Na tym etapie przeznaczono obiektywne kryteria oceny ergonomicznego interfejsu, takie jak wskaźniki wydajności, wydajność, satysfakcja użytkownika (na wcześniejszych etapach niemożliwe jest zidentyfikowanie tych kryteriów).

Odpowiednio, na tym etapie tworzone jest prawdziwe zadanie dla projektu interfejsu. Na przykład:

Grupa użytkowników stale zmienia ich skład i domniemana próba użycia jest rzadko stosowana. Konieczne jest skupienie się na prostocie zrozumienia interfejsu.

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

20% zmniejsza liczbę błędów ludzkich.

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

Na wyjściu: lista obiektywnych kryteriów sukcesu.

top do kategorii

Analiza celów

Deweloper musi wyraźnie zdawać sobie sprawę, że użytkownicy nie potrzebują samych narzędzi, potrzebne są tylko wyniki ich pracy. Nikt nie potrzebuje procesora tekstowego - potrzebujesz możliwości pisania tekstów z wygodą. Nikt nie potrzebuje programu przetwarzania obrazu - potrzebujesz już przetworzonych obrazów. Oznacza to, że same funkcje nie są potrzebne i nie są ważne. Ludzie potrzebują narzędzia w ogóle, co umożliwia wykonywanie jakiejkolwiek pracy.

Różnica w podejściach do wyboru funkcjonalności jest dogodnie zilustrowana przez przykładem tostera. Standardowe podejście, w którym funkcje są wybrane praktycznie dowolnie arbitralnie, spowoduje to zadanie: "Potrzebujesz pudełka z wąskim prostokątnym otworem i grzejnikiem wewnątrz". Analiza celów użytkownika doprowadzi do kolejnego sformułowania: "Potrzebujesz chleba tostowego. Wydaje się, że najłatwiejszym sposobem osiągnięcia tego do osiągnięcia szuflady z otworem na kształcie kawałka chleba i grzejnika wewnątrz. Z drugiej strony wydaje się, że ta metoda nie jest jedyna. ". Drugą opcją w pełnym rozwojem tej metody może nie tylko prowadzić do stworzenia tostera, ale także rzeki (tj. Urządzenia, w których nie tylko chleb może być karmiony).

Wynikiem tego procesu powinien być wykazem celów, na przykład, dla tostera, ostateczna lista celów powinna wyglądać bardzo proste: "Musi pchać małe kawałki żywności, głównie chleba".

Na wyjście: Zalecenia dotyczące optymalizacji interfejsu, lista udanych i nieudanych rozwiązań interfejsu (ostrość jest na roztworach, które nie powiodły). Jeśli aktualna wersja jest używana na tym etapie, raport zawiera krótkie protokoły i listę wniosków badawczych.

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

Na wyjściu: lista obiektów wdrażania nowego interfejsu z charakterystyką wagi każdego.

top do kategorii

Formalizacja ról biznesu użytkownika

Funkcjonalność dowolnego systemu jest podzielona na kilka ról użytkowników: różnych użytkowników potrzebują różnych bloków funkcji (w systemach automatyzacji, role te nazywane są role biznesowe). Nawigacja systemowa bezpośrednio zależy od tych ról, ponieważ w ramach tej samej roli w nawigacji nie jest pożądane włączenie funkcji z roli innej osoby. W związku z tym na tym etapie przydzielono podstawowe role użytkowników z funkcjami dotyczącymi tych ról. Na tym etapie występują wywiady z każdym z przedstawicieli pewnej roli do identyfikacji cech tej roli i dowiedzieć się, jakie należy zapewnić dodatkowe (w stosunku do formalnych) możliwości.

Na tym etapie można zastosować metodę obserwacji osób wykonujących swoje zadanie za pomocą już istniejących narzędzi i jest systemem konkurentów (jeśli w ogóle) i obiektom rzeczywistego świata. Nie złe źródło materiału do analizy często służy nawet nie obserwować ludzi, ale analiza wyników ich pracy jest to, że jeśli okaże się, że wynik pracy jest praktycznie niezależny od użytego narzędzia, oznacza to, że tylko funkcjonalność jest potrzebne (tj. Funkcje, których nikt nie skorzystał, nie jest potrzebny).

Zwykle jest kilka na różne sposoby wdrażanie tej samej funkcji. Analiza działań użytkownika umożliwia określenie, która metoda powinna być wdrażana. Ponieważ na tym etapie dowiemy się, że funkcjonalność jest potrzebna dla każdej roli biznesowej, możesz wybrać odpowiednią ścieżkę zgodnie z zasadą "Mniejsze działanie jest wymagane od użytkownika, tym lepiej".

Na wyjście: opis ról biznesu użytkownika.

top do kategorii

Formalizacja funkcjonalności

Na tym etapie, na podstawie informacji opracowanych na poprzednich etapach, w końcu generowana jest lista funkcjonalności nowej wersji systemu. Wcześniej utworzony TK czasami nie obejmuje części niezbędnej funkcjonalności lub zawiera funkcjonalność, która nie jest realistyczna, użytkownicy.

Przy wejściu: Dostęp do użytkowników, ekspertów i dokumentacji projektu, znajomość głównych aspektów obszaru tematycznego.

Na wyjściu: Opis funkcjonalności systemu (raport na temat realizacji tego etapu pracy jest zwykle nie utworzony, zamiast tego utworzone zadanie techniczne jest aktualizowane).

top do kategorii

Formalizacja scenariuszy działań użytkownika

Na tym etapie częściowo badane są częściowo opracowane przez scenariusze działań użytkownika: Sformalizowanie danych niezbędnych dla użytkowników do wykonywania pracy, sekwencji samej pracy, kryteria kompletności tej pracy.

Celem tego etapu jest napisanie słownego opisu interakcji użytkownika z systemem bez określania dokładnie, jak idzie interakcja, ale może płacić większa uwaga Wszystkie cele użytkownika. Liczba scenariuszy może być arbitralna, główną rzeczą jest to, że powinny obejmować wszystkie rodzaje zadań stojących w obliczu systemu i być realistycznym. Skrypty są bardzo wygodne, aby odróżnić nazwiska fikcyjnych znaków uczestniczących w nich.

Przypuśćmy, że konieczne jest opracowanie skryptów na przyszły program pocztowy. Najwyraźniej trzech scenariuszy potrzebuje tego zadania:

Elizabeth Petrovna uruchamia program pocztowy. Obejmuje proces pobierania nowej poczty. Po odebraniu poczty, czyta wszystkie wiadomości, a następnie część ich usuwa i odpowiada na jedną wiadomość. Po tym wyłączy program pocztowy.

Andrei Fedorovich tworzy aktywne okno programu już otwartego poczty i zawiera proces pobierania nowa poczta. Po otrzymaniu poczty, czyta go. Jedna wiadomość, którą wysyła do innego adresata, po czym go usuwa, a jeszcze jedno wydruki. Po tym przełączy się na inne zadanie.

Nowa wiadomość pojawiła się, a administrator systemu Andrew postrzega odpowiedni wskaźnik. Tworzy aktywny okno programu pocztowego i otwiera odebraną wiadomość. Czyta go, po którym przenosi go do innego folderu. Po tym przełączy się na inne zadanie.

Scenariusze te mają podwójną wartość. Po pierwsze, będą przydatne do późniejszych testów, ponieważ nie jest testowany przez wykonanie abstrakcyjnych zadań, ale wykonywanie określonych w tych scenariuszach, operacjach. Po drugie, fakt ich pisania jest zwykle, nie zawsze, prowadzi do lepszego zrozumienia urządzenia zaprojektowanego systemu, zachęcające do natychmiastowego optymalizacji przyszłej interakcji. W takich scenariuszach niepotrzebne kroki są zauważalne. Na przykład w trzecim scenariuszu administrator systemu Andrew, po otrzymaniu wskaźnika, nie można natychmiast otworzyć nowej wiadomości, ale okno systemowe musiało otworzyć, znaleźć odpowiednią wiadomość, otwórz go i tylko przeczytaj. Jest jasne, że z tych niepotrzebnych etapów można bezpiecznie pozbyć się tego wczesnego etapu projektowania.

Przy wejściu: Dostęp do użytkowników, ekspertów i dokumentacji projektu, znajomość głównych aspektów obszaru tematycznego.

Na wyjście: Scenariusze pracy użytkownika (zaprojektowane scenariusze, są reprezentowane w postaci schematoryjnych opisujących cały proces korzystania z systemu do wykonania zadania).

top do kategorii

Przegląd interfejsu systemów konkurencyjnych

Większość publiczności dowolnego systemu ma umiejętności korzystania z kilku konkurencyjnych systemów; Jeśli opracowany interfejs jest całkowicie niezrozumiały z konkurentami, użytkownicy będą musieli zostać wycofani. Ponadto, konkurencyjne systemy często zawierają skuteczne rozwiązania, które są przydatne do nauki (lub częściej, biorąc pod uwagę przy projektowaniu interfejsu).

Podobnie jak w przypadku eksperta ocenę obecnego interfejsu systemu, raport na temat wykonania tego etapu pracy zawiera listę udanych i nieudanych rozwiązań interfejsu; Ogólnie rzecz biorąc, raport jest bardziej skoncentrowany na udanych rozwiązaniach.

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

Na wyjściu: Przegląd zalet i wad interfejsu konkurencyjnych systemów.

top do kategorii

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

Na tym etapie badane są subiektywne oczekiwania użytkowników z systemu. Bez tego badania jest trudne lub niemożliwe do przewidzenia relacji użytkowników do przyszłego systemu.

Wejście: Dostęp do użytkowników.

Na wyjściu: opis cech, do których interfejs powinien spełniać, aby zwiększyć subiektywną satysfakcję, listę charakterystyki systemu systemu. W zależności od wybranej metody badawczej zawiera dane liczbowe lub szacowane dane.

Ten artykuł będzie przydatny dla tych, którzy dopiero zaczynają tworzyć interfejsy - otrzymasz pomysł, w którym kierunku się poruszy. Doświadczyłem nic nowej obietnicy, maksimum - Twoja wiedza będzie w schudnym obrazie. Więc gdzie zacząć projekt?

Biegnij, aby przeczytać książki i artykuły Google do inspiracji - nie najlepszy pomysł. Interfejsy z samych czytania nie są zaprojektowane i nie stają się lepsze. Oczywiście teoria jest dobra, ale jak w każdym przypadku, na teorii "Nie odejdę". Do materiałów odniesienia, aby skontaktować się z początkowym etapem, jest również bez znaczenia - należy to zrobić za pomocą konkretnych pytań. I niekończące się niewielkie oprogramowanie do projektowania nie powoduje wzrostu wydajności.

Co zrobić, aby rozpocząć projekt?

Po pierwsze, zaczynając pracować, warto myśleć o wyniku: zdjęcia (to jest interfejsy) i działania. Po drugie, betonowe kroki pomogą: zrozumieć problem, sformułować zadanie, tworzyć przynajmniej coś, a następnie poprawić, napisz historie (opowiemy o nich poniżej w tekście) lub szukamy porady dla doświadczonych ludzi.

Bez doświadczenia i odpowiedzi na pytanie "Gdzie się rozpocząć?" Strach powstaje. Coś nowego, to się boi, ale niemożliwe jest siedzenie bez powodu bez powodu. Pierwszy cholernie nadal będzie com. Nie bój się mówić o swoim pierwszym doświadczeniu. Każdy interfejs, który zrobiłeś, jest jeszcze straszny - nadal możesz używać.

Tworzyć historie.

Przede wszystkim warto zrozumieć, że interfejsy są językiem, którego już znamy. Każdy użytkownik może czytać i pisać w tym języku. Z błędami, oczywiście, ale wie, jak. Podobnie jak dowolny język, interfejsy istnieją do przenoszenia myśli. Jest spójny wśród osób, które mają być wyrażone, więc pierwszy krok jest formułowanie pomysłów i tworzenie fabuły, która przechwytuje słuchacza i daje impulsowi wszystkim, co się dzieje.

Aby zrozumieć, co rozumiemy w terminie "historia", wyobraźmy sobie: Maxim staje się klientem pokazu motorów "Star Neva" - kupił sobie nowy samochód. Podsumowując umowę w Urzędzie Spółki, pracownicy programu motorycznego informują go o istnieniu systemu online dla klientów, gdzie widzi jego płatności, płatność kredytową, przypomnienia o kontroli technicznej i ubezpieczenia, a także wiadomości salon samochodowy.

Z takiej prawej strony zaczynamy "reagować" historię. Co najważniejsze, w procesie historii wymyślania, wypracuj wszystkie możliwe opcje rozwijania wydarzeń.

Przy wejściu do systemu Maxim widzi swoją pierwszą płatność na automatowym pokazie, cechach samochodu, dokumentów w samochodzie, nazwa twojego menedżera. Jeśli jego zakup spadnie w ramach żadnej promocji, zobaczy w ostrzeżeniem o warunkach promocji (na przykład wolnego przemywania samochodów klasy "Suite" w sierpniu).

W domu Maxim zapoznał się z systemem. Podczas procesu randkowego system jest regulowany dla MAXIM i pokazuje dla niego najważniejsze informacje.

Bez historii nie ma produktu, brak projektu, bez interfejsu. Połączona historia pozwoli Ci wyjaśnić zachowanie użytkownika i zrozumieć, czego brakuje.

Oddziaływanie z komputerem, osoba próbuje nie zamienia się w samochód, ale wręcz przeciwnie - w celu określenia systemu. Jaką funkcjonalność nie powiesić, bez emocji, nie będzie interesujące dla człowieka. Ludzie oczekują od komputera nowych wrażeń i reakcji na swoje działania. Dobre historie powodują emocjonalną odpowiedź: lubię to - nie lubię, szybko - powoli, chcę - nie chcę.

Ucz się czasownik

Zanim zaczniesz coś rysować, omówić połączoną historię w zespole, który zamierzasz naprawić. Dodaj czasowniki, aby rozwinąć działkę, więc szybko ujawniasz scenariusz zachowań użytkownika. Komponent literowy zasługuje na szczególną uwagę. Przeanalizuj słowa i brzmienie: Jakie przymiotniki i rzeczowniki pojawiają się w historii - nic nie dzieje się bez czasowników.

Rozrywki w stylu "Byłoby miło zrobić przyciski tutaj" muszą się obrócić, ponieważ prowadzą do myśli z dala od spójnej historii. Podczas pracy na interfejsie każdy powinien znać działkę interakcji użytkownika z usługą i przewiń go w głowie. Bez spójnej historii nie otrzymuje się podłączonych interfejsów.

Daj grać!

Popularne zgrabiarki, które można użyć, to powiedzieć "do piekła, grajmy!". Oczywiście jest to również sposób na nauczenie się, jak projektować: rozwijamy narzędzie, aw trakcie obudowy otrzymujemy umiejętności. Ale problem polega na tym, że narzędzie nie pozwoli rozwiązać poprawnie zadania, wiedzy i doświadczenia zwykle mogą pomóc. I tak, że nie spędzasz czasu na popiersie programów, krótko opowiemy o nich.

Tworzenie złożonego i dobrego interfejsu to proces łączący specjalistów w różnych dziedzinach. Potrzeba tak długo, więc rozwój interfejsu witryny lub programu jest podzielony na niektóre etapy.

Proponowany podział nie jest uniwersalny. Każdy z etapów można podzielić na subjące. I dalej podpodteapy - więc proces wygląda jeszcze trudniejsze, co oznacza droższe w oczach klientów :-)

1. Kolekcja danych.

Potrzebna jest gromadzenie danych, aby jasno zrozumieć, jaki rodzaj produktu istnieje ten momentże nie pasuje do klienta i jaki wynik oczekuje od współpracy. Na tym etapie projektowanie projektantów interfejsu programu:

• komunikuje się z klientemzrozumieć znaczenie i filozofię programu;
• patrząc na pracę: Gotowe prototypy (nawet jeśli istnieją tylko na serwetce);
• analiza programów konkurencyjnych (i być może prowadzi testowanie użyteczności programów konkurentów);
• przeprowadzić przedstawione wywiady klientów. lub potencjalni klienci.

2. Projekt

Na tym etapie projektowanie projektantów interfejsu programu:

• określa siatkę, kolory, czcionki i tło;
• i często tworzy niestandardowe kontrole, takie jak menu rozwijane.

Oczywiście każdy z etapów jest dyskusja i, jeśli to konieczne, bezpłatne wyrafinowanie. Twoje zamówienie Dostaniesz albo jak pliki graficzne w formacie Photoshoplub w formie Kod HTML lub XAML.

4. Realizacja

Gdy wszystko jest jasne z interfejsem, pozostaje trochę :) Z reguły, nasi klienci posiadają programistów w pełnym wymiarze godzin, a my przyciągamy do nas dla różnych prac związanych z interfejsem użytkownika, od projektowania do tworzenia ikon. Jednak dla tych klientów, którzy nie mają własnych programistów, oferujemy rozwój i testowanie aplikacji internetowych i aplikacji mobilnych w ramach IOS. Mamy stały departament deweloperów i testerów. Gwarantujemy: bez niezależnego.

Na etapie wdrażania istnieje rozwój i testowanie (QA, nie użyteczność) programu. Programiści będą zdecydowanie zrozumiałejak zrobić coś na podstawie pliki graficzne. (Szkice) i wyjaśnienia dla nich. W przeciwnym przypadku, my Dorisy i dodamy.

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

5. Testowanie użyteczności

Przyciąganie projektu dobrego projektanta interfejsu nie zapisuje się od konieczności systematycznego przeprowadzania testów użyteczności. Poleganie tylko na "genialny projektant interfejsu" jest szkodliwy z następujących powodów:

• naturalnie, musisz spróbować pracować nad projektem najlepszych projektantów interfejsu (na przykład Visualpharm :) ale niestety nie zawsze jest to możliwe. Czasami w projekcie weź udział Ci ludzie możesz do niego przyciągnąća nie te o pracy, z którymi marzysz;
• projekt nie jest dokładną nauką.; Nawet jeśli twój projektant jest geniuszem, nie wszystkie jego pomysły są równie dobre. Dlatego w celu zmniejszenia ryzyka, będzie logiczne, aby odsłonić wszystkie te pomysły w prawdziwym życiu z prawdziwymi użytkownikami. (Przypominamy Ci nowe pomysły, z którymi można sprawdzić minimalny koszt za pomocą takiego technika jako prototyp papieru);
• jak projektanci interfejsu zazwyczaj stają się dobrymi projektantami? Bardzo proste: uczenie się doświadczyć, jakie pomysły działają, a które nie są. Ale w tym doświadczeniu wymaga testówktóre są przeprowadzane przez ekspertów z użytecznością;
• nawet najlepsi projektanci mogą tworzyć udany produkt tylko wtedy, gdy rozwiązują właściwe zadanie. Wspaniały interfejs nie pomaga, jeśli funkcjonalność jest nieograniczona. ALE w jaki sposóbprojektanci interfejsydowiedz się, czego potrzebujemy użytkownicy? Odpowiedź jest prosta: przy pomocy użyteczności;
• nikt nie jest idealny. Nawet więcej dobry projekt Można go poprawić, jeśli przejdziesz przez proces poprawy jakościowej. Na każdym etapie wydawasz testy z użytkownikami i na podstawie wyników krok po kroku, poprawić 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 ramach odbiorców docelowej. Znajdziemy go. Potrzebujesz Amerykanów z Midwesta w wysokości 30-55 lat zainteresowanych rosyjskimi panonami? Zapraszamy.

Możesz wykonać testowanie użyteczności zarówno prototypu, jak i gotowy produkt. Ogólne zalecenie - zamiast jednego dużego testu, wykonaj wiele małych testów. Wykonane, przetestowane, poprawione, testowane ponownie. Pozwoli to znaleźć i poprawić niepewne błędy.

wyczucie czasu

Czas trwania pracy zależy na liczbie ekranów. Projekt i projekt jednego ekranu wymaga tego samego czasu. Zazwyczaj potrzebujemy dwa dnistworzyć prototyp (lub projektowanie) jednego ekranui pięć dni na projekt całego zamówienia. Tak więc rozwój (projekt lub projekt) pięciu ekranów zajmie 15 dni roboczych.

Korekta na żądanie będzie wymagała dodatkowego czasu. Chociaż nie bierzemy dodatkowych opłat za edycję, mogą wpływać na terminy na koniec projektu. Często edycja wymaga więcej niż bezpośrednio do tworzenia ekranów.

W gospodarstwie test użytecznościpotrzebuję 6 dni roboczych. Wszystko zależy od tego, czy chodzi o testowanie całej aplikacji lub o małych testach iteracyjnych.

Koszt

Projektowanie i projektowanie jednego ekranu również stają się równo:

• projekt / projekt pierwszego ekranu Warto było 48 800 R.. Pierwszy ekran jest droższy, ponieważ określa całą aplikację. Podczas ich opracowywania musimy wziąć pod uwagę strukturę całej aplikacji;
• design / Design innych ekranów – 18 350 R.. dla każdego.

Tak więc rozwój prototypu (lub projektu) pięciu ekranów będzie kosztować 48 800r. + 18 350r. x 4 \u003d. 122 200r.

Przybliżony koszt testowania użyteczności 52 500R. - 126 000r.

Duże projekty

Powyższy opis dotyczy małych projektów do opracowania interfejsu programu. Duże projekty będzie przydatne jest podział na podtaski spędzić cykl dla każdego z nich. Na przykład, jeśli opracowaliśmy interfejs Skype, można wyróżnić moduły:

• berło komunikacja głosowa;
• interfejs komunikacyjny z wideo;
• lista kontroli kontaktów;
• itp.

Dla każdego z wymienionych modułów wskazane jest przejście przez wszystkie etapy. Następnie przejdź do następnego modułu. Ta metoda rozwoju jest nazywana Zwinny. (Przeczytaj "Edula"). Ta metodologia jest zwyczajowa do szacunku i wspomina za każdym razem, gdy chcesz zaimponować klientom i piękne dziewczyny :-)

Chciałbym dać ci prostą, ale paradoksalną radę: nie wierz w wszystko, co powiedziano o projekcie.

Rzeczy jest to, że projekt w zakresie rozwoju sieci dzięki wielu historycznych przyczynach rozwinęło się przez pokład piątego i jest nadal niewyraźne, słabo opisane i niewielu, którzy są rozumiane. Sytuacja powoli wyprostowana ostatnie lataAle istnieje wiele prac wyjaśniających - a zatem każdy, kto chce wymyślić projekt, musisz dołączyć głowę i nie bać się kwestionowania każdego kapitału, wydaje to prawdę.

Istnieje wiele takich "kapitałowych" prawd, a razem rodzą straszny i straszny zestaw mitów o projekcie - o najważniejszych z nich chciałbym dziś porozmawiać.

Mit Numer 1. Projekt to dodatkowa usługa

Projektant zaangażowany w ważny społecznie przydatny biznes

Wielu uważa, że \u200b\u200betap projektowania jest dodatkową usługą, która ma zostać zaniedbana. To nie jest prawda.

Co tworzymy produkty IT? Jeśli jesteśmy w stanie umysłu i dobrej pamięci, tworzymy je do rozwiązywania zadań biznesowych (własnych lub ich klientów - nie jest tak ważny); Rozwiązanie tych zadań biznesowych z kolei opiera się na realizacji problemów utworzonych przez zadania produktu, biorąc pod uwagę warunki rynku, ograniczeń technologicznych i wszystko inne.

Aby produkt mógł spełnić wszystkie warunki, konieczne jest zebranie wielu sprzecznych, niespecyficznych i trudnych do osiągnięcia informacji - aby porozmawiać ze wszystkimi obowiązującymi osobami, badanie powiązanych procesów biznesowych, zapoznają się z systemami zewnętrznymi , Spójrz na konkurentów i tak dalej, a informacje zebrane byłyby miło naprawić i łączyć, aby wszyscy członkowie zespołu mają taki sam dobry pomysł danych wprowadzających.

Ponadto, na podstawie zebranych informacji, musisz wymyślić produkt i wymyślić go, aby nie zaprzeczył warunków zadania, ale przeciwnie, przyczyniłoby się do ich wdrożenia - i takiego Produkt jest złożony organizm, w którym wszystkie części są ze sobą połączone. W razie wynalazł produkt, konieczne jest prawidłowe rozwiązanie go do klienta, a deweloper rozumie, że otrzymają one w końcu (aw przyszłości produkt można wyrafinowany).

Czy można wykonać, ile złożony i użyteczny produkt, przekazuje wszystkie te etapy? Zgadzam się: Ledwie. Tymczasem wszystkie procesy opisane i uzupełniają to, co jest zwyczajowe, które mają być nazywane projektami - analiza (analiza warunków problemu), syntezy (tworzenie produktu) i fotowanie (opracowywanie prawidłowej dokumentacji projektu).

Projekt nie może być usługi dodatkowe , Ponieważ wkrótce jest ciało z mięsa rozwoju i ma na celu zrozumieć wynik, a nie na rozwój budżetów ani walki o wszystko dobrze przeciwko całej złej.

Mit # 2. Projekt jest drogi

Menedżer projektu puka budżetu od klienta

Jest to opinia, że \u200b\u200betap projektowania zwiększa koszt produktu.

W tym względzie uwielbiam cytować Karl Wirza - patriarcha projektu systemu, autora cudownej książki "Rozwój wymagań oprogramowanie"I tylko inteligentna osoba.

Karl Wiggers w jakiś sposób prowadził badanie amerykańskiego rynku rozwoju IT i obliczył to Średnio 40% budżetów rozwojowych zastanawia sięCo więcej, te pieniądze nie są stracone z powodu błędu kluczowych deweloperów lub złych klientów, ale tylko dlatego, że dwie strony są klientem i deweloper - po prostu nie mogłem się zgodzić.

Czterdzieści procent - a to jest dla Ameryki, gdzie zupełnie inne relacje między klientem a panowaniem dewelopera! Dla Rosji wydaje mi się, że liczba ta jest jeszcze wyższa - Edak o jeden i pół razy.

Jednocześnie prawidłowy projekt systemu, zgodnie z obliczeniami tego samego wigera, zajmuje 15-20% budżetów do rozwoju (a liczba ta jest w pełni potwierdzona przez nasze doświadczenie).

Wyszło na to, że ciekawy efekt: Wydajemy ustalone 15-20% dla projektu, ale jednocześnie zminimalizujemy "puste" wydatki (te największe 40% budżetu), co potencjalnie zakopuje projekt, a ponadto, niezwykle opóźnienie terminu Produkt operacyjny.

Zatem koszt odpowiedniego paradoksalnie wpływa na koszt całego projektu jako całości: z jednej strony etap projektowania nie jest wolny i przyjmuje pewną ilość budżetu, ale z drugiej, zmniejsza koszt całego Projekt jako całość ze względu na ryzyko związane ze słabo przemyślaną, a zatem nieprzewidywalny produkt.

Mit # 3. Design to pisanie TK

Słoń wykonany przez tk

Często musisz usłyszeć, że projekt jest procesem pisania TK, który może być dołączony do umowy. To nie jest prawda.

Jak dowiedzieliśmy się podczas analizowania poprzedniego mitu, projekt minimalizuje ryzyko rozwoju. Będziesz się śmiać, ale jedynym i najważniejszym spotkaniem - wszystko inne jest harmonijnie wynika z tego faktu:

• design pozwala wziąć pod uwagę interesy użytkowników (a tym samym minimalizując ryzyko rozwoju);
• design pozwala wziąć pod uwagę interesy Klienta (a tym samym minimalizowanie ryzyka rozwoju);
• design pozwala wziąć pod uwagę wszystkie istotne czynniki zewnętrzne (a tym samym minimalizowanie ryzyka rozwoju);
• design pozwala stronom uzyskać pojedynczą wizję produktu (a tym samym minimalizując ryzyko rozwoju);
• design pozwala dokładnie przewidzieć czas i koszt rozwoju (a tym samym ... Cóż, rozumiesz).

Pisanie TZ. - Jest to tylko jeden z narzędzi, które jest zdecydowanie wystarczające, systemowo i wszędzie naprawiają wymagania dotyczące produktu w formacie przezroczystego dla dewelopera. Tak, to narzędzie można nazwać najważniejsze, ale etap projektowania zwiększa znacznie ważniejsze zadanie - i należy go pamiętać.

Mit Numer 4. Projekt dotyczy interfejsów użytkownika

Produkt z przemyślanym przyjaznym interfejsem

Ze względu na zestaw powodów, projekt na naszym rynku (i nie tylko na naszym) rynku tworzenia stron internetowych jest mocno związany z interfejsami.

Rzeczywiście, interfejsy są najbardziej zauważalną częścią produktu: Jest z nią, że użytkownicy będą w kontakcie z ich zadaniami przy użyciu produktu, a tym samym przyczyniają się do wykonania zadań klienta.

Czy jest to możliwe, aby rozważyć interfejsy jedyny godny cel dla projektu? Oczywiście, nie: interfejs jest tylko częściową częścią lodowej produktu, a jeśli rozmawiamy o właściwym wzorze, co naprawdę minimalizuje ryzyko rozwoju, musimy również radzić sobie z tym, co dzieje się w produkcie: Struktura jego danych, logika jego zachowania i zewnętrznych systemów obligacji, interfejsy administracyjne i wiele innych.

Interfejs użytkownika - To tylko jeden z elementów produktu, który służy dostępowi użytkowników do funkcji i danych produktów. Ważne jest, aby go zaprojektować, ale ograniczony tylko do nich - szkodliwe.

Myth Number 5. Design może również kierować

Menedżer aktywności profilu.

Jak już dowiedzieliśmy, projekt jest złożonym procesem związanym z żmudnymi, drobnymi pracą. Aby projekt spełnić swoje zadania, praca ta musi być wykonana jako wysoka jakość i starannie. Konstrukcja, innymi słowy, wymaga wykonawcy obecności bardzo specyficznego systemu wartości, w przypadku gdy jakość pracy i odpowiedzialność osobistej będzie przede wszystkim.

W tym przypadku projekt jest często w ręku do menedżerów jako ludzie, 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 moment: W. dobrzy menedżerowie Zupełnie inny system wartości, gdzie w głowie są prace projektu i jego budżetu.

W dużych projektach, aw szczególności w rozwoju niestandardowym, gra z menedżerami bardzo zły żart: Jeśli menedżer podnosi się do dylematu, aby rozwiązać problem związany z projektem jako całości (na przykład, pociągnij projektant z Pasza - zupełnie prawdziwa historia, przy okazji lub rozwiązywać problem związany z projektowaniem (bardziej szczegółowo, aby zarejestrować protokół danych w TK), a następnie każdy menedżer wybierze rozwiązanie, które umieści pożary, które są zajęte tutaj i teraz. W rzeczywistości wadliwy TK wpłynie gdzieś w dłuższej perspektywie, ale na czas, że nieugizowany ogień projektu doprowadzi do utraty projektu w tej chwili. I, w końcu, jak mogę cicho napisać TK, kiedy ciągle rozprasza klientów na drobiazgach?

I tak będzie cały rozwój. Jeśli profesjonalny aspekt jest dodany do tego aspektu wartości (przecież, projektant musi być w stanie wiedzieć wiele z faktu, że menedżer nie jest zobowiązany do wiedzy), łatwo jest zrozumieć, dlaczego projekt powinien zajmować się osobnym, specjalnie wyszkolona osoba z jego systemem wartości.

Jedynym wyjątkiem od tej zasady jest rozwój wewnętrzny. W warunkach, gdy menedżer ma jeden projekt, a problem terminów i budżetów nie jest tak ostry, Menedżer może podjąć funkcje projektanta. Prawda, w tym przypadku staje się menedżerem produktu - i jest to oddzielna historia, która zasługuje na jego artykuł.

Mit Numer 6. Psychologowie powinni być zaangażowani w projekt

Treść techniczna produktu według psychologa

Niektóre firmy są do największego - uważa się, że ludzie z edukacją psychologiczną powinni być projektować. Ten mit rośnie z przekonania, że \u200b\u200bprojektant musi bronić wyjątków użytkowników. Jak już dowiedzieliśmy się, to nie jest - projektant jest zaangażowany w cały produkt jako całość i uwzględnia interesy zarówno użytkowników, jak i Klienta, nie wspominając o specyfiki systemu. Wszystko to wymaga umiejętności technicznych, które psychologowie są głównie pozbawione.

Inną rzeczą jest to, że psychologowie można przyciągnąć do wąskiej części projektu - pracować z interfejsami lub analizą preferencji użytkownika, - ale wszystko powinno mieć miejsce pod nadzorem projektanta produktu, który uwzględni wszystkie subtelności techniczne i niuanse.

Mit Numer 7. Projekt musi być zaangażowany w inżynierów

W przeciwieństwie do mitem psychologów, istnieje mit o inżynierach - mówią, że projektant musi być programistą. Jak myślę, że już się domyśliłem, jest też zła opcja - sferyczny programista w próżni jest w stanie myśleć o ogólnej architekturze produktu, ale trudno jest odczuwać wystarczająco dużo użytkowników, aby czuć się wystarczająco dużo i zrozumieć wymagania klient. W rzeczywistości taki deweloperzy natknęli się, ale w swoim magazynie umysłu, dość projektanci, którzy przez nieporozumienia stali się deweloperami.

Podobnie jak w przypadku minionego mitów, deweloperzy mogą być przyciągane do projektowania - ale tylko w strukturze danych i opisy funkcjonalne. Produkt pod nadzorem projektanta (choć, jeśli to konieczne, projektant powinien to zrobić).

Kto jest taki projektant?

Kto powinien być projektantami? To bardzo trudne pytanie, które mogę krótko odpowiedzieć.

• Warto spełnić, że na "odpowiednich" projektantach systemowych nigdzie nie jest nauczany.
• Najczęściej prawidłowy projektant rodzi się na skrzyżowaniu między uwarunkowanymi naukami humanitarnymi i technicznymi.
• Najczęściej dobry projektant nie wie, że jest dobrym projektantem i pracuje po lewej specjalności, że go nie zadowolisz.
• Ten "nie aktywowany" projektant jest rekordem ścieżki schizofrenicznej, niejasnej edukacji, szerokiej gamy i magazynowi dobrego klasycznego inżyniera.
• Projektant musi zrozumieć projektantów, deweloperów, klientów i użytkowników.
• Projektant musi być w stanie komunikować się z ludźmi.

Osobiście moje doświadczenie pokazuje, że projektant jest raczej koncepcją mI.: Nauczanie projektanta z niezbędnymi narzędziami i technikami może być stosunkowo szybko (poważnie, od trzech miesięcy do sześciu miesięcy), ale zainwestować w to Żądany system Wartości i magazyn umysłu jest prawie niemożliwy.

Ale są takie osoby - i było to na ich wyszukiwanie i tworzenie, które stworzyłem gildię wolnych projektantów jednocześnie, a jest to również oddzielny temat do rozmowy.

Unified podejście do projektowania nie istnieje

Projektant nie wytrzymuje blasku pasji na projekcie

Istnieje wiele podejść do projektowania, a niedoświadczony czytelnik może łatwo oszałowiony wbrew obfitości technik, podejść i skrótów, hojnie przekształconej przez terminologicznego Bardaka (wszystkie te UX, UI, CX, HCD i inne IDDQD z Kriva Rosyjski - Mówiąc analogi).

Niektórzy jednak próbują przynieść uniwersalne modele projektowe, ale w końcu okazuje się, że próbując połączyć istniejące 20 (warunkowo) podejść do projektowania, uzyskujemy w wyniku 21 podejścia - a metodologie wydają się być zaczął przygotować się.

Specjaliści pochodzą na tej podstawie, że nie ma pojedynczego podejścia do projektowania i nie może być - mówią, wszystko jest ściśle indywidualnie, a zatem nie ma nic do usystematyzacji.

Jest to również mit, który osobiście nie pasuje do mnie kategorycznie. Istnieje jednolitego podejścia do projektowania, ale wymaga oddzielnej, dużej i bardzo osobistej rozmowy; Tak więc, z pozwoleniem ten mit obróci trochę później - bliżej końca września, kiedy mój duży artykuł na ten temat zostanie wydany na COSSA.

Zamiast więzienia

Więc co znalazłem dzisiaj?

• Projektowanie jest warte ich pieniędzy i pozwala zmniejszyć budżet rozwoju.
• Projekt minimalizuje rozwijające się zagrożenia.
• Projektowanie broni interesów produktu jako całości.
• Projekt powinien być zaangażowany w projektantów (tutaj jest prawda, eh?).
• Projekt jest dużym i złożonym procesem, który ma własne wzorce i jednolite podejścia.
• Nie wierz w to, co piszą o projekcie - nie bój się myśleć, oferują swoje poglądy i bronić swojej wizji.

A ostatni wniosek: nie wierz w słowo nawet dla mnie - będę cieszę się, jeśli nie zgadzasz się ze mną i bronić swojego punktu widzenia: będzie to powód przydatny i dużej rozmowy, podczas której inna prawda może pojawić się - i czy nie jest zdrowy?