Podsumowanie TL;DR

• Wiele (większość?) zespołów zajmujących się produktami cyfrowymi nie ma przywództwa skoncentrowanego na projektowaniu i/lub zasobów niezbędnych do przejścia poważnego przeprojektowania produktu (lub do kompleksowego zastosowania nowego systemu projektowania).
• Jednak powszechną pułapką projektantów w tych organizacjach jest projektowanie „idealnych”, wzorców aspiracji, które reprezentują główną zmianę w systemie: to znaczy „zaprojektujmy najlepszy system, jaki możemy wymyślić”, zamiast systemu, który najlepiej poprawi istniejący produkt.
• Moje preferowane podejście to mniej „rewolucji”, a więcej „ewolucji”: rozwijając system od korzeni istniejącego produktu (zamiast wymuszać rewolucyjne zmiany), znacznie szybciej osiągniesz bardziej spójne, przewidywalne i przyjazne dla użytkownika wrażenia użytkownika .

Firmy mają ograniczone zasoby, aby ułatwić zmianę projektu

Organizacje takie jak Airbnb i Apple pokazały nam, że podejście projektowe do produktu może prowadzić do pięknych wrażeń — a czasem nawet sukcesu komercyjnego! A firmy takie jak MailChimp i Google (wraz z uruchomieniem Material Design ) wykonały godny podziwu kurs pracy, poprawiając kompleksowe pozytywne zmiany projektowe.

Często, gdy zespoły projektowe rozmawiają o systemach projektowych, mają na myśli właśnie te firmy: „Potrzebujemy projektu materiałowego dla [naszego produktu]!” Bardzo ekscytujące rzeczy, ale to trudne zadanie dla zespołu z ograniczonymi zasobami inżynieryjnymi o wysokim zapotrzebowaniu, który ma już duże zaległości: chcieliby mieć dobrze zaprojektowany produkt, ale najpierw muszą pracować nad [X, Y, i projekty Z]… wszystkie prawdopodobnie mają wyraźniejsze historie „zwrotu z inwestycji” niż zmiany projektowe.

Brzmi znajomo? Mnie to przeszkadza, zwłaszcza w organizacjach na wczesnym i średnim etapie, w których wolę pracować.

Jesteś więc projektantem pracującym z ograniczonym „budżetem” inżynieryjnym. Masz świetne pomysły na swój produkt, a także nowe wzorce, zachowania i estetykę, które aż chce się wdrożyć . Ale kiedy cofniesz się i spojrzysz dzisiaj na cały swój produkt, oto co o nim myślisz:

Oto on: masz duże, podstawowe doświadczenia użytkownika, które z czasem zostały połączone z równorzędnymi stronami, przepływami i innymi gałęziami produktów. Zostały one zbudowane w ciągu miesięcy lub lat przez różnych ludzi zajmujących się produktami o różnych kierunkach projektowych. Niektóre z tych funkcji zostały prawdopodobnie zbudowane jako rozwiązania MVP — „nasi klienci potrzebują tego teraz! Później dodamy „projekt” — i od tamtej pory nikt ich nie dotykał. Wszystko to zostało zbudowane z najlepszymi intencjami dla użytkownika i firmy, ale jako system projektowy możesz mieć do czynienia ze szczurzym gniazdem doświadczeń.

Jak więc, projektant produktu, nadać temu kształt?

Rewolucja: osiągnięcie nirwany projektowej w jednym wielkim ujęciu

Vive la rewolucja! Kiedy siedzisz w Sketch przed wyświetlaczem Apple Thunderbolt, łatwo wpaść w emocjonalną pułapkę: „Gdybym tylko mógł zacząć od zera, mógłbym sprawić, że ten produkt śpiewa! ”. Ale jak planujesz faktycznie to wdrożyć? Prawdopodobnie coś takiego:

Świetna robota: masz doskonały system projektowania! Omówmy to podejście do stosowania systemu projektowania.

Zalety

• Twój produkt ma teraz projekt naszych marzeń! TO MAGICZNE!
• Zaprojektowałeś wszystko na raz, z tymi samymi projektantami w pokoju, więc wszystko jest bardzo spójne i przemyślane. CZUJE SIĘ TAK DOBRZE!

• To… prawie nigdy tak naprawdę nie działa w ten sposób.
• Trzeba było poświęcić mnóstwo zasobów przez długi czas.
• Zostało to zaprojektowane w próżni (niezależnie od tego, czy zostało dobrze zbadane, czy nie), więc nie uwzględnia niektórych rzeczywistych wyzwań, które nieuchronnie odkryjesz, gdy prawdziwi użytkownicy zaczną z niego korzystać.
• Wreszcie (ale może przede wszystkim ), Twoi użytkownicy/klienci musieli używać starej, gównianej wersji Twojego produktu przez miesiące lub lata , tylko po to, by stawić czoła nagłej, ogromnej zmianie w projekcie produktu za każdym razem, gdy wypuszczasz tę nową rzecz.

Model „North Star”: osiąganie nirwany w zakresie projektowania produktów, jeden cudowny moment na raz

Twój zespół projektuje więc swoje idealne doświadczenie produktowe, ale okazuje się, że nie masz zasobów potrzebnych do jednostronnej rewolucji projektowej. Wyobraź to sobie! Ale teraz, gdy zaprojektowaliśmy te wspaniałe wzorce, zachowania i zasady, zacznijmy stosować je w sposób oportunistyczny, gdy i tak pracujemy nad stronami produktów i funkcjami. Tu nic nie idzie:

W porządku, mamy tutaj trochę ruchu, a pod koniec tego procesu mamy kilka naprawdę fajnych doświadczeń w naszym produkcie (nawet jeśli nadal niesiemy ze sobą jakiś bagaż).

Zalety

• Zobacz, jak Twoje marzenia projektowe spełniają się w Twoim produkcie, nawet jeśli to tylko elementy.
• Znacznie bardziej realistyczny niż pełna rewolucja projektowa.
• W odległej przyszłości (i jeśli udało ci się zachować te same preferencje projektowe przez te lata) możesz po prostu zobaczyć, jak reszta produktu zaokrągla się do formy. Może.

• Bardziej radykalne zmiany wymagają więcej zasobów na zmianę (ponieważ otwierasz skrajne przypadki, ograniczenia techniczne itp.), więc tempo zmian jest wolniejsze niż w przypadku użycia starych lub bardziej konserwatywnie zmienionych wzorców.
• Do końca masz świetny projekt, ale spójrz na fazy przejściowe tego projektu: to miesiące lub lata, kiedy Twoi użytkownicy i klienci używają tego naprawdę niejednolitego produktu, w którym doświadczenie i styl mogą się radykalnie zmieniać z ekranu na ekran. Czy naprawdę projektujesz tak, aby Twoja praca w końcu przynosiła owoce po latach ? Nie sądziłem.
• Zanim większość Twoich produktów zostanie przeniesiona do tego nowego systemu, ty (i reszta społeczności projektantów) prawdopodobnie zmieniłeś się pod względem tego, co uważa się za dobry, powszechny, a nawet modny projekt interfejsu użytkownika. Tyle pracy, a ty nadal tkwisz w projekcie (zgadza się, twój „nowy projekt”), który ma kilka lat.

Pod względem stylu i zachowania są one bardzo różne , więc jeśli migrujesz części swojego UX krok po kroku, będziesz mieć radykalnie różne formularze i dane wejściowe prezentowane w całym produkcie. To mały przykład, który przedstawia większy problem polegający na wprowadzaniu radykalnych zmian w projekcie w sposób fragmentaryczny.

Ale jest nadzieja! Możesz uniknąć trudnych, niechlujnych zmian projektowych, projektując system, który opiera się na tym, co masz. Można nawet powiedzieć, że powinieneś „ewoluować” swój produkt od miejsca, w którym jest dzisiaj…

To ewolucja, kochanie : szybsze tworzenie lepszego produktu dzięki docenianiu tego, co masz

Zespołowi projektowemu z ograniczonym budżetem inżynieryjnym polecam zbudowanie (lub ulepszenie) systemu projektowego, wykorzystując najlepsze cechy produktu, który już oferuje, i opierając się na tym. Nawet jeśli jesteś pierwszym projektantem w małym zespole startupowym, ktoś (niezależnie od tego, czy był to projektant, lider produktu czy programista) zdecydował się podjąć te decyzje dotyczące interfejsu użytkownika z prawdziwych powodów. Twoje kroki będą się różnić w zależności od bieżącego stanu produktu, ale proces zaczyna się mniej więcej tak:

1. Dowiedz się o swoim obecnym systemie projektowania (jeśli istnieje) : skąd pochodzą komponenty? Czy gdzieś w Twojej organizacji znajduje się podstawowy arkusz stylów lub biblioteka? W jaki sposób są one zorganizowane? Kto to zbudował? Kto używa go najczęściej i z jakich jego części korzysta? Kiedy muszą wyruszyć w teren bez niego?
2. Zrób inwentaryzację wzorców i zachowań, które widzisz w swoim produkcie : w jaki sposób prezentujesz różne rodzaje informacji użytkownikom? W jaki sposób użytkownicy wybierają, co chcą zobaczyć? Jak wprowadzają informacje? W przypadku elementów interfejsu: czy widzisz zakładki, karty, listy lub formularze? W jakich sytuacjach pojawia się każdy element?
3. Zapisz zasady, którym wydaje się podlegać Twój produkt; następnie sam zaostrz zasady: gdzieś za całym długiem projektowym kryje się logika tego, jak Twój produkt został złożony. Zapoznaj się z zasadami projektowania, które wydają się być zgodne z Twoim produktem, a następnie podwój je. „ Wydaje się, że używamy tabel do wielu rzeczy, w tym wtedy, gdy użytkownicy muszą wybrać, z czym chcą się zaangażować ” być może staje się regułą: „ używamy wierszy tabeli, aby umożliwić użytkownikom wybór między pokrewnymi, ale niezależnymi elementami ”.
4. Uzyskaj konsensus od swojego zespołu (zespołów): przedstaw swoją ocenę i swój plan. Budowanie konsensusu łatwiej powiedzieć niż zrobić, ale zbudowanie tego systemu z istniejącego produktu sprawi, że ta rozmowa i przejście będą łatwiejsze niż wymyślanie zupełnie nowych wzorców i reguł. Z pewnością wielu z tych interesariuszy również przyczyniło się do tego, jak produkt wygląda dzisiaj, więc ta ścieżka bardziej szanuje ich role i całą wiedzę organizacyjną wbudowaną w istniejące projekty.
5. Zacznij budować z tym systemem: teraz, gdy wiesz, jakich zasad przestrzegać i wzorców, których należy używać, określ te wzorce i zacznij przestrzegać zasad! Następnym razem, gdy twoi inżynierowie wstawią tabelę, kartę, formularz itp., upewnij się, że jest to ten określony element i że używają go we właściwy sposób. Z czasem więcej elementów interfejsu będzie korzystało z tego nowego systemu projektowania, ale powinien on stosunkowo dobrze łączyć się ze starszymi częściami interfejsu.

Zalety

• TAKIE ZIELONE . Opierając nowy system luźno na istniejących wzorcach, szybciej dojdziesz do „dobrego”.
• „Dobre doświadczenia” stosunkowo dobrze mieszają się ze „starymi doświadczeniami”, zapewniając bardziej płynne wrażenia — tak, nawet podczas tych trudnych przejściowych miesięcy i / lub lat.
• Mniej dramatyczne zmiany oznaczają, że możesz szybciej zastosować nowe komponenty i wzory. Następnie, gdy wszystkie zostaną podłączone do systemu, możesz je zmieniać i aktualizować na poziomie systemu: zwiększa to szanse, że będziesz w stanie nadążyć za sąsiadami Jonesa (tj. własny nowy interfejs użytkownika.
• Mniej radykalna zmiana może być również dobra z punktu widzenia użytkownika: użytkownicy dość powszechnie nie lubią zmian (zobacz wszystkie przeprojektowania Facebooka lub przeprojektowanie na dużą skalę twojego ulubionego narzędzia B2B), więc unikanie ogromnych skoków może złagodzić wstrząsy w twoich relacjach z użytkowników/klientów.
• Jest to mniej zasobochłonne i bardziej naturalne dla Twojej organizacji organicznej. W przeciwieństwie do „rewolucji” i gigantycznych inicjatyw wykonawczych, może to lepiej utrzymać dobrą wolę zespołu. Sprawia, że ​​robienie dobrego projektu wydaje się właściwe , a nie tylko jako dużo naprawdę trudnej pracy.

• Nic!
• Żartuję. Jak widać, w tym modelu właściwie nie doszliśmy do „idealnej” fazy nirwany projektowej. Bardziej konserwatywny model „Ewolucji” umożliwił nam szybsze i łatwiejsze tworzenie dobrych projektów, ale być może nie skorzystaliśmy z możliwości związanych z „wielkimi pomysłami”, które w przeciwnym razie moglibyśmy mieć.
• Czasami praca na małą skalę i brak planowania „wielkiej wizji” może spowodować, że później w ewolucji systemu projektowego przeoczysz niektóre zależności i/lub możliwości. Istnieją sposoby, aby to złagodzić — np. poprzez jakąś wizję inną niż „zrób małe kroczki” — o czym opowiem później w bardziej szczegółowym poście.
• Czasami „stary” projekt produktu w twoim produkcie jest naprawdę, naprawdę zły, więc może nawet nie być dobrym punktem wyjścia. (Jest to kusząca mentalna droga do podążania, ale odradzam ci to: w większości przypadków, jeśli pracujesz nawet nad średnio udanym produktem, to coś w starym projekcie działa dobrze, czy ci się to podoba, czy nie ).

Twoim zadaniem jest poprawa doświadczeń klientów i użytkowników z Twoim produktem. Jeśli będziesz strzelać jak gwiazda nad każdym małym projektem, a następnie spalać mnóstwo zasobów inżynieryjnych, wprowadzając te zmiany w życie, możesz źle „wydawać” te zasoby, ograniczając w ten sposób ilość pracy, którą możesz wykonać, aby ulepszyć inne rzeczy dla swoich użytkowników . Czy doprowadzenie jednego przepływu użytkownika do perfekcji jest lepsze niż sprawienie, by przepływ trzech użytkowników był dobry ? Może dla Ciebie, ale prawdopodobnie nie dla Twoich użytkowników.

Podchodząc bardziej realistycznie do swojego systemu projektowego — budując go na istniejących podstawach i dbając o to, by był przyjazny dla zmian — możesz szybciej wdrożyć nowy system, a Ty (i Twoi użytkownicy) możecie zacząć czerpać korzyści.

Więc idź i ewoluuj!

Aktualizacja (około rok później)

Napisałem kolejny artykuł o tym systemie projektowania, nad którym pracowałem dla Hired — tym samym projekcie, który zainspirował ten artykuł „Ewolucja” rok wcześniej.

Złagodziłem nieco swoje stanowisko w sprawie podejścia „podobnego do Gwiazdy Północnej”, biorąc pod uwagę pewne wnioski z tego projektu, ale główne założenia tego postu nadal obowiązują: w większości przypadków ewolucja jest nadal odpowiedzialnym podejściem do użytkowników, produktu i Twojej organizacji.