Wprowadzanie lepszego procesu projektowania do Twojej organizacji

Jako projektanci i badacze doświadczeń użytkownika (UX) najczęstszą skargą, jaką słyszymy od użytkowników, jest:

„Dlaczego nie pomyślą o tym, czego potrzebuję?”

W rzeczywistości wiele organizacji ma zespoły zajmujące się dostarczaniem tego, czego potrzebują użytkownicy i klienci. Coraz więcej programistów chętnie współpracuje z projektantami UX w celu tworzenia interfejsów, które klienci będą używać i rozumieć. Problem polega na tym, że złożone projekty oprogramowania mogą łatwo ugrzęznąć w konkurencyjnych priorytetach i niejasności co do tego, co dalej.

Rezultatem jest kiepski projekt, który utrudnia produktywność. Na przykład, efektywność w opiece zdrowotnej jest utrudniona przez elektroniczną dokumentację medyczną (EMR). Skargi na te systemy oprogramowania są niezliczone. Dr Steven Ugent, dermatolog z Bostonu i absolwent Yale Medical School, nie jest wyjątkiem.

Od 2010 r. dr Ugent używał dwóch systemów EMR: Przed 2010 r. kończył pracę punktualnie o 5:15 każdego dnia. Ponieważ on i jego koledzy zaczęli używać EMR, zazwyczaj pracuje dodatkowe pół godziny do 1,5 godziny wieczorem. „Nie znam żadnego lekarza, który byłby zadowolony ze swojego systemu dokumentacji medycznej. Szaloną rzeczą jest to, że byłam znacznie bardziej wydajna, kiedy używałam długopisu i papieru”.

Systemy EMR są niezgrabne, nieelastyczne i trudne do dostosowania. Na przykład Ugent nie może umieszczać zdjęć bezpośrednio w swoich notatkach na wykresie. Zamiast tego musi otworzyć folder ze zdjęciem kreta, a następnie otworzyć inny folder, aby zobaczyć tekst. Ta konfiguracja jest szczególnie kłopotliwa dla dermatologów, którzy podczas leczenia pacjentów w dużym stopniu polegają na zdjęciach.

Ugent zwięźle podsumowuje problem z EMR:

„Ludzie, którzy go projektują [system EMR], nie rozumieją mojego przepływu pracy. Gdyby to zrobili, zaprojektowaliby inny system”.

Lekarze nie są sami w swojej frustracji z powodu niezgrabnego oprogramowania. Konsumenci i profesjonaliści na całym świecie składają podobne skargi:

„Dlaczego nie mogę znaleźć tego, czego potrzebuję?”

„Dlaczego tak to utrudniają?”

„Dlaczego muszę tworzyć login, skoro po prostu chcę kupić ten produkt. Daję im pieniądze. Czy to nie wystarczy?

Głównym czynnikiem przyczyniającym się do niezgrabnego oprogramowania są wadliwe procesy projektowe. W tym artykule przedstawimy cztery problemy związane z procesem projektowania i wyjaśnimy, jak je rozwiązać.

1. Złożoność
2. Zespół następnej wersji
3. Za mało czasu na iteracje projektowe
4. Przekazanie kontroli zewnętrznym dostawcom

1. Złożoność

Skala, wielu interesariuszy i potrzeba zaawansowanego kodu to jedne z wielu czynników przyczyniających się do złożoności dużych projektów oprogramowania.

Czasami jednak pomijane są skomplikowane przepisy i regulacje. Na przykład ubezpieczenia są silnie regulowane na poziomie stanowym, co dodaje warstwę złożoności dla firm ubezpieczeniowych działających w wielu stanach. Banki i spółdzielcze kasy pożyczkowe podlegają regulacjom, podczas gdy przedsiębiorstwa użyteczności publicznej muszą przestrzegać stanowych i federalnych przepisów dotyczących ochrony środowiska.

Produkty medyczne i oprogramowanie podlegające przepisom FDA stanowią jeszcze większe wyzwanie. Problem nie w tym, że przepisy są nierozsądne. Bezpieczeństwo jest najważniejsze. Kwestie to czas, budżet i planowanie niezbędne do spełnienia wymagań FDA.

Jak wyjaśnia dr Jeff Horvath, konsultant ds. UX z dużym doświadczeniem w opiece zdrowotnej: „Wymagania te dodają kilka rzędów wielkości do rygoru pisania protokołów testów, konfiguracji testów, gromadzenia danych, analiz, kontroli jakości i uzyskanie zgody na przeprowadzenie badań w pierwszej kolejności.” Na przykład pojedyncza runda testów użyteczności przeskakuje z sześciu tygodni (rozsądne ramy czasowe dla standardowego testu użyteczności) do sześciu miesięcy. I to w ramach jednej rundy testów użyteczności . Często konieczne są dwie lub więcej rund testów.

Ten poziom rygoru jest sygnałem ostrzegawczym dla firm, które dopiero zaczynają współpracować z FDA. Horvath niejednokrotnie miał do czynienia z trudnymi rozmowami z klientami, którzy nie byli przygotowani na wydłużone terminy i dodatkowy budżet niezbędny do spełnienia wymagań FDA. To trudne, ale konieczne. „Opłaca się być dokładnym” — mówi Horvath. W 2018 roku FDA zatwierdziła zaledwie 11% zgłoszeń przed wprowadzeniem na rynek.

Wymagania stawiane naukowcom, projektantom i programistom są wyższe w przypadku oprogramowania medycznego wymagającego zgodności z FDA niż w przypadku tradycyjnych produktów programowych. Na przykład:

• Badacz UX może przeprowadzić tylko jedną lub dwie sesje testów użyteczności dziennie, w przeciwieństwie do bardziej powszechnych od pięciu do sześciu sesji dziennie w przypadku standardowego oprogramowania.
• Projektanci UX muszą zwracać szczególną uwagę na każdy aspekt interakcji użytkownika z oprogramowaniem. Nawet jedna myląca interakcja może spowodować, że lekarz popełni błąd, który może zagrozić zdrowiu pacjenta. Z tego samego powodu projektanci interfejsu użytkownika muszą rysować interfejsy, które pozostają wierne każdej interakcji.
• Dłuższe ramy czasowe projektowania i testowania użyteczności oznaczają, że wysiłki programisty muszą być starannie zaplanowane. Doświadczeni programiści i mający dobre intencje często chętnie zmieniają kod, gdy tylko pojawią się nowe informacje. Chociaż takie podejście może działać w organizacjach, które są dobrze praktykowane w szybkiej iteracji, niesie ze sobą ryzyko podczas projektowania i kodowania złożonych systemów.

Niepowodzenie w radzeniu sobie ze złożonością może mieć fatalne konsekwencje, jak to miało miejsce, gdy Danielle McCray została przyjęta do szpitala Tallahassee Memorial Hospital, gdy miała urodzić. Aby złagodzić jej dyskomfort, pracownicy służby zdrowia podłączyli ją do kontrolowanej przez pacjenta aparatu przeciwbólowego, programowalnej pompy infuzyjnej.

Osiem godzin później stwierdzono, że McCray zmarł z powodu przedawkowania morfiny. Głównym czynnikiem tej tragedii była wadliwa konstrukcja pompy infuzyjnej używanej do podawania leków. Pompa wymagała 27 kroków programowania. Niezajęcie się taką złożonością poprzez zaprojektowanie bardziej intuicyjnego interfejsu użytkownika przyczyniło się do niepotrzebnej śmierci.

Rozwiązanie

Rozwiązaniem jest uznanie i zajęcie się złożonością Ten punkt brzmi logicznie. Jednak, jak wyjaśniono powyżej, skomplikowane przepisy FDA często zaskakują liderów firm. Odmowa nie działa. Brak planowania oznacza, że ​​Twoja organizacja prawdopodobnie wpadnie w 89% zgłoszeń przed wprowadzeniem na rynek, które FDA odrzuciła w 2018 roku.

Przeprowadzając testy użyteczności, badacze doświadczeń użytkowników muszą podjąć trzy kroki, aby zarządzać złożonością związaną z przepisami FDA:

1. Moderator (osoba przeprowadzająca test użyteczności) musi być bardzo uważny. Na przykład, jeśli skan MRI wymaga od technika ścisłego przestrzegania sekwencji kroków podczas korzystania z powiązanego oprogramowania, moderator musi uważnie obserwować, czy uczestnik postępuje zgodnie z instrukcjami co do joty. Jeśli nie, zadanie jest oceniane jako niepowodzenie, co oznacza, że ​​zarówno projekt interfejsu, jak i związana z nim dokumentacja będą wymagały modyfikacji;
2. Moderator musi również śledzić bliskie rozmowy. Na przykład uczestnik może początkowo wykonać kroki w kolejności, odkryć błąd i wyzdrowieć, wykonując odpowiednią sekwencję. FDA uważa, że ​​jest to prawie chybione, a moderator musi to zgłosić jako taki;
3. Moderator musi również ocenić wiedzę uczestnika. Czy wierzy, że postępuje zgodnie z właściwą sekwencją? Czy to przekonanie jest trafne?

2. Zespół następnego wydania

Jednym z czynników braku uznania złożoności jest sposób myślenia „napraw to później”, który nazywamy syndromem następnego wydania. Błędy oprogramowania nie stanowią problemu, ponieważ „naprawimy to w następnej wersji”. Nacisk na szybkość nad jakość i bezpieczeństwo sprawia, że ​​zbyt łatwo jest odkładać na później rozwiązanie trudnych problemów.

Każdy, kto zajmuje się projektowaniem i rozwojem produktu, musi zmierzyć się z syndromem następnej wersji. Dwa przykłady świadczą o tym:

• Odkryliśmy poważne wady projektowe w oprogramowaniu do monitorowania stanu zdrowia klienta. Firma zdecydowała się wydać oprogramowanie bez rozwiązywania tych problemów. Nic dziwnego, że klienci byli niezadowoleni.
• Przeprowadziliśmy testy użyteczności dla dużej unii kredytowej z siedzibą w USA. Uczestnikami byli doświadczeni doradcy finansowi. Testy ujawniły poważne wady projektowe, w tym mylące ikony stanu, przyciski o niejasnym celu i prawie ukryte łącze, które uniemożliwiało uczestnikom wyświetlanie ważnych danych. Pamiętaj, że jeśli użytkownik go nie widzi, to go tam nie ma. Kiedy zgłosiliśmy wyniki, odpowiedź brzmiała: „Naprawimy to w następnej wersji”. Zgodnie z oczekiwaniami aplikacja internetowa nie została dobrze przyjęta. Odpowiedzi od użytkowników obejmowały: „Dlaczego poprosiłeś nas o sprawdzenie aplikacji, jeśli nie masz zamiaru wprowadzać zmian?”

Rozwiązanie: odrzuć mentalność „napraw-następny-raz”

Rozwiązaniem jest zajęcie się teraz poważnymi problemami projektowymi. Brzmi prosto. Ale jak przekonać decydentów do zmiany zakorzenionego sposobu myślenia „napraw to później”?

Kluczem do sukcesu jest przeniesienie rozmowy o osiągnięciach z dostarczania produktu w kierunku tworzonej wartości. Na przykład zespoły, które poświęcą czas na zrewidowanie projektu w oparciu o badania użytkowników, prawdopodobnie zaobserwują lepsze reakcje klientów i, z biegiem czasu, większą ich lojalność.

Wzmocnij sprawę, wykorzystując dane ilościowe, aby pokazać decydentom bezpośredni związek między badaniami użytkowników a zwiększonymi przychodami i pozytywnymi doświadczeniami klientów.

Przedefiniowanie wartości jest w efekcie ulepszeniem procesu, ponieważ ustanawia nowy zestaw priorytetów, które lepiej służą klientom i długoterminowym interesom Twojej firmy. Jak donosi McKinsey w The Business Value of Design: „Firmy z górnego kwartyla korzystają z pełnego doświadczenia użytkownika; przełamują wewnętrzne bariery między projektowaniem fizycznym, cyfrowym i usługowym.”

3. Niewystarczający czas na iteracje projektowe

Z syndromem następnej wersji wiąże się niewystarczający czas na iterację projektu w oparciu o wyniki badań lub zmieniające się wymagania biznesowe. „Nie mamy na to czasu” – to częsty refren deweloperów i właścicieli produktów. Projektanci pracujący w środowiskach Agile są często pod presją unikania „wstrzymywania” zespołu programistów.

Rozwój przyspiesza, a oprogramowanie zostaje wydane. Wszyscy widzieliśmy skutki mylących aplikacji na telefon, nieporęcznego oprogramowania do dokumentacji medycznej, do niewygodnego interfejsu użytkownika dla wspomnianych powyżej doradców finansowych.

Rozwiązanie: Kolce projektowe

Jedno rozwiązanie pochodzi ze świata kodowania. W swoim artykule „Fitting Big-Picture UX Into Agile Development” Damon Dimmick przedstawia ideę skoków projektowych, „bąbelków czasu, które pozwalają projektantom skupić się na złożonych kwestiach UX”. Wpasowują się w ramy Scrum, tymczasowo zajmując miejsce zwykłego sprintu.

Kolce projektowe mają kilka zalet:

• Pozwalają zespołom UX skoncentrować się na całościowych kwestiach i uniknąć ugrzęźnięcia w szczegółowych problemach projektowych, które czasami są podkreślane w ramach jednego sprintu;
• Oferują możliwość zbadania złożonych pytań UX na wysokim poziomie. W razie potrzeby zespół projektowy UX może również zaangażować się w myślenie zorientowane na projektowanie w dowolnym momencie, aby rozwiązać większe wyzwania UX;
• Przyjmując skoki projektowe, zespoły UX mogą wykorzystać tę samą elastyczność, której używają zespoły programistyczne w zwinnym procesie i poświęcić czas potrzebny na skupienie się na problemach projektowych, które nie zawsze pasują do standardowego sprintu;
• Rozwój, na który nie mają wpływu decyzje projektowe, może być kontynuowany.

Oczywiście iteracje projektowe często wpływają na niektóre części kodu witryny, aplikacji lub oprogramowania. Z tego powodu podczas projektowania skoków, żaden kod, na który prawdopodobnie wpłynie skok projektu, nie może posunąć się do przodu. Ale, jak wyraźnie stwierdza Dimmick, to „opóźnienie” prawdopodobnie zaoszczędzi czas dzięki uniknięciu przeróbek. Po prostu nie ma sensu pisać kodu teraz, a potem przepisywać go kilka tygodni później po tym, jak zespół zgodził się na poprawiony projekt. Krótko mówiąc, odroczenie części kodowania faktycznie oszczędza czas i budżet.

4. Zbyt duże poleganie na dostawcach

Rozwiązanie problemu złożoności, przeciwstawienie się syndromowi następnej wersji i pozostawienie czasu na iterację są niezbędne dla skutecznego procesu projektowania. W przypadku wielu firm kolejną kwestią do rozważenia jest ich relacja z dostawcami oprogramowania. Dostawcy ci odgrywają ważną, a nawet krytyczną rolę w rozwoju. Jednak przyznanie im zbyt dużej dźwigni utrudnia kontrolowanie własnego produktu.

Oczywiście powinniśmy traktować współpracowników i dostawców z szacunkiem i składać rozsądne prośby. Nie oznacza to jednak, że konieczne jest zrzeczenie się całej dźwigni finansowej, jak to miało miejsce podczas mojej kadencji w dużej firmie finansowej.

Pracując w tej firmie jako projektant UX, często spotykałem się z tą dynamiką:

Menedżer : „Hej, Eric, czy możesz ocenić to oprogramowanie, które zamierzamy kupić? Chcemy tylko upewnić się, że działa zgodnie z przeznaczeniem”.

Ja : „Jasne, pod koniec tygodnia wyślę ci moje wstępne ustalenia”.

Menedżer : „Świetnie”

Następny tydzień:

Kierownik : „Dziękuję za recenzję. Widzę, że znalazłeś trzy poważne problemy: trudno znaleźć numer istniejącego roszczenia, ekrany ze zbyt dużą ilością tekstu, które są trudne do odczytania, oraz trudności z powrotem do poprzedniego ekranu podczas przetwarzania nowego roszczenia. To jest niepokojące. Czy uważasz, że te problemy zmniejszą wydajność?”

Ja : „Tak, myślę, że te problemy zwiększą stres i zwiększą czas rozpatrywania wniosków w Centrum roszczeń. Jestem bardzo zaniepokojony, ponieważ moja poprzednia praca z zespołem Janet wykazała, że ​​przedstawiciele Centrum Roszczeń są już bardzo zestresowani”.

Manager : „Naprawdę dobrze wiedzieć. Właśnie wysłałem czek. Poproszę sprzedawcę o naprawienie problemów przed wysyłką”.

Ja (wrzeszcząc w środku): „Nieeeeeeeeeeeee!”

Ten mający dobre intencje menedżer zrobił dokładnie coś złego. Po wysłaniu czeku poprosił o zmiany. Nic dziwnego, że sprzedawca nigdy nie wprowadził żądanych zmian. Dlaczego mieliby? Mieli swoje pieniądze.

Ten scenariusz nie tylko powtarzał się wielokrotnie w tej firmie, ale byłem tego świadkiem w całej mojej karierze UX.

Rozwiązanie

Rozwiązanie jest jasne. Jeśli produkt dostawcy nie spełnia potrzeb klientów i biznesu, a żądane zmiany mieszczą się w zakresie, nie płać, dopóki dostawca nie wprowadzi zmian. To naprawdę takie proste.

Wniosek

W tym artykule zidentyfikowaliśmy cztery wspólne bariery dla wysokiej jakości projektowania i odpowiednich rozwiązań:

1. Skomplikowane przepisy i standardy
   Rozwiązaniem jest uznanie i uwzględnienie złożoności poprzez opracowanie realistycznych harmonogramów i wystarczającego budżetu na badania i projektowanie iteracyjne.
2. Wysyłanie oprogramowania z błędami z obietnicą ich późniejszego naprawienia
   Rozwiązaniem jest uniknięcie syndromu następnej wersji i rozwiązanie poważnych problemów już teraz. Przekonaj decydentów poprzez ponowne zdefiniowanie znaczenia wartości w Twojej organizacji.
3. Za mało czasu na iteracje projektowe
   Rozwiązaniem jest uwzględnienie skoków projektowych w zwinnym procesie rozwoju. Te bąbelki czasu chwilowo zastępują sprint i pozwalają projektantom skupić się na złożonych zagadnieniach UX.
4. Zbyt duże poleganie na dostawcach
   Rozwiązaniem jest zachowanie dźwigni poprzez wstrzymanie końcowej płatności, dopóki dostawca nie wprowadzi żądanych zmian, o ile zmiany te mieszczą się w pierwotnym zakresie projektu.

Czwarte rozwiązanie jest proste. Chociaż pierwsze trzy nie są łatwe, są konkretne, ponieważ można je zastosować bezpośrednio w istniejących procesach projektowych. Ich wdrożenie nie wymaga ogromnej reorganizacji ani milionów dolarów. Wymaga to po prostu zaangażowania w dostarczanie lepszych wrażeń.