Loading...
Oprogramowanie

Jak powstawał interfejs użytkownika w Windows 95?

Proces projektowania Microsoft Windows 95 problemy rozwiązania relacja Kent Sullivan

Niniejszy wpis jest tłumaczeniem treści z socket3.wordpress.com o tytule Designing Windows 95’s User Inteface. Strona z materiałami będącymi inspiracją dla Josha – autora wspomnianego wyżej artykułu, została już usunięta. Z tego też powodu sam twórca określił się mianem internetowego archeologa, który ku mojej radości, jako osoba pragnąca dzielić się wiedzą, zgodził się na przetłumaczenie i umieszczenie tekstu po polsku w przestrzeni Piwnicy.

A zatem, jeśli macie ochotę na podróż w czasie, rozsiądźcie się wygodnie, przygotujcie sobie duży kubek kawy i razem cofnijmy się do grudnia 1992 roku. Dowiecie się jak powstały legendarne elementy interfejsu Windowsa niezmienione po dziś dzień: menu start, pasek zadań, zasobnik systemowy zwany Trayem, kosz, czy kreatory instalacji.

Powłoka dla początkujących

Oryginalny materiał Kenta Sullivana (pracownika Microsoftu, będącego członkiem zespołu projektującego interfejs graficzny Windowsa 95) określał niektóre z napotkanych problemów powłoki Menadżera Programów obecnego w Windows 3.1 i prezentował możliwości stworzenia specjalnej powłoki dla początkujących. Moim zdaniem było to prawdopodobnie zainspirowane alternatywnym pulpitem na Macintosha autorstwa Apple, zwanym At Ease. Powstał on w latach 1992-1993, więc tuż przed premierą Windowsa 95. Był to uproszczony pulpit zaprojektowany w celu zabezpieczenia systemu Macintosha przed zgubnymi działaniami użytkowników i ograniczenia ich do używania tylko wyznaczonych aplikacji. Innymi słowy prawdopodobnie było to coś, czego nikt nie chciał na swoim osobistym pulpicie Macintosha, lecz co było pożądane na komputerach Macintosh używanych w miejscach publicznych takich jak szkoły czy biblioteki.

Poniżej znajdziecie to, co Kent dosłownie przekazał w swoim artykule zatytułowanym “The Windows 95 User Interface: A Case Study in Usability Engineering”.

Przedsięwzięcie

Opracowanie interfejsu użytkownika dla tak ogromnego komercyjnego oprogramowania jak Microsoft® Windows 95 to wielkie przedsięwzięcie, angażujące bardzo wiele osób, szeroki zakres celów projektowych i napięty harmonogram prac. Ten artykułów opisuje w jaki sposób z powodzeniem stosowano zasady inżynierii użyteczności w iteracyjnym projektowaniu (iterative design) i śledzeniu problemów na każdym etapie prac. Dawały one większą kontrolę nad rozbudowanym procesem projektowania UI.

Wprowadzenie

Windows 95 to następca systemów Windows 3.1 i Windows for Workgroups 3.11. W prawie każdym aspekcie systemu wprowadzono wiele zmian, także w interfejsie użytkownika. W niniejszym dokumencie omówione zostały cele i procesy zespołu projektowego, a następnie wyjaśniono, jak zasady inżynierii użyteczności zostały zaimplementowane do projektu podając konkretne przypadki problemowe i ich rozwiązania jako przykłady.

Zespół projektowy

Zespół projektujący interfejs użytkownika systemu Windows 95 powstał w październiku 1992 roku, na wczesnym etapie całego projektu. Dołączyłem do zespołu jako pomocnik w zakresie użyteczności interfejsu w grudniu tego samego roku. Zespół był naprawdę zróżnicowany, składał się z osób doświadczonych w projektowaniu produktu, grafik, testach użyteczności i informatyce. Liczebność zespołu zmieniała się w trakcie trwania projektu, oscylując około dwunastu osób. Deweloperzy odpowiedzialni za implementację interfejsu użytkownika stanowili kolejną dwunastkę.

Cele

Przed zespołem zostały postawione dwa bardzo obszerne cele:

  • Uczynić system łatwiejszym przyswojenia dla osób zaczynających swoją przygodę z komputerami i Windowsem
  • Zaprojektować Windowsa łatwiejszym w użytkowaniu dla osób na co dzień już używających komputerów – zarówno dla użytkowników średniozaawansowanych jak i zaawansowanych

Windows w wersji 3.1 oraz 3.11 był zainstalowany na ponad pięćdziesięciu milionach komputerów, nie wykorzystując jeszcze w pełni rynku komputerów osobistych. Od początku było jasne, że zadanie stworzenia lepszego produktu nie będzie proste. Bez starannego zaprojektowania i testowania nowych rozwiązań prawdopodobnie stworzylibyśmy produkt, który poprawiłby komfort pracy tylko dla niektórych użytkowników, lecz pogorszyłby go dla milionów innych (obecnych, lub potencjalnych). Dość dobrze rozumieliśmy problemy średniozaawansowanych i zaawansowanych użytkowników, ale niewiele wiedzieliśmy o problemach użytkowników początkujących.

Proces

Biorąc pod uwagę bardzo obszerny zakres celów projektu i krótki termin realizacji (około 18 miesięcy na zaprojektowanie i stworzenie kodu interfejsu użytkownika) od razu wiedzieliśmy, że tradycyjny kaskadowy model pracy nie zapewni nam wystarczającej elastyczności w celu osiągnięcia najlepszego możliwego rezultatu. Prawdę mówiąc, obawialiśmy się, że tak tradycyjne podejście przyniesie bardzo nieużyteczny produkt – przeciwieństwo celów jakie przed nami postawiono.

W modelu kaskadowym projekt systemu jest podzielony na sekcje (zwykle ograniczony do opisania specyfikacji), a testy użytkowe odbywają się pod sam koniec procesu, podczas końcowych szlifów. Zdaliśmy sobie sprawę, że potrzebujemy znacznie więcej okazji do wypróbowania projektu z użytkownikami (może porównania z innymi projektami) na każdym etapie produkcji, a także zbierania opinii i wprowadzania zmian na bieżąco. Nasze pragnienie porzucenia kaskadowego modelu pracy i wyboru iteracyjnego na szczęście zgrało się z podobnymi działaniami w innych obszarach firmy, więc mieliśmy konkretne argumenty na jego poparcie.

Projektowanie iteracyjne w praktyce

Grafika przedstawia model pracy, którzy wykorzystaliśmy. Proces był typowy dla większości produktów zaprojektowanych iteracyjnie: pomysły stworzone na papierze lub komputerze przenosiliśmy do laboratorium w celu zebrania danych o użyteczności. Za każdym razem kiedy został stworzony kod, był przenoszony do laboratorium. Po zaprojektowaniu i udoskonaleniu wystarczającej części produktu, był on badany w szerszym zakresie, a z biegiem czasu testowany już na zewnątrz. Drobne problemy użytkowe zidentyfikowane na zewnątrz zostały naprawione jeszcze przed premierą. Co ważniejsze, dane zebrane podczas testów zewnętrznych zostały wykorzystane do prowadzenia prac nad kolejną wersją.

Nasz iteracyjny proces projektowania został podzielony na trzy główne fazy: badanie, szybkie prototypowanie i precyzyjne udoskonalenie.

Iterative Design schemat projektowania iteracyjnego
Rys. 1: Iteracyjny proces projektowania

Faza badania

W pierwszej fazie eksperymentowaliśmy w którym kierunku pójść i gromadziliśmy początkowe dane od użytkowników podczas badań. Rozpoczęliśmy od solidnej podstawy wizualnego projektu interfejsu użytkownika, wykorzystując pracę wykonaną przez zespół Cairo. Odziedziczyliśmy po nich wiele podstawowych interfejsów i projektów interakcji (pulpit, menu Tray, menu kontekstowe, odczucie i wygląd trójwymiaru itp.). Otrzymaliśmy także dane z pomocy technicznej dotyczące dwudziestu najczęstszych problemów użytkowych z Windows 3.1.

Grafika przedstawia prototypowy projekt pulpitu Windowsa 95, który testowaliśmy w styczniu 1993 roku. Ten design powstał w oparciu o pomysły zespołu Cairo i zawierał nasze usprawnienia niektórych znanych problemów z Windows 3.1 (w szczególności zarządzanie oknami).

wczesny projekt pulpitu w Windows 95
Rys. 2 Wczesny pulpit Windowsa 95 (z objaśnieniami).

Pierwsza ikona, czyli File Cabinet, pokazywała widok menedżera plików znanego z Windows 3.1 (lewy panel pokazuje hierarchię, prawy zawartość). Druga ikona – World ukazywała zawartość w sieci. Trzecia ikona Programs była folderem zawierającym inne foldery pełne odnośników do programów znajdujących się na komputerze. W dolnej części znajdował się Tray z trzema przyciskami (System, Find i Help) oraz obszarem do przechowywania plików. Inna ikona, Wastebasket – była folderem zawierającym usunięte pliki.

Badania użyteczności prototypowego pulpitu przeprowadzano w specjalnym laboratorium Microsoftu, tak jak samo jak późniejsze testy. Przeprowadziliśmy typowe iteracyjne badania użyteczności. Trzech do czterech użytkowników reprezentujących każdą odrębną grupę (zazwyczaj początkujący i średniozaawansowani użytkownicy systemu Windows 3.1) wykonywało zadania z wykorzystaniem prototypu. Pytania adresowane do testerów były czasami bardzo ogólne (np. Czy użytkownik lubi to?) a czasami bardzo konkretne (np. Czy po dziesięciu minutach korzystania z systemu użytkownik odkryje przeciągnięcie i upuszczenie w celu skopiowania pliku?). Zebraliśmy dane typowe dla badań iteracyjnych: wypowiedzi użytkowników podczas testów, czasy wykonania zadań, ilość błędów, rodzaje błędów i oceny testerów.

Pierwsze wnioski

Przeprowadzone testy użyteczności tego prototypu ujawniły wiele ciekawych kwestii, w tym kilka niespodzianek:

  • Początkujący i wielu średniozaawansowanych użytkowników było zdezorientowanych dwupanelowym widokiem po kliknięciu na File Cabinet. Nie byli pewni związku pomiędzy panelami i sposobu nawigacji pomiędzy folderami. Początkujący często byli przytłoczeni złożonością wizualną File Cabinet i mieli więcej podstawowych problemów takich jak niezrozumienie, w jaki sposób foldery mogą istnieć w innych folderach. Wielu użytkowników było również zdezorientowanych ikoną folderu nadrzędnego. Pojawiała się ona w każdym folderze i wyglądała jak plik, będąc tak naprawdę kontrolerem nawigacyjnym do przechodzenia do folderu wyżej.
File Cabinet Windows 3.1
Rys. 3: File Cabinet, wczesna przeglądarka plików.
  • Użytkownicy każdej grupy zaawansowania byli zdezorientowani folderem Programs. Myśleliśmy, że posiadanie folderu na pulpicie z innymi folderami i linkami do programów w nim zawartych będzie naturalną zmianą dla użytkowników przyzwyczajonych do Windowsa 3.1 i jego Menedżera Programów, a jednocześnie okaże się stosunkowo łatwe do nauczenia dla początkujących. Myliliśmy się! Początkujący szybko zgubili się we wszystkich folderach (w przeciwieństwie do File Cabinet każdy folder otworzył się w innym oknie), a pozostali mieli problem z decyzją, czy oglądają rzeczywisty system plików i jego zawartość, czy tylko linki do rzeczywistych plików.
  • Użytkownicy mieli znaczną trudność w określeniu do czego służy każdy z trzech przycisków znajdujących się w Trayu, kłopot sprawiał im także wybór odpowiedniej komendy, ponieważ ich funkcję często były niejednoznaczne (np. aby znaleźć coś w pomocy klikniesz w wyszukaj czy pomoc?).

Porównanie z Windows 3.1

Wraz z dokonaniem pierwszych badań laboratoryjnych stało się jasne, że potrzebowaliśmy punktów odniesienia do Windowsa 3.1, aby lepiej zrozumieć jakie problemy istniały przed Windows 95, a jakie były unikalne dla nowego projektu. Najpierw zgromadziliśmy dane z badań rynkowych o dwudziestu najczęściej wykonywanych zadaniach przez użytkowników Windowsa 3.1. Następnie przeprowadziliśmy kilka badań porównujących Windows 3.1 z Windowsem 95 pod względem wykonywania dwudziestu najczęstszych zadań wynikających z wcześniej zebranych danych. Przeprowadziliśmy także wywiady z profesjonalnymi trenerami Windowsa 3.1 (i Macintosha, dla porównania), aby dowiedzieć się, co jest łatwe i trudne do przyswojenia pod względem obsługi systemu operacyjnego.

Kluczowe wnioski były następujące:
  • Początkujący użytkownicy Windowsa 3.1 potrzebowali średnio 9,5 minuty, aby zlokalizować i otworzyć program, który nie był od razu widoczny. Rezultaty nie były o wiele lepsze dla naszego prototypu Windowsa 95. Wyniki te były niedopuszczalne, biorąc pod uwagę, że uruchomienie programu było zadaniem numer jeden użytkownika, co również wynikało z badań.
  • Początkujący i niektórzy średniozaawansowani użytkownicy mieli duże problemy z używaniem myszy, szczególnie z podwójnym kliknięciem. W rezultacie często nie znajdowali zawartości folderów, gdy jedynym sposobem ich otwarcia było właśnie podwójne kliknięcie.
  • Początkujący i wielu zaawansowanych polegało wyłącznie na wizualnych wskazówkach, aby wykonać daną akcję. Polegali oni (i intuicyjnie odnajdywali) paski menu i narzędzi, ale nie używali menu kontekstowych ani okienek pop-up, nawet po przeszkoleniu.
  • Wszyscy, oprócz najbardziej zaawansowanych użytkowników nie rozumieli jak efektywnie zarządzać nachodzącymi na siebie oknami. Początkujący mieli największe problemy – kiedy minimalizowali okno, uważali, że zniknęło jeśli zostało zasłonięte przez inne. Słyszeliśmy wiele historii od szkoleniowców (i świadków w laboratorium) w jaki sposób użytkownicy doprowadzali do tego, że komputerowi brakowało pamięci RAM. Uruchamiali oni wiele kopii tego samego programu, zamiast przełączać z powrotem na pierwszą uruchomioną kopię. Użytkownicy średniozaawansowani byli bardziej biegli w obsłudze, ale nadal mieli problemy, zwłaszcza z aplikacjami obsługującymi wiele dokumentów (MDI) takimi jak Program Manager czy Microsoft Word. Dane z badań potwierdziły ten problem, pokazując, że 40% średniozaawansowanych użytkowników systemu Windows nie uruchomiło więcej niż jednego programu na raz, ponieważ mieli problem jak to zrobić.
  • Początkujący użytkownicy byli oszołomieni hierarchicznym systemem plików. Średniozaawansowani potrafili poruszać się w hierarchii, ale często tylko powierzchownie. Co ciekawe zazwyczaj zapisywali wszystkie swoje dokumenty w domyślnej ścieżce podanej przez program, którego używali. Ten problem (zwłaszcza przypadek początkujących) był także zaobserwowany wśród użytkowników komputerów Macintosh.

Zmiana kierunku

Rezultaty tych badań i wywiadów znacznie zmieniły kierunek rozwoju interfejsu użytkownika systemu Windows 95. We wczesnym prototypie Windows 95 celowo zmieniliśmy niektóre rzeczy z Windows 3.1 (np. pulpit był teraz prawdziwym folderem) ale nie wszystkie (np. Menedżer plików i Menedżer programów – tak jak ikony na pulpicie) ponieważ obawialiśmy się odejścia zbyt daleko z designem. Zdawaliśmy sobie sprawę, że stworzenie produktu radykalnie różniącego się od systemu Windows 3.1 mogłoby zdezorientować i rozczarować miliony obecnych użytkowników, co było całkowicie niedopuszczalne.

Niemniej dane zebrane na temat naszego prototypu Windowsa 95 i Windowsa 3.1 pokazały nam, że nie możemy kontynuować bieżącego kierunku rozwoju. Wyniki początkujących użytkowników podczas wykonywania podstawowych zadań były niedopuszczalnie słabe, a wielu średniozaawansowanych uważało, że Windows 95 był po prostu inny, ale nie lepszy.

Postanowiliśmy się cofnąć i przez kilka dni zastanowić nad całą sytuacją. Zespół projektowy przeniósł się poza siedzibę firmy i analizował wszystkie zebrane do tej pory dane: badania użyteczności, wywiady z testerami, badania rynku i informacje o wsparciu produktu. Gdy omawialiśmy zebrane dane, zdaliśmy sobie sprawę, że musimy skupić się na najczęściej wykonywanych przez użytkowników zadaniach. Uświadomiliśmy sobie również, że zbytnio skupiliśmy się na spójności systemu z Windowsem 3.1.

Zasadniczo uzmysłowiliśmy sobie, że nowe rozwiązania nie muszą wyglądać, ani działać jak Windows 3.1, ale zapewnić wystarczającą wartość, aby być atrakcyjnymi dla użytkowników na różnych stopniach zaawansowania. Pomyśleliśmy, że naprawdę użyteczny system będzie skalowalny w zależności od potrzeb różnych grup użytkowników. Taki system powinien być łatwy do opanowania, jednocześnie zapewniając większą efektywność (dzięki skrótom i alternatywnym sposobom obsługi) bardziej zaawansowanym użytkownikom.

Faza szybkiej iteracji

Gdy zaczynaliśmy pracę nad nowymi rozwiązaniami, mieliśmy nadzieję uniknąć klasycznego paradoksu łatwego do przyswojenia, ale trudnego w użyciu, pamiętając, że podstawowe funkcje interfejsu użytkownika muszą skalować. Aby osiągnąć ten cel, wiedzieliśmy, że potrzebujemy szybko wypróbować wiele różnych pomysłów, porównać je i powtarzać te, które wydawały się najbardziej obiecujące. Żeby to zrobić, musieliśmy uczynić nasze procesy projektowania i oceny bardzo efektywnymi.

Specyfikacja procesu ewolucji UI

Mimo, że od samego początku zdecydowaliśmy się na iteracyjne podejście do projektowania, pozostało jedno dziedzictwo kaskadowego modelu pracy: monolityczna specyfikacja projektu („spec”). W ciągu kilku pierwszych miesięcy projektu specyfikacja wzrastała skokowo, odzwierciedlając setki godzin ludzkiej pracy. Jednocześnie ze względu na odkryte problemy podczas testów użytkowników, projekt udokumentowany w tej specyfikacji nagle okazał się przestarzały. Zespół stanął przed poważną decyzją: spędzić tygodnie nad zmianą specyfikacji, aby udokumentować nowe pomysły i stracić cenny czas na iterację, lub przestać aktualizować specyfikację i użyć prototypów oraz stworzonych kodów jako „żywej” specyfikacji.

Lepsze rozwiązanie

Po kilku debatach zespół zdecydował się na drugie rozwiązanie. Chociaż ta zmiana utrudniała grupom zewnętrznym śledzenie tego, co robimy, umożliwiała nam znacznie szybszą iterację. Zmiana przyniosła również nieoczekiwany efekt – zbliżyła cały zespół, ponieważ wiele szczegółów omawianych było w codziennych rozmowach, lub znajdowały się na białych tablicach w biurach poszczególnych pracowników. Wiele pomysłów przynosiły zwykłe rozmowy na korytarzu podczas trwania całego projektu.

Aby zapewnić stały dostęp do informacji dla zainteresowanych naszym projektem, postanowiliśmy:

  1. Odbywać regularne spotkania dla zespołu projektowego. Te cotygodniowe (a czasem nawet częstsze) spotkania pozwalały każdemu z nas na sprawdzenie etapu na którym jesteśmy, a także na dyskusję jak praca jednej osoby wpływała na postęp innej.
  2. Przesyłać harmonogramy testów i ich wyniki przy pomocy poczty e-mail. Członkowie zespołu projektowego regularnie otrzymywali powiadomienia na temat nadchodzących testów użyteczności, a także ich późniejsze rezultaty. Dzięki temu mogli łatwiej śledzić na bieżąco informacje na temat użyteczności coraz to nowszych wersji.
  3. Formalnie śledzić kwestie użyteczności. Podczas projektu tak wielkiego jak Windows 95, wiedzieliśmy, że potrzebujemy ustandaryzowania śledzenia postępów prac. Musieliśmy notować wszystkie zidentyfikowane problemy związane z użytecznością, odnotowywać jak i kiedy mają zostać naprawione, a następnie zamknąć je, gdy poprawka zostanie wdrożona i pomyślnie przetestowana z użytkownikami. Ten proces jest szerzej omówiony w rozdziale Śledzenie otwartych problemów.
  4. Organizować regularne prezentacje designu dla grup zewnętrznych. W miarę jak projekt rósł w siłę coraz więcej grup (w Microsofcie oraz poza nim) chciało się dowiedzieć nad czym pracujemy, więcej pokazywaliśmy i demonstrowaliśmy im nasze postępy. Prezentacje były skuteczniejsze niż wydawanie dokumentów, ponieważ nadążały za dynamicznym postępem prac, a także pozwalały na dyskusje just-in-time na temat projektu.
Oddzielny interfejs dla początkujących

Pierwszym ważnym kierunkiem naszych prac, był osobny interfejs (shell) dla początkujących użytkowników. Projekt został prędko wymodelowany w Visual Basic i przetestowany w laboratorium użyteczności. Chociaż testy wypadły obiecująco, ponieważ interfejs skutecznie hamował działania użytkownika do małego zestawu czynności, szybko zaczęliśmy dostrzegać ograniczenia w miarę testowania przez większą liczbę użytkowników:

  1. Jeśli tylko jedna funkcja, której potrzebował użytkownik nie była obsługiwana w powłoce dla początkujących, musiałby ją porzucić (przynajmniej tymczasowo).
  2. Zakładając, że większość użytkowników zdobędzie doświadczenie i zechce opuścić powłokę dla początkujących, wiedza, którą nabyli niekoniecznie przeniesie się do standardowej powłoki.
  3. Interfejs dla początkujących nie był podobny do programów uruchamianych przez użytkowników (edytory tekstu, arkusze kalkulacyjne itp.). W rezultacie użytkownicy musieli nauczyć się dwóch różnych procesów interakcji z komputerem, co było dla nich mylące.
Częściowy widok oddzielnej powłoki dla początkujących
Rys. 4: Częściowy widok oddzielnej powłoki dla początkujących.

Z tych i innych powodów postanowiliśmy zrezygnować z idei interfejsu dla początkujących. Co ważne, z powodu użycia przez nas narzędzia do prototypowania i szybkiego przetestowania pomysłu w laboratorium użyteczności, wciąż mieliśmy mnóstwo czasu na zbadanie innych kierunków rozwoju.

Przykłady szybkiej iteracji

Poniżej znajdziecie omówienie pięciu obszarów wokół których zaprojektowaliśmy i przetestowaliśmy trzy lub więcej wersji zanim stworzyliśmy finalną. Takich obszarów jest oczywiście o wiele więcej, ale to już materiał na osobną książkę a nie jeden wpis.

  1. Uruchamianie programów: Menu Start. Pomimo porzucenia pomysłu na oddzielną powłokę dla początkujących, udało nam się uratować jej najważniejsze funkcjonalności: dostęp po jednym kliknięciu, przejrzysta widoczność i interakcja oparta o menu. Stworzyliśmy szereg modeli naszego pomysłu i przetestowaliśmy je z użytkownikami o różnym stopniu zaawansowania, ponieważ wiedzieliśmy, że dane rozwiązanie musi być intuicyjne dla użytkowników na wszystkich poziomach zaawansowania. Grafika przedstawia finalne Menu Start z otwartym podmenu Programy. Ostateczna wersja zawiera także inne funkcje poza uruchamianiem programów, dając użytkownikom intuicyjny punkt odniesienia w interfejsie systemu.

    Projekt menu start w Windows 95
    Rys. 5: Menu Start z otwartym podmenu Programy.
  2. Zarządzanie Oknami: Pasek Zadań. Nasz pierwszy pomysł na zaprojektowanie tego elementu nie był zbyt ambitny, ale nie byliśmy pewni, ile pracy wymagało rozwiązanie problemu. Pierwszy projekt polegał na zmianie wyglądu zminimalizowanych okien z ikon na płytki. Mieliśmy nadzieję, że problem zostanie rozwiązany, nadając zminimalizowanym oknom charakterystyczny wygląd i zwiększając ich rozmiar. Myliliśmy się! Użytkownicy mieli prawie tyle samo problemów, co w systemie Windows 3.1. Nasze wyniki badań pokazały, że głównym problemem była niewidoczność okien przez cały czas, więc użytkownicy nie mogli szybko zobaczyć, co mają otwarte lub uzyskać szybkiego dostępu do zadań. Te wnioski szybko doprowadziły nas do projektu paska zadań, ukazanego na grafice poniżej. Każde zadanie ma własną przestrzeń na pasku zadań, który pozostaje zawsze widoczny. Późniejsze testy użytkowników potwierdziły, że było to realne rozwiązanie problemu.
    Wizualizacja zminimalizowanego okienka
    Rys. 6: Płytka – wizualizacja zminimalizowanego okienka.

     

    Pasek zadań z menu start, programami i zegarem
    Rys. 7: Pasek zadań z przyciskiem Start, programami i zegarem.
  3. Praca z Plikami: komunikaty Otwórz i Zapisz jako. Informacje z działu wsparcia produktu i testów laboratoryjnych wskazały nam, że początkujący i średniozaawansowani mieli problemy korzystając z dostarczanych przez system okien komunikujących o otwarciu i zapisaniu plików. Problemy wynikały z tego, że pola dialogowe nie były w logicznej kolejności i miały skomplikowaną metodologię wyboru. Zespół Cairo przejął inicjatywę dotyczącą tego problemu i stworzył kompleksowy prototyp w Visual Basic, zawierający symulowany system plików. Testowaliśmy wiele wariantów, aż dotarliśmy do ostatecznego projektu pokazanego na grafice poniżej..praca z plikami komunikaty otwórz i zapisz jakopraca z plikami komunikaty otwórz i zapisz jako
  4. Drukowanie: Kreator Instalacji. Dowiedzieliśmy się od działu wsparcia produktu, że proces instalacji i konfiguracji drukarek był najczęstszym powodem telefonów użytkowników. Wiele z tych problemów było spowodowanych interfejsem użytkownika procesu instalacji. Szukanie właściwej drukarki było utrudnione, ponieważ wszystkie modele znajdowały się na jednej długiej liście. Wybór portu dla drukarki, szczególnie w środowisku sieciowym, wymagał tunelowania w dół o 4-5 poziomów i charakteryzował się nietypowym i skomplikowanym zachowaniem danego wyboru. Mniej więcej od czasu, kiedy zaczęliśmy pracować nad tym problemem, członkowie zespołu projektowego rozpoczęli badania nad kreatorami instalacji, poszukując rozwiązania tego wieloetapowego, rzadko wykonywanego przez użytkowników zadania. Instalacja drukarki pasuje idealnie do tej definicji, a finalny kreator dał bardzo dobre wyniki w testach użytkowników. Ekran wyboru drukarki z finalnego kreatora ukazany jest na grafice poniżej.Kreator instalacji drukarek w Windows 3.1Kreator instalacji drukarek w Windows 95
  5. Uzyskiwanie pomocy: Okno dialogowe/karta Indeks. Testy laboratoryjne Windowsa 3.1 wykazały, że użytkownicy mieli problem z oknem wyszukiwania w Pomocy. Użytkownicy mieli trudności ze zrozumieniem, że okno dialogowe było dwuczęściowe. Musieli wybrać coś z pierwszej listy, a następnie z drugiej, używając do tego różnych przycisków. Wypróbowaliśmy kilka pomysłów zanim stworzyliśmy finalną zakładkę Indeks. Zawierała ona tylko jedną listę, a słowa kluczowe z więcej niż jednym tematem generują dynamiczny spis, z którym użytkownicy nie mają już żadnego problemu.Okno uzyskiwania pomocy dotyczącej użytkowania systemu w Windows 3.1Okno uzyskiwania pomocy dotyczącej użytkowania systemu w Windows 95

Faza precyzyjnego udoskonalania

Po zaprojektowaniu wszystkich głównych obszarów produktu, zdaliśmy sobie sprawę, że musimy się cofnąć i sprawdzić, jak wszystkie elementy do siebie pasują. Aby to osiągnąć, przeprowadziliśmy podsumowujące próby laboratoryjne i długie badania kierunku projektu, który obraliśmy.

  • Podsumowujące testy laboratoryjne. Korzystając z wiedzy o dwudziestu najczęściej wykonywanych przez użytkowników zadaniach, przeprowadziliśmy testy nowego kompletnego UI. Użytkownicy o różnym stopniu zaawansowania wykonywali identyczne zestawy zadań, oceniając łatwość nauki nowych rozwiązań i obsługi systemu już po zapoznaniu się z nowym interfejsem. Porównaliśmy te czynniki z Windowsem 3.1 jako punktem odniesienia. Po pilotażowych testach wewnętrznych aby rozpracować problemy z procedurami, test został przeprowadzony przez zewnętrzną firmę, którego rezultaty mogły być użyte w białej księdze. Wyniki były bardzo obiecujące – użytkownicy ukończyli zadania o połowę szybciej, aniżeli w Windows 3.1. Odczuwali także większą satysfakcję podczas korzystania z Windows 95 w 20 z 21 ankietowanych kategorii.
  • Badania szeroko zakresowe. Używając finalnej wersji beta Windowsa 95, przeprowadziliśmy szerokie, dwudziestoosobowe badanie. Wpierw sprawdziliśmy jak użytkownicy pracowali na Windowsie 3.1, po czym przyjrzeliśmy się jak konfigurowali Windowsa 95. Powtórzyliśmy to po tygodniu i miesiącu, w celu zmierzenia stopnia opanowania systemu i zmian w sposobie jego używania po pewnym czasie. Nie napotkaliśmy żadnych istotnych uchybień w użyteczności produktu, ale udało nam się poprawić sformułowania w interfejsie użytkownika i tematach pomocy. Niektóre z zebranych danych zostały użyte przy planowaniu kolejnej wersji systemu Windows, a także przez dział wsparcia produktów jako lista rzeczy, na które trzeba zwracać uwagę przyjmując zgłoszenia od użytkowników.

Śledzenie otwartych kwestii

Przez cały okres projektowania i testowania interfejsu użytkownika Windows 95 stosowaliśmy różne zasady i metody inżynierii użyteczności. Przy projekcie wielkości Windowsa 95, wiedzieliśmy, że potrzebujemy ustandaryzowania procesu odnotowywania wszystkich zidentyfikowanych problemów związanych z użytecznością, określania kiedy i jak mają zostać naprawione, a następnie zamknąć daną kwestię po wdrożeniu i przetestowaniu określonej poprawki.

Aby sprostać tym potrzebom, zaprojektowaliśmy relacyjną bazę danych. Po każdej fazie testów laboratoryjnych dodawałem nowe problemy, a także proponowane rozwiązania i przypisywałem je odpowiednim osobom – zazwyczaj projektantowi danego rozwiązania i testerowi. Statusy istniejących problemów były również na bieżąco aktualizowane – pozostawiano je otwarte gdy wymagały większego wkładu pracy, lub zamykano, jeżeli udało się je rozwiązać. Co kilka tygodni wyciągałem z bazy danych serię raportów i drukowałem wszystkie otwarte statusy według danych osób i rozsyłałem je członkom zespołu. Spotykaliśmy się w celu omówienia postępów w zakresie rozwiązań otwartych problemów i ustalenia, kiedy poprawione rozwiązania będą gotowe na testy użytkowników.

Baza danych zgłoszeń dotyczących problemów z interfejsem
Rys. 14: Jeden z rekordów bazy danych
Zgłoszenie dotyczące problemu z interfejsem
Rys. 15: Jeden z rekordów bazy danych.

Karta raportu

Tak jak w przypadku każdego projektu, dowody są w statystykach, więc ich udostępnienie jest niezbędne.

Testy laboratoryjne

Przeprowadziliśmy 64 fazy testów laboratoryjnych, w których brało udział 560 osób. Pięćdziesiąt procent użytkowników Windows 3.1 było na poziomie średniozaawansowanym; reszta była początkująca, zaawansowana a także używała innych systemów operacyjnych. Liczby te nie obejmują testów wykonanych na rozwiązaniach dostarczanych nam przez inne zespoły (Klient poczty e-mail Exchange, oprogramowanie Faksu itp.) Testowanie tych rozwiązań obejmowało około 25 faz i 175 użytkowników.

Identyfikacja problemu

W przypadku podstawowych komponentów powłoki interfejsu w trakcie projektu wprowadzono do bazy danych 699 różnych ustaleń użyteczności. Z tej liczby 148 było pozytywnymi wnioskami, natomiast 551 problemami do rozwiązania. Problemy postanowiliśmy ocenić w trzystopniowej skali ważności:

  • Poziom 1: Użytkownicy nie mogli kontynuować zadania lub serii zadań z powodu problemu.
  • Poziom 2: Użytkownicy mieli znacznie utrudnione wykonanie zadania lub serii zadań, ale ostatecznie możliwa była kontynuacja.
  • Poziom 3: Użytkownicy mieli niewielką trudność w wykonaniu zadania lub serii zadań

Z 551 zidentyfikowanych problemów 15% zostało ocenione jako poziom 1, 43% to poziom 2 i 42% na poziomie 3.

Rozwiązanie problemu

Podczas projektu ustaliliśmy pięć rodzajów rozwiązania problemu:

  1. Zaadresowany. Zespół naprawił i pomyślnie przetestował rozwiązanie z użytkownikami.
  2. Zespół zaprojektował rozwiązanie problemu i oczekiwał na jego zaimplementowanie.
  3. Niezdecydowany. Zespół nie jest pewny czy rozwiązał problem lub poprawka jest możliwa.
  4. Poniekąd. Zespół zaprojektował i pomyślnie przetestował poprawkę z użytkownikami, lecz ciągle pozostawały jakieś kwestie do rozgryzienia.
  5. Zespół nie jest w stanie rozwiązać problemu.

Pod koniec projektu, wszystkie problemy z przypisanym rodzajem zaplanowany lub niezdecydowany zostało przeniesione do jednej osobnej kategorii. 81% problemów zostało zaklasyfikowanych jako Zaadresowane, 8% jako Poniekąd i 11% jako Niezaadresowane. Większość Niezaadresowanych było spowodowanych ograniczeniami sprzętowymi lub napiętym harmonogramem.

Konkluzja

Projekt systemu Windows 95 był dla wielu członków zespołu pierwszym doświadczeniem w zakresie projektowania iteracyjnego, tak dokładnego testowania użyteczności i śledzenia problemów.

Projektowanie iteracyjne

Najlepszym dowodem na naszą wiarę w iteracyjny sposób projektowania jest to, że żaden nawet najmniejszy detal początkowej wersji interfejsu użytkownika dla Windowsa 95 nie przetrwał niezmieniony do finalnej wersji. Na początku procesu projektowania, nie wyobrażaliśmy sobie tak ogromnego zakresu i wielkości zmian, które koniec końców wprowadziliśmy.  Projektowanie iteracyjne, używanie prototypów i produktu jako specyfikacji, oraz ciągłe testowanie nowych koncepcji z użytkownikami, pozwoliło nam błyskawicznie znajdować i badać rozwiązania problemów.

Zespół projektowy tak bardzo przywyknął do iteracyjnego sposobu projektowania, że w okolicach końca projektu złapaliśmy zadyszkę śpiesząc się z ostatnimi poprawkami. Nie mieliśmy już czasu na powtarzanie testów więcej niż raz. Byliśmy bardzo rozczarowani, że nie zdążymy kontynuować dopracowywania i ponownego testowania projektu.

Proces specyfikacji

Podejście prototyp albo kod jest specyfikacją ogólnie działało całkiem nieźle, chociaż oczywiście udoskonaliliśmy ten proces po pewnym czasie. Na przykład, wszystkie prototypy danej wersji produktu były umieszczane w naszej sieci i zawierały instrukcje dotyczące ich instalacji i uruchomienia.

Zespół projektowy kontynuuje opracowywanie wstępnych dokumentów specyfikacyjnych i rozpowszechnia je w celu uzyskania wstępnnych opinii zwrotnych. Z każdym stworzeniem i przetestowaniem prototypu specyfikacja odsyła czytelnika do jego uruchomienia w celu uzyskania szczegółowych informacji. Odkryliśmy, że prototyp jest bogatszą wersją specyfikacji, wymagającą mniejszej ilości pracy, ponieważ ma inne zastosowania (testy użyteczności, wersje demo, itp.) Prototyp zachęca także do obszerniejszych opinii zwrotnych, ponieważ testujący mniej wyobraża sobie jak działa system, a bardziej doświadcza.

Testy użyteczności

Chociaż projektowanie i równoczesne testowanie pozwoliło nam stworzyć użyteczne sposoby wykonywania najczęstszych zadań, a także doskonalić produkt, to dopiero całościowe testy systemu były kluczem do poprawienia szczegółów pomiędzy częściami interfejsu.

Jak już wspomniano wcześniej, wprowadziliśmy zmiany w słownictwie interfejsu użytkownika a także w tematach modułu pomocy bazując na zebranych danych. Gdybyśmy tego nie zrobili, ogólne doświadczenia użytkowników z produktem byłyby mniej twórcze i atrakcyjne.

Śledzenie problemów

Tak dobre wyniki poprawiania błędów użyteczności nie byłyby możliwe bez wielkiego poświęcenia wszystkich członków zespołu. Dzięki naszej bazie danych wszystkich zgłaszanych problemów cały proces był łatwiejszy w zarządzaniu i gwarantował, że żaden z problemów nam nie umknie. Niemniej, gdyby zespół nie był tak oddany wizji stworzenia jak najbardziej użytecznego produktu, nie udało by się stworzyć tak wielu poprawek. Kluczem tego przekonania było zrozumienie przez nas, że prawdopodobnie nie uda nam się od razu stworzyć doskonałego interfejsu, a sam proces jego udoskonalania po tak wielu testach również może być bardzo pasjonujący.

W naszej bazie danych wszystkie problemy oznaczone jako Niezaadresowane i Poniekąd zostały przeniesione do nowo utworzonej bazy danych, jako punkt wyjścia do prac projektowych nad następną wersją systemu Windows. Projektanci produktu i osoby odpowiedzialne za design pracowali codziennie, a także przetwarzali raporty z działu wsparcia produktu.

Bibliografia

  1. Dumas, J. S. and Redish, J. C. (1993). A Practical Guide to Usability Testing(pp. 324-325). Norwood, NJ: Ablex Publishing Company.
  2. Nielsen, J. (1993). Usability Engineering. San Diego, CA: Academic Press, Inc.
  3. Usability Sciences Corporation. (1994).Windows 3.1 and Windows 95 Quantification of Learning Time & Productivity. (dostępne na http://www.microsoft.com/windows/product/html.)
  4. Whiteside, J. L., Bennett, J, & Holtzblatt, K. (1988). Usability Engineering: Our Experience and Evolution. In M. Helander (Ed.), Handbook of Human-Computer Interaction(pp. 791-817). Amsterdam: Elsevier Science Publishers, B. V.
  5. Wiklund, M. E. (1994). Usability in Practice: How Companies Develop User-Friendly Products. Cambridge, MA: Academic Press, Inc.