Agile UX: jak włączyć UX i projekt produktu do Agile

DevOps jest często definiowany jako procesy, operacje, metodologie, narzędzia i kultura otaczające oprogramowanie i rozwój systemów firmy.

Ale inżynieria nie działa w próżni. Plany, pomysły, projekty i koncepcje pochodzą od specjalistów ds. projektowania produktów, którzy decydują o układach, przepływach i interaktywności. Są to nieinżynierskie osoby i zespoły, które podzielają cele DevOps i pożądane wyniki.

DevOps to o wiele więcej niż sposób, w jaki programiści łączą się z IT, jak zarządzana jest infrastruktura i jak można ulepszać frameworki. Chodzi o rozpoznanie, ile zespołów jest naprawdę zaangażowanych w proces tworzenia oprogramowania, jak powiązane są ich role i praca oraz znalezienie lepszych sposobów, aby upewnić się, że wszyscy są przy stole.

Deweloperzy i architekci inżynierowie chcą być zaangażowani w projektowanie oprogramowania lub systemu przez zespoły produktowe i kreatywne. Ale gdzie to jest w obecnej definicji DevOps? Zespoły produktowe, UX i kreatywne chcą pozostać zaangażowane w procesy inżynieryjne, ale tak wiele metodologii je wyklucza. To są stare silosy, które musimy zburzyć.

Twoi klienci widzą tylko Twoje doświadczenie użytkownika (UX). Nie widzą, ilu miałeś programistów ani czy byłeś Agile czy Lean. Nie mają pojęcia, jakie narzędzia DevOps są używane. UX Twojej firmy jest produktem, który może Cię stworzyć lub złamać. Zastanawiają się, kto zbudował ten złom. Przy tak dużej konkurencji i ludziach, którzy chętnie odinstalują aplikację lub opuszczą stronę internetową, czy dostaniesz drugą szansę z klientem, który Cię porzucił?

Agile rzadko trenuje UX lub współpracuje ze specjalistami UX

Wiele zespołów inżynierskich często uważa, że ​​UX jest wyciszony i trudny do współpracy. UX nie wydaje się Lean, a wiele odmian Agile wyklucza szczegóły dotyczące pracy z UX. Niektóre podejścia Agile wyraźnie sugerują, że właściciel produktu opisujący funkcję jest „wystarczająco dobry”.

SAFe Agile popełnia błąd, uznając, że najlepszym sposobem rozwiązania problemu silosowania UX jest ich całkowite wykluczenie. SAFe „umożliwia zespołom Agile” tworzenie własnego „Lean UX”. Ponieważ coraz więcej firm rozumie wartość włączenia specjalistów UX i pełnego procesu UX, SAFe idzie w złym kierunku.

Brak wyjaśnienia UX i ich procesów na podstawie szkoleń i książek Agile skłonił zespoły na całym świecie do wykluczenia lub zminimalizowania zaangażowania wyspecjalizowanych projektantów produktów.

• Kiedy błędnie wyobrażasz sobie, że UX po prostu rysuje ramki na stronach, łatwo założyć, że „mogę wykonać tę pracę”. Podobnie jak wielu słuchaczy American Idol, są pewni, że są najlepszymi piosenkarzami na świecie, większość menedżerów produktu i inżynierów uważa, że ​​są świetni w UX. Zwykle oznacza to, że wierzą, że są świetni w układaniu ekranów. Ale ponieważ ten artykuł wyjaśnia, co tak naprawdę składa się na pracę UX, zobaczysz, jak specjalista od UX nie widziałby programisty, który tworzy makiety, jako kogoś, komu należy powierzyć zadania UX.
• Książki o Scrumie sugerują, że jeśli specjalista UX stanie się wąskim gardłem, powinna wyszkolić role niezwiązane z UX, aby wykonywać swoją pracę. Ten rodzaj decyzji jest rzadko sugerowany w przypadku innych ról w tworzeniu oprogramowania; nikt nie chciałby, aby kodem zajmował się niewyszkolony lub niedoświadczony programista, nawet po bootcampie lub po przeczytaniu książki o programowaniu. Nigdy nie sugerowalibyśmy, że jeśli programista stanie się wąskim gardłem, powinien przeszkolić kierownika projektu w zakresie kodowania.
• Zatrudnianie menedżerów, którzy błędnie wierzą, że UX to praca artystyczna (UI), zatrudniają artystów do pracy UX. Dyplom z UX i UI nie nakładają się na siebie. Naturalne talenty często się nie nakładają; ktoś świetny w UX może być kiepskim artystą i vice versa. Zatrudnienie dla „UX/UI” często zapewnia wspaniałego artystę z minimalnym doświadczeniem w zakresie UX, wiedzą fachową, procesem lub wykształceniem.

Ci, którzy patrzą tylko na wyniki, chcieliby obciąć budżet, powierzając zadania UX osobom, którym może brakować wykształcenia UX, doświadczenia, wiedzy, umiejętności lub naturalnego talentu. Jest to jednak krótkowzroczne i może prowadzić do niskiej produktywności, wydajności, kultury, zadowolenia z produktu i klienta.

Znaczenie włączenia ekspertów UX w Agile

Pod koniec 2018 roku firma zajmująca się doradztwem w zakresie zarządzania McKinsey & Company opublikowała „The Business Value of Design” raport z badań, które przeprowadzili z ponad 300 firmami.

Odkryli, że „projektowanie to jedyny sposób, w jaki firmy mogą wyróżnić się z tłumu”. Kiedy konkurenci mają zbliżone zestawy funkcji, co wyróżnia ich? Design jest czasem postrzegany jako tylko estetyka lub to, co sprawia, że ​​wygląda to jak nasza marka. Ale w połączeniu z projektowaniem „UX” oznacza architekturę funkcji i decyzje dotyczące ekranów, kroków, przepływów, układów, procesów, organizacji i menu.

UX jest częścią procesu ciągłego doskonalenia, zawsze starając się lepiej zrozumieć użytkowników oraz wybrać i zaprojektować funkcje i produkty, które najlepiej odpowiadają ich potrzebom, rozwiązać ich problemy i wprowadzić znaczące innowacje.

McKinsey poinformował również, że „Firmy muszą przyjąć projektowanie całościowo i na wczesnym etapie procesu, zamiast postrzegać je jako małe narzędzie, które pasuje później”. Zespoły zakładające, że uwaga na wrażenia użytkownika jest czymś, co można zminimalizować, wykluczyć lub zrobić po wydaniu produktu, przyjmują niewłaściwe podejście.

McKinsey zebrał dane ilościowe i stwierdził, że firmy, które przyjęły projektowanie UX, wygenerowały o 32% większe przychody i 56% większe zwroty dla akcjonariuszy w okresie 5 lat. Sama deklaracja, że ​​Twoja firma jest „zorientowana na użytkownika”, nie wystarczy. Musisz przejść przez proces integracji praktyków i procesów UX, od planowania i portfolio po rozwój i kontrolę jakości.

Procesy rozwoju oprogramowania z i bez UX

Jeśli Twoja firma nie włącza specjalistów UX w proces projektowania i tworzenia oprogramowania, Twój proces najprawdopodobniej wygląda tak, jak na poniższym obrazku.

Klient, menedżer produktu, dyrektor generalny lub ktoś z wizją mówi inżynierom, czego chcą. Inżynierowie budują go, testują i umieszczają na serwerze pomostowym lub produkcyjnym. Osoba z wizją wtedy to widzi i, nie wiesz, nie jest szczęśliwa. Chcą czegoś innego lub zmienili zdanie.

Inżynieria musi następnie wrócić do początku, dowiedzieć się, czego teraz chce ta osoba, zbudować, przetestować i trzymać kciuki, że to jest urok.

Jeśli masz w zespole ekspertów UX, proces wygląda zupełnie inaczej. Osoba z wizją przychodzi do UX z pomysłami, danymi i problemami klientów. UX cyklicznie przechodzi przez zadania w procesie projektowania zorientowanym na użytkownika, a następnie testuje te koncepcje, zanim inżynierowie napiszą wiersz kodu. Gwarantuje to, że produkt lub funkcja, którą zamierzamy zbudować, jest właściwą realizacją właściwego pomysłu dla naszych docelowych klientów.

Testowanie może ujawnić pewne wady, co pozwala UX na iterację i często ponowne testowanie. Po procesie UX masz w pełni sprawdzony projekt gotowy do dostarczenia do inżynierii.

Jeśli ktoś po drodze zmieni zdanie, porozmawia z UX, zamiast zgłaszać to jako prośbę o zmianę do programistów. UX powoduje zakłócenia podczas ich procesu i nic nie jest wysyłane do inżynierii bez zaangażowania UX w projekty, decyzje i testy na rzeczywistych lub archetypowych klientach.

Zmiana zdania w tym momencie nie jest katastrofą, ponieważ koszt zmiany zdania w tym momencie jest minimalny. Inżynieria nie dostarczyła planów, nie zostały uruchomione i nie mają nic do odbudowy. UX iteruje w swoich projektach i może przeprowadzać testy użytkowników, aby upewnić się, że pomysły są dobrze dopasowane do bazy klientów. Zmiany czasu wypalania umysłu, ale ogólny wpływ na budżet jest niewielki.

UX ma sformalizowany proces

Projektowanie zorientowane na użytkownika (UCD) to sformalizowany proces, który obejmuje zadania, które kierują specjalistów UX do badania, projektowania, prototypowania, testowania na rzeczywistych lub archetypowych użytkownikach, a następnie iteracji w oparciu o wnioski z testów.

Koncentrując się na kilku z tych obszarów, zaczynamy od wymagań i wczesnych dyskusji na temat funkcji i projektów. Kiedy UX po raz pierwszy otrzymuje wymagania i inne informacje o projekcie, ważne jest, aby od razu rozpocząć współpracę. UX NIE powinien dowiedzieć się później, że zaprojektował coś, czego nie można zbudować.

Zacznij od włączenia pracowników lub menedżerów UX, gdy menedżerowie produktu lub projektu decydują o funkcjach i priorytetach. Projekt bez wartości dla użytkownika można usunąć, oszczędzając niezliczoną ilość czasu i pieniędzy. Tutaj w grę wchodzi maksymalizacja ilości niewykonanej pracy. Produkt i inżynieria powinny wspierać UX, gdy tworzą mniej pracy dla inżynierów, zmniejszając lub usuwając funkcje lub całe projekty. Jednak zbyt często projekty mają przywiązane ego, a koledzy z zespołu często wykluczają UX z tych wczesnych rozmów, aby projekt został sfinansowany.

Badania to ważny element tego, czym zajmuje się UX. Nie jest zorientowany na użytkownika bez angażowania użytkowników. Statystyki i dane ilościowe są świetne, ale nic nie zastąpi przeprowadzania wywiadów z użytkownikami, dogłębnego ich zrozumienia i uzyskania danych jakościowych. UX chce wiedzieć, dlaczego, a nie tylko co.

Badania UX również przyciągają członków zespołu na tę samą stronę, jednocząc wszystkich wokół person, archetypów klientów docelowych. Na podstawie wywiadów z użytkownikami agregujemy to, czego się uczymy i sprowadzamy wszystkich do 6 lub mniej osób. Co ich motywuje? Czego potrzebują? Gdzie są możliwości dla naszej firmy, produktu lub usługi?

Najlepszym zastosowaniem person byłoby umieszczanie ich wszędzie. Produkt wyobraża sobie funkcje w oparciu o persony (i dobre dane). Projekty UX oparte na personach. Testy QA, wyobrażając sobie, że są to te osobowości. Marketing może dodać swoje dane demograficzne i inne szczegóły, ale także powinien wziąć pod uwagę, w jaki sposób głos marki, media społecznościowe i reklamy przemawiają do person.

Persony pomagają pracownikom nie korzystającym z UX uciec od: „Cóż, podoba mi się w ten sposób” lub „Cześć generalna lubi to w ten sposób”. Projektujemy dla tych docelowych klientów i jeśli Ty lub CEO nie pasujecie do person, to na UX nie wpływa ego ani osobiste preferencje. UX musi być zorientowany na klienta.

Architektura informacji dotyczy hierarchii, struktury i taksonomii. Może to być nawigacja w witrynie lub sposób kategoryzacji produktów w bazie danych handlu elektronicznego. Chcemy mieć pewność, że klienci z łatwością znajdą produkty według kategorii, metadanych i filtrów.

Projektowanie interakcji , czasami nazywane również projektowaniem doświadczeń, jest tym, o czym myśli większość ludzi, gdy wyobrażają sobie UX. To są makiety i prototypy, plany projektów i koncepcje. Pokazują one przepływy procesów, układy, menu, interakcje, ścieżki, wybory i wiele więcej.

Prototypy UX są jak ożywione szkielety. Są to klikalne, interaktywne makiety cyfrowe. Nie musimy pisać kodu; mamy oprogramowanie, które pomaga nam je szybko tworzyć. Firmy poszukujące bardziej realistycznych prototypów używają Axure, ponieważ ma on logikę warunkową, zmienne, gesty przesuwania, przeciągania i upuszczania oraz wszelkiego rodzaju wyzwalacze zdarzeń. Możesz stworzyć prototyp dla dowolnego typu urządzenia.

Prototypowanie UX ma na celu:

• Burza mózgów
• Współpracować
• Powtarzać
• Poznaj rozwiązania
• Prezentacja dla inwestorów (dla startupów)
• Przetestuj prototyp, aby sprawdzić, czy rozwiązanie dobrze łączy się z odbiorcami docelowymi.
• Dostarcz interaktywny model programistom lub innym członkom zespołu, co jest często preferowane w stosunku do stron dokumentacji (i nie ma klikalnego modelu).

Teraz przechodzi do testowania użytkowników , zwanego również testowaniem użyteczności, które odbywa się podczas procesu UX i przed inżynierią napisze wiersz kodu. Musisz przetestować koncepcje i projekty, aby upewnić się, że pomysł i wykonanie są fantastyczne dla docelowych klientów.

Testy użytkowników ujawnią wszelkie wady, dając UX szansę na iterację pomysłów, co w tym momencie jest niedrogie, ponieważ inżynieria nie ma czego budować ani przebudowywać.

Istnieje 5 kluczowych powodów, dla których UX przeprowadza testy przed dostarczeniem do inżynierii:

1. Najlepsze wykorzystanie czasu i zasobów inżynierów. Jeśli chcesz, aby uczestnicy testów zobaczyli gotowy produkt stworzony przez inżynierów, musisz go zbudować i przetestować pod kątem błędów. Jeśli testy UX wyjdą na jaw potrzebne zmiany, programiści będą musieli przebudować, a kontrola jakości będzie musiała ponownie przetestować. Jeśli testy UX wykazały większą porażkę koncepcji, może to oznaczać, że czas inżynierów został całkowicie zmarnowany, ponieważ nie jest to kod, który nigdzie się skończy. Koncepcja musiałaby zostać przemyślana, przeprojektowana i świeżo przetestowana.
2. Iteruj za kulisami. Kiedy firmy po prostu go budują, po prostu wysyłają, iterują, budują i wysyłają ponownie, oznacza to, że klienci widzą różne wersje. Widzą prace w toku i przyglądają się, jak powstaje kiełbasa. Jest to często frustrujące i mylące doświadczenie, wymagające od klientów ciągłego uczenia się na nowo ewoluującego systemu. Lepiej jest iterować za kulisami procesu UX i wyjaśniać testerom, że jest to wersja prototypowa lub demonstracyjna.
3. Monitorowanie i pomiary. Jeśli nowa koncepcja zostanie opublikowana na żywo, badacze UX nie mają dobrego sposobu na obserwowanie, jak ludzie go używają, zadawanie im pytań i uzyskiwanie informacji zwrotnej, jakiej UX potrzebuje, aby określić, czy coś jest gotowe lub wymaga kolejnej iteracji. UX zawsze chce wiedzieć, dlaczego, jaka jest jakość, a nie tylko co lub ile. W jaki sposób użytkownicy wydają, konwertują, angażują się itp.? Unikanie właściwych testów UX utrudnia diagnozowanie i rozwiązywanie problemów lub problemów klientów.
4. Testy UX się opłacają. Testowanie UX nie jest dużym wydatkiem. Niektóre narzędzia testowe innych firm wymagają mniej niż 100 USD na uczestnika testów, inne wymagają minimalnego rocznego zobowiązania w wysokości tysięcy dolarów. Nie są to ogromne wydatki, biorąc pod uwagę całkowity budżet firmy na proces tworzenia oprogramowania i znaczenie wczesnych informacji zwrotnych z testów. Rundy testów użytkowników prawie zawsze kosztują mniej i przebiegają szybciej niż zmuszanie programistów do tworzenia czegoś, co być może będziemy musieli cofnąć lub zbudować ponownie.
5. Testowanie użytkowników rozwiązuje argumenty. Jeśli Twoja firma nie pozwala specjalistom ds. UX na podjęcie ostatecznej decyzji o tym, jak produkt jest zaprojektowany, może się okazać, że UX jest w konflikcie z produktem, inżynierią lub interesariuszem, gdy istnieją różne pomysły na to, co należy zbudować i udostępnić klient. A co, jeśli UX ma dwa mocne pomysły i zastanawiają się, który lepiej łączy się z klientami? Rozwiązaniem tutaj jest testowanie użytkowników.

UX może prototypować koncepcje. Najlepiej sprowadzić konkurencję do dwóch najlepszych projektów, zwłaszcza jeśli można już znaleźć kompromisy między pomysłami i członkami zespołu. Oznacza to, że nie testujemy tego, czego oczekuje UX, co podoba się produktowi, co lubi inżynier inżynier, co zdaniem mistrza scrum brzmi jak dobry pomysł, a co lubi życiowy partner prezesa.

Testowanie użytkowników pozwala klientom zabierać głos i pomaga znaleźć właściwy kierunek dla funkcji lub produktu. Rozwiązuje kłótnie, dostarczając zespołom twardych danych ilościowych i jakościowych, które podpowiadają wszystkim, który pomysł może przynieść największą satysfakcję klientom.

Nie jest to projekt zorientowany na użytkownika bez angażowania użytkownika. Oznacza to, że badamy i testujemy na prawdziwych lub archetypowych klientach, zamiast zgadywać, zakładać lub „po prostu wysyłać”. Musimy upewnić się, że to, co „po prostu wysyłamy”, zostało sprawdzone przez testy użytkowników i jest doskonałą realizacją świetnego pomysłu.

Co się dzieje, gdy UX jest omijany lub ograniczany?

Skype niedawno ogłosił, że jego przeprojektowanie w 2017 roku, które miało na celu uczynienie go bardziej podobnym do Snapchata, zakończyło się porażką. Użytkownicy nie chcieli, nie potrzebowali lub nie lubili nowych funkcji. Reakcja była na tyle duża, że ​​Skype ogłosił w 2018 r., że ponownie przeprojektują Skype'a. (https://devops.icu/skypes-coming-redesign-of-their-last-redesign/)

Eksperci UX na wielu etapach swojego procesu wiedzieliby, że te funkcje mogą być niechciane lub zawiodą. Badania z docelowymi użytkownikami mogły szybko ujawnić, że nie chcą, aby Skype stał się Snapchatem. Zabicie projektu lub przestawienie się na tak wczesnym etapie mogło oszczędzić Skype'owi miliony dolarów, a także złą prasę i wyobcowanie klientów.

Nawet gdyby pominięto badania UX, przetestowanie prototypu UX na użytkownikach jasno pokazałoby, że klienci nie chcą, aby Skype podążał w tym kierunku. Ponieważ UX wciąż przechodzi przez swój proces, inżynierowie nie napisali jeszcze linii kodu. Mogłoby to zaoszczędzić ogromną ilość czasu, pieniędzy i zasobów ludzkich, celebrując prostotę i inżynierię pracy, której nie trzeba było robić.

Zwinny proces UX

Pamiętaj o zasadach manifestu Agile. Twoim najwyższym priorytetem jest zadowolenie klienta poprzez budowanie wartościowego oprogramowania. Zapewnij pracownikom (UX) środowisko i wsparcie, których potrzebują, ufając, że wykonają swoją pracę. Zmaksymalizuj ilość niewykonanej pracy. Ciągła dbałość o dobry design zwiększa zwinność.

Projekty, które posuwają się do przodu, muszą zapewnić UX ogromny wybieg, aby można było rozpocząć odpowiednie badania, projektowanie i testowanie. Nie zapraszaj UX na spotkanie inauguracyjne i zaskakuj ich żądaniem dostarczenia finalnych makiet w ciągu kilku dni. To nie jest UX.

Nie patrz na to jak na Big Design Up Front (BDUF), co jest terminem stworzonym po to, by ludzie się skulili i ogłosili, że jest to coś, od czego musimy uciec. Gdy projekt lub funkcja jest duża lub nowa, UX musi przechodzić przez większość, jeśli nie całość, procesu projektowania zorientowanego na użytkownika. W przypadku UX najmniejszym możliwym elementem większej funkcji jest przepływ pracy lub proces użytkownika. Jeśli projektujemy i testujemy coś mniejszego, ryzykujemy, że nie uzyskamy pełnego obrazu prawdziwego doświadczenia użytkownika.

Na przykład, jeśli projektujemy przepływ, w którym użytkownicy rejestrują się i kupują, nie możemy po prostu zaprojektować pól wyboru hasła i przesłać je do inżynierii. Gdyby UX działał w małych kawałkach, kiedy testowano by cały proces? Nie możemy poznać reakcji użytkownika na cały przepływ bez przetestowania całego przepływu… co oznacza, że ​​cały przepływ musi zostać zaprojektowany, zanim przejdzie do testów użyteczności.

Tam, gdzie funkcje, historie lub poprawki są niewielkie, praktycy UX mogą wykonać podzbiór procesu projektowania zorientowanego na użytkownika i pracować szybciej. UX zawsze będzie działać tak szybko, jak tylko mogą, ale świetny specjalista UX zrobi wszystko, co w jej mocy, aby uniknąć poświęcania jakości wykonywanej pracy. W bitwie „szybko kontra dobra” UX zawsze będzie wybierał dobre, a nie szybkie… i ty też powinieneś.

Budżety i harmonogramy uniemożliwiają UX szybkie uzyskiwanie informacji zwrotnych i iterację. Praktycy UX zawsze chcą informacji zwrotnej i szansy na ulepszenie produktu, dążąc do zaprojektowania tego, co naprawdę działa dla klientów. Zaangażowanie praktyków UX już na etapie zarządzania portfelem i planowania pozwala UX oszacować czas i budżet, których będą potrzebować; nie powinny to być później niespodzianki ani przyczyny konfliktów.

Praktyk UX jest częścią zespołu Agile

Osadź swojego projektanta UX w zespole Agile. Zaproś ich do planowania wydania, stand-upu, retro i każdego spotkania, na którym można omówić UX. Pozwól UX oszacować swój czas podczas planowania wydania, aby nie było niespodzianek związanych z harmonogramem zadań UX. Nie podejmuj decyzji bez nich. Jeśli Twój kolega z zespołu UX przegapił spotkanie, poczekaj, aż znajdziesz go osobiście, przez czat, e-mail lub inną metodą używaną przez Twoją firmę.

Przydziel pytania, niejasności lub błędy swojemu koledze z zespołu UX w JIRA lub innym używanym systemie śledzenia błędów. Upewnij się, że problemy związane z UX znajdują się w tym samym systemie, co inne problemy; nie usuwaj problemów UX na tablicy Trello, jeśli używasz VersionOne do wszystkiego innego.

Po długim wybiegu UX, jeśli było to wymagane dla tej funkcji lub produktu, najlepszą praktyką jest, aby UX był o 2 lub więcej sprintów przed inżynierią. UX może sprintować razem z Tobą. Zdobądź mnóstwo historii technicznych lub napraw dług technologiczny w zaległościach. W ten sposób, jeśli kreatywny i cykliczny proces UX opóźnia się lub wymaga większej liczby sprintów, programiści mogą być naprawdę zwinni. Zamiast czekać na UX, mogą przerzucić się na jakiś nisko wiszący owoc, dla którego produkt lub inżynieria mają priorytet.

Weź również pod uwagę zasoby, alokację i personel. W zależności od wielkości projektu przydziel do jednego projektanta UX nie więcej niż 3 projekty. Jeśli masz oddzielnych, doświadczonych badaczy UX, którzy również przeprowadzają testy i analizy, przydziel jednego badacza do nie więcej niż 3 projektantów UX. Jeśli Twój praktyk UX ma kształt litery T, co oznacza, że ​​ma również kwalifikacje i jest doskonała w badaniach, testowaniu i innych podspecjalizacjach UX, upewnij się, że nie jest przypadkowo wąskim gardłem, ponieważ jest przydzielona do zbyt wielu projektów.

Wyniki pomiaru

Bez zadowolenia klienta możesz nie mieć klientów. Możesz użyć wskaźników satysfakcji klienta, aby określić, w jaki sposób usprawnienie procesów poprzez integrację UX spowodowało pozytywne zmiany.

• Mniej skarg
• Lepsze recenzje aplikacji
• Wyższe oceny aplikacji
• Mniej zgłoszeń pomocy technicznej
• Mniej połączeń z call center
• Bardziej pozytywna semantyka postów społecznościowych
• Więcej instalacji aplikacji, mniej odinstalowań
• AOV (średnia wartość zamówienia) wzrasta
• Wyższy współczynnik konwersji

Możesz także mierzyć pożądane cele DevOps, takie jak czas wprowadzenia na rynek i czas między poprawkami. Ile czasu zajmuje historiom, projektom i eposom wprowadzenie na rynek przed i po rewolucji UX? Szacunki czasu programistów będą prawdopodobnie bardziej dokładne, gdy sfinalizują projekty UX, na których będą opierać swoje szacunki, w porównaniu z pracą na podstawie historii lub czegokolwiek, co teraz robisz.

Jeśli UX dostarcza plany i są one przestrzegane, mamy nadzieję, że inżynierowie będą mniej pracowali dzięki ograniczeniu niespodziewanych zmian i przebudów. Lepszy projekt UX wcześniej, mniej poprawek później.

Agile UX to inwestycja, która więcej niż się opłaca

Wielu kierowników projektów postrzega UX jako linię budżetową, którą można usunąć lub zmniejszyć, a menedżerowie zatrudniający są podekscytowani pomysłem połączenia zadań UX z inną rolą. Jednak coraz więcej firm przekonuje się, że nic nie zastąpi inwestowania w odpowiedni proces UX realizowany przez wyszkolonych i doświadczonych specjalistów UX.

Eric Ries, autor książki The Lean Startup , pyta: „A co, gdybyśmy zbudowali coś, czego nikt nie chciał? W takim razie, jakie miałoby znaczenie, że zrobiliśmy to na czas i zgodnie z budżetem?” Nawet jeśli Twoja organizacja nie stosuje metodologii Lean, ostrzeżenie nadal jest prawdziwe. Pożądane wyniki DevOps odzwierciedlają to, gdy staramy się zbudować coś odpowiedniego dla klienta, poprawić satysfakcję klienta i opracować funkcje o wysokiej wartości dla klienta.

Poznanie klienta, zaangażowanie go w proces i budowanie zgodnie z jego prawdziwymi potrzebami i preferencjami jest ostatecznie ważniejsze niż terminy, budżety, ramy i narzędzia. Zaufaj, że jeśli zbudujesz właściwą realizację właściwych pomysłów, uzyskasz przychód.