Smashing Podcast Episode 9 With Stephanie Walter: Jak mogę pracować z ramami interfejsu użytkownika?

Jako programista, jedną z rzeczy, które lubię we frameworkach UI, jest to, że często mają domyślny styl, ale czy jest to coś, na czym powinniśmy polegać w projektach? Po prostu używając domyślnego stylu i ufając, że ktokolwiek wyprodukował framework, wykonał naprawdę dobrą robotę przy projektowaniu tych komponentów? Dołącz do mnie w dzisiejszym odcinku podcastu, w którym rozmawiam z projektantką UX Stephanie Walter o rzeczach, które powinniśmy wziąć pod uwagę podczas tworzenia frameworka UI.

Pokaż notatki

• Strona Stephanie
• Stephanie na Twitterze

Cotygodniowa aktualizacja

• „Jak stworzyć grę w dopasowywanie kart za pomocą Angular i RxJS” autorstwa Anny Prenzel
• „Jak stworzyć bezgłową witrynę WordPress na JAMstack” autorstwa Sarah Drasner
• „Magiczne karty flip: rozwiązywanie powszechnego problemu z rozmiarem” Dana Halliday'a
• „Najważniejsze cechy Django: modele użytkownika i uwierzytelnianie (część 1)” autorstwa Philipa Kiely
• „Jak tworzyć mapy z React i ulotką” Shajia Abidi

Transkrypcja

Drew McLellan: Jest projektantką skoncentrowaną na użytkowniku i ekspertem w dziedzinie mobilnej obsługi, która skrzyżowała wspaniałe produkty i interfejsy ze szczególnym naciskiem na wydajność. Pracowała nad projektami dla klientów, takich jak Uniwersytet Luksemburski, Europejski Bank Inwestycyjny, BMW i Microsoft, żeby wymienić tylko kilka, i pomaga tym klientom dostarczać udane projekty swoim odbiorcom przez całą drogę od strategii do produktu końcowego. Jest ekspertem Google Developer w zakresie projektowania produktów i pełnym pasji nauczycielem dzielącym się swoją wiedzą w licznych postach na blogach, artykułach, warsztatach i prezentacjach konferencyjnych. Więc wiemy, że jest ekspertem w projektowaniu doświadczeń użytkowników, ale czy wiesz, że kiedyś pracowała przy przymierzaniu dywanów u Sir Eltona Johna? Moi Smashingowi przyjaciele, witajcie proszę Stephanie Walter. Witaj Stephanie, jak się masz?

Stephanie Walter: Cześć, rozwalam i uwielbiam wprowadzenie.

Drew: Chciałem więc dziś z tobą porozmawiać o konkretnym problemie i jest to temat korzystania z gotowych frameworków interfejsu użytkownika. Teraz jesteś projektantem doświadczeń użytkownika i pracujesz z wieloma różnymi klientami, a Twoim zadaniem jest pomaganie tym klientom w tworzeniu najlepszych możliwych doświadczeń użytkownika poprzez tworzenie wysoce użytecznych interfejsów użytkownika. Więc pomysł, aby móc to zrobić za pomocą gotowego zestawu narzędzi, wydaje mi się trochę naciągany. Czy korzystanie z frameworka UI jest czymś, co często widzisz w swojej pracy?

Stephanie: Tak, często to widziałam, zwłaszcza w ciągu ostatnich kilku lat, ponieważ zaczęłam pracować z agencją, a teraz pracuję w firmie. Więc w tych super dużych zespołach IT i tak, w tej chwili jest wiele interfejsów użytkownika, takich jak ten, który widziałem najczęściej, to Material-UI, zasadniczo Material design to rodzaj wytycznych i rzeczy Google w zakresie projektowania, a także Material -UI to zespół Angulara, ale także zespół Reacta. Stworzyli własne ramy, korzystając z wyglądu i stylu projektu Material od Google. Ale to już nie ma nic wspólnego z Google. To tak jak oni, nie wiem, myślę, że podobał im się wygląd i styl. W tej chwili są to dwa główne frameworki UI, z którymi pracuję. Jest też coś, co nazywa się Ant Design, które stało się bardzo popularne.

Stephanie: To framework React. Nie wiem, czy mają też Angulara. Myślę, że zrobił to zespół z Chin. I jest to interesujące, ponieważ nie tylko dostarcza komponenty, wszystko w React, ale jeśli wejdziesz na ich stronę internetową, otrzymasz również pliki zdrapek, co jest w rzeczywistości dość interesujące, ponieważ w pewnym sensie motywuje lub pomaga projektantowi budować lub kształtować interfejs do komponentów interfejsu użytkownika używanych przez tę platformę. Więc tak, to coś, co często widziałem, zwłaszcza w dużych zespołach IT, ponieważ w większości przypadków nie mają one projektanta. W tej chwili jestem zasadniczo zespołem UX składającym się z jednego w małym zespole w europejskim banku inwestycyjnym. Więc to ja jako projektant UX. Pracuję z zespołem programistów, analityków biznesowych, wszystkich dobrych ludzi, ale wciąż jestem jednym projektantem dla całego projektu.

Stephanie: Dopóki nie przyjechałem, nie było projektanta. Jest to więc rodzaj rozwiązania wdrożonego w wielu firmach, zwłaszcza na przykład na produktach wewnętrznych. Tam, gdzie zwykle mówią, dobrze, tak naprawdę nie potrzebujemy do tego projektanta. Potrzebujemy tylko czegoś, co działa dla naszych wewnętrznych użytkowników i po prostu użyjmy frameworka, ponieważ jest to wygodne dla programistów. Większość komponentów już tam jest, a ponieważ w zespole nie ma projektantów, zastępuje to, że tak powiem, rolę projektanta interfejsu użytkownika. Tak, problem polega na tym, że ok, masz komponenty, ale rolą projektanta interfejsu użytkownika nie jest tylko decydowanie o tym, czy przycisk ma być czerwony, zielony, pomarańczowy, niebieski, cokolwiek. Zwykle rolą projektanta UI jest architektura informacji, zrozumienie potrzeb użytkownika. Czyli wszystko, co wykracza poza interfejs. Więc nawet jeśli masz tego rodzaju ramy, to troszczy się o cały interfejs użytkownika, więc wizualnie to, co widzisz na ekranie.

Stephanie: Nadal potrzebujesz kogoś, kto w pewnym momencie zajmie się zrozumieniem tego, co umieścimy na ekranie, jak będzie się zachowywał? Co się stanie, gdy klikniemy tutaj? Jak użytkownik osiąga swój cel? Jak przejść z punktu A do punktu B? Ponieważ możemy użyć modelu, możemy korzystać z zakładek, możemy korzystać ze wszystkich komponentów. Dlatego zawsze jest to trochę skomplikowane i trudne.

Drew: Czy to możliwe, czy myślisz, że będziesz w stanie stworzyć użyteczny interfejs użytkownika przy użyciu gotowego frameworka UI, czy zawsze będzie to trochę kompromisem?

Stephanie: Mam taką nadzieję. Mam taką nadzieję, bo inaczej buduję nieużyteczne interfejsy. Więc ta odpowiedź jest całkowicie stronnicza, ale tak, myślę, że tak, ale zależy to również od poziomu kompromisu, jaki jesteś w stanie zrobić i są kompromisy po obu stronach. W tej chwili na przykład kompromituję wiele przycisków, ponieważ masz naprawdę specyficzne przyciski w Material-UI i nie podoba mi się efekt ripple na przycisku. Myślę, że działa to świetnie na urządzeniach mobilnych, ponieważ na urządzeniach mobilnych potrzebujesz pewnego rodzaju dużej informacji zwrotnej, gdy użytkownik kliknie lub dotknie przycisku. Ale wtedy kroki są rodzajem efektu falowania, który przechodzi przez cały przycisk. To trochę przesada, zwłaszcza gdy jest dużo przycisków. Ale nadal zamierzamy zachować ten efekt, ponieważ usunięcie go byłoby bardzo skomplikowane, ponieważ zostało to wbudowane w framework React. I żeby mieć kolejny efekt najechania na ten przycisk, coś bardziej subtelnego, co nie będzie tutaj tego rodzaju szumem. To byłoby bardzo złożone.

Stephanie: Więc to jest rodzaj kompromisów, które robisz. Ale tymczasem nie idę na kompromis w kwestii konkretnych rzeczy, czyli komponentów niestandardowych. Tam gdzie wcześniej pracowałem, obecny klient dla firmy turystycznej i lotniczej. A linia lotnicza ma bardzo, naprawdę bardzo specyficzne potrzeby. Na przykład kalendarz dla linii lotniczych, chcesz podać ceny, chcesz umieścić… jeśli nie lecisz do tego miejsca w określonym dniu, nie wiesz, kiedy to umieścić, masz ten wylot i przylot i podstawowy kalendarz większości z tych frameworków UI nie zapewnia tego rodzaju rzeczy. Więc w pewnym momencie możesz powiedzieć, w porządku, po prostu użyjemy kalendarza, który mają. I to wszystko. Musisz wyjść poza to. Więc większość kompromisów opiera się na zasadzie, czy używamy podstawowego komponentu? Czy tworzymy taki niestandardowy, który będzie odpowiadał potrzebom użytkownika? A może tworzymy mieszankę tych dwóch? W przypadku kalendarza, na przykład, używamy siatki kalendarza, więc korzystamy z podstawowego komponentu, a następnie wzbogaciliśmy go o personalizację. Więc to było dużo prac nad Reactem.

Stephanie: I tak, więc zazwyczaj idziesz na wiele kompromisów.

Drew: Wygląda na to, że użycie frameworka interfejsu użytkownika może pomóc w osiągnięciu pewnego poziomu, ale aby naprawdę mieć dobry interfejs użytkownika w wyniku tego, musisz zrobić sporo dostosowań na górze?

Stephanie: Zwykle. Tak.

Drew: Czy to dostosowanie wykracza poza motywy?

Stephanie: Tak, mój programista chciał, żeby to nie wychodziło poza tematykę. Eugene Jeśli mnie posłuchasz. Myślę, że byłby bardzo szczęśliwy, gdybyśmy po prostu zmienili kilka kolorów we wszystkim. Ale tak, w pewnym momencie musisz wyjść poza dostosowywanie, ponieważ po pierwsze, tak jak frameworki UI są jak narzędzia Lego, są rodzajem zestawu narzędzi. W pudełku jest więc wiele różnych komponentów, ale to nie tworzy strony. Nadal potrzebujesz nagłówka, nadal potrzebujesz stopki. Nadal potrzebujesz dodatkowej zawartości, której nie było w ramach. Więc czasami możesz dostosować komponent do tego, czego potrzebujesz. Z tego, co zrozumiałem, używamy komponentu karty do budowania okien modalnych, ale rzecz z oknami modalnymi polega na tym, że tak naprawdę nie zachowuje się jak karta.

Stephanie: Trochę wychodzisz poza to. Potrzebujesz tła z zaciemnieniem. Musisz go uruchomić po kliknięciu, podczas gdy zwykle Twoja karta jest już w interfejsie. Używamy tego komponentu karty, ponieważ ma wiele rzeczy, których potrzebujemy, takich jak tło, nagłówek i tytuł na górze, kilka przycisków na dole. Mamy więc strukturę, a potem trochę ją poprawiamy. Ale kończy się czasem konfliktem dotyczącym semantyki, a także HTML. Ponieważ na przykład chciałem mieć przyciski, które nie miały kształtu przycisków, więc podobnie jak przycisk linku, a programista powiedział: „OK, więc używamy linku takiego jak link href”. Powiedziałem: „Nie, to nie jest łącze. To przycisk. Kiedy go klikną, nie otworzy nowej strony. Oczyszcza wszystko, co jest w formie.”

Stephanie: Więc technicznie z semantycznego punktu widzenia powinien to być przycisk. "Tak. Ale to nie istnieje w ramach.” Mówię „W porządku, wiem, co robimy?” Więc zwykle zaczynasz omawiać te małe rzeczy, a ponieważ naprawdę denerwuję moich programistów również dostępnością, jest to kolejna dodatkowa warstwa, polegająca na upewnieniu się, że mamy podstawowe komponenty, z którymi dobrze współpracują. Ale są też semantycznie jakbym nie chciał mieć przycisków z gifami w gifach w gifach. W przeciwnym razie w końcu będziemy mieć problemy.

Drew: Myślę, że rozpoczynając nowy projekt, który będzie używał frameworka UI, prawdopodobnie będziesz musiał zacząć od jakiegoś rodzaju badań użytkowników.

Stephanie: Tak.

Drew: Czy to sprawiedliwe?

Stephanie: Powinnaś. Musisz. Więc tak, zwykle możesz mieć wszystkie komponenty, które chcesz. Nadal musisz wiedzieć, czego Twoi użytkownicy potrzebują na stronach, jak będą się poruszać? Musisz zbudować przepływ. Dlatego zwykle jeszcze przed podjęciem decyzji o frameworku, idziemy do naszych użytkowników, rozmawiamy z nimi, staramy się zrozumieć ich potrzeby. Więc w tej chwili mam szczęście, ponieważ użytkownicy są wewnętrznie w banku. Więc robimy z nimi wiele warsztatów i musisz sobie wyobrazić, że to bardzo złożony interfejs. Przechodzimy z czegoś, co zostało zbudowane, nie wiem, myślę, że 10 lub nawet 15 lat temu do czegoś zupełnie nowego, błyszczącego za pomocą Material-UI React. Więc to całkiem duża zmiana i trzeba zrozumieć, że przez te 15 lat każdy, kto czegoś chciał, mógł pójść do wsparcia, a potem poprosić zespół IT o wdrożenie. Więc w tej chwili mój interfejs jest jak 400 stron z tabelami, w tabelach, w tabelach, z innymi tabelami i rzeczami, których nawet nie powinno być w tabelach.

Stephanie: Tak jak mamy wiele rzeczy, które są po prostu kluczową wartością, kluczową wartością, kluczową wartością. Więc budują stół z dwiema kolumnami. Mówię: „Nie, może uda nam się z tym zrobić coś lepszego”. Dlatego w tej chwili zrobiliśmy kilka badań użytkowników, aby zrozumieć różne cele użytkowników. Zidentyfikowaliśmy więc, że to, co robią z interfejsem, mają pewne cele związane z planowaniem. Muszą zaplanować swoją pracę. Więc chcę wiedzieć, że ta operacja pójdzie na to spotkanie, więc potrzebuję tego w tym harmonogramie, takie rzeczy. Chcą coś monitorować, chcą raportować dane. Tak więc monitorowanie jest jak przeglądanie danych i upewnianie się, że wszystko jest w porządku. Raportowanie to możliwość wykorzystania danych, zrobienia z nimi czegoś, czym chcą się podzielić, i pewnego rodzaju współpracy z kolegami, a wszystko to, co odkryliśmy, dyskutując bezpośrednio z użytkownikami.

Stephanie: Odkryliśmy , że w rzeczywistości niektóre z rzeczy, które planowaliśmy przenieść pod koniec, są jednymi z najważniejszych na co dzień dla użytkownika. Tak więc cel użytkownika planowania jest obecnie jednym z największych. Więc naprawdę, naprawdę nad tym pracujemy. Więc tak, korzystamy z wywiadu i teraz jesteśmy w fazie, w której w tej chwili jesteśmy na bardzo wysokim poziomie, mówiąc ok, musimy zbudować powłokę, musimy zrozumieć nawigację. Ale w tej chwili tak naprawdę nie przejrzeliśmy wszystkich danych i to właśnie zamierzamy zrobić. I to jest interesujące, ponieważ mamy wiele tabel i powiedzieliśmy, że możemy albo pójść w niezbyt mądry sposób i po prostu umieścić tabele w nowym interfejsie i gotowe, albo możemy powiedzieć, ok, spróbujmy zrozumieć, co te tabele to: Do ​​czego nasi użytkownicy używają tej tabeli?

Stephanie: A potem może niektóre tabele można wyświetlić jako wizualizację danych, a żeby to zrobić, musisz zrozumieć cały biznes, aby dane miały sens. Więc jeśli masz fajny framework i mówisz, dobrze, użyjmy tego wykresu… Myślę, że nazywa się to frameworkiem JS wykresu. Masz wiele rzeczy, możesz mieć histogram, wykresy kołowe, wykresy i wszystko inne, ale w pewnym momencie nadal potrzebujesz projektanta, który pomoże Ci podjąć decyzję. Ok, te dane, czy ma to sens, jeśli pokażemy je na wykresie, czy bardziej sensowne będzie pokazanie ich w postaci tortu, ponieważ chcemy pokazać część całości, czy też chcemy porównać ewolucję jednego kraju w ostatnich 10 lat, wtedy histogram jest ciekawszy. Więc w oparciu o to, co użytkownik chce zrobić z danymi, będziesz wyświetlać je w zupełnie inny sposób.

Stephanie: I zazwyczaj nie jest to praca programisty. Nasz programista, to super mądry facet. Przykro mi, ale szczerze pracuję z chłopakami, żałuję, że nie mam paru pań, ale nie. Żadna z nich nie jest kobietami. Więc super mądrzy faceci, ale nie są super wykwalifikowani, by powiedzieć, w porządku, te dane powinny być wyświetlane w ten sposób, tamto, tamto i tamto. Więc w końcu nadal potrzebujesz kilku projektantów, którzy porozmawiają z użytkownikami, zrozumieją, co możesz zrobić z danymi, a to znacznie wykracza poza samo powiedzenie: okej, powinien to być pasek kart lub nawigacja po lewej stronie.

Drew: I po podjęciu tego rodzaju decyzji w oparciu o rozmowę z użytkownikami. Czy zwykle zabierałbyś powstałe prototypy lub projekty z powrotem do użytkowników, aby przetestować je ponownie, aby sprawdzić, czy na przykład rozumieją Twój typ wykresu?

Stephanie: Tak, właściwie to robiliśmy, co jest naprawdę miłe, ponieważ wtedy nie rozwijasz czegoś, dopóki nie wiesz, że będzie to przydatne i użyteczne. Więc to zależy. Jeśli szybciej jest faktycznie rozwijać rzecz, ponieważ mają już większość komponentów, zwykle robię naprawdę szybkie prototypowanie na papierze, a następnie rozwijamy rzecz, ponieważ jest ona szybka, nawet bez danych. Jeśli jest to coś złożonego, coś naprawdę, naprawdę nowego, którego opracowanie zajmie dużo czasu, wtedy mówimy, w porządku, projektujemy kilka ekranów i przeprowadzamy testy bezpośrednio na ekranie. Mamy więc narzędzie o nazwie InVision, w którym w zasadzie umieszczasz cały swój projekt, możesz tworzyć połączenia między różnymi częściami. Chodzi o to, że zależy to również od tego, co chcesz przetestować. Jeśli chcesz na przykład testować telefony, koszmarem jest testowanie ich w InVision, ponieważ ludzie tak naprawdę ich nie czują, a zwłaszcza na przykład na telefonie komórkowym.

Stephanie: Więc zawsze jest trochę sprytnie. Jaki jest najszybszy i najtańszy sposób? Czy testowanie samych projektów jest szybsze i tańsze. Czy to wystarczy? W przypadku formularzy zwykle, nie tak naprawdę, ponieważ masz automatyczne uzupełnianie wszystkich ciężkich prac, które wkładasz w interfejs użytkownika, a użytkownik faktycznie wypełnia formularz, więc w przypadku formularzy może bardziej efektywne jest zbudowanie formularza i przetestowanie go. Ale dla nowych rzeczy, tak, robimy wiele projektów. Idziemy do użytkowników. Więc w tej chwili albo robimy jeden na jeden, ale moi użytkownicy są naprawdę zajętymi ludźmi. To europejski bank inwestycyjny, więc nie mają tak dużo czasu. Więc to, co zwykle robimy, to to, że jeśli spotykamy się z użytkownikami sam na sam, robimy małe spotkania, bardziej przypominające grupy fokusowe. I jest to również interesujące, ponieważ czasami dochodzi do konfrontacji. Niektórzy ludzie mówią: „Tak, myślę, że to działa dla mnie, ponieważ pracuję w ten i inny sposób”, a inni ludzie mówią: „Och, pracujesz w ten sposób? Właściwie nie, robię to tak i tak.”

Stephanie: Interesujące jest także, gdy w pokoju jest kilka osób i słuchają tylko rozmowy, robią notatki i mówią: „Och, może wtedy moglibyśmy to zrobić” i „Ten element byłby lepszy w oparciu o to, co właśnie zrobiłem”. słyszał." I podobne rzeczy.

Drew: Jeśli pracujesz z bardziej ogólnymi odbiorcami swojego produktu. Więc może nie użytkownicy wewnętrzni, tacy jak ty, ale bardziej ogół społeczeństwa, czy istnieją niedrogie sposoby, dzięki którym projektanci mogą wykorzystać badania? Czy są łatwiejsze sposoby, jeśli nie wiesz bezpośrednio, kim będą Twoi użytkownicy?

Stephanie: Powinnaś wiedzieć, kim będą, w przeciwnym razie zrobi to zadanie marketingowców przed zbudowaniem produktu. Ale tak, na przykład przeprowadziliśmy testy partyzanckie. Nadal możesz na przykład używać InVision. Możesz więc zbudować kilka prototypów w InVision, a następnie rekrutować użytkowników na przykład za pośrednictwem mediów społecznościowych. Pracowałem dla produktu, który pomagał, jak to się nazywa, mechanikom z salonów samochodowych, którzy naprawiają rzeczy, a następnie informują klienta o naprawach dodatkowych, tego typu rzeczach. Więc mieliśmy już rosnącą społeczność na LinkedIn i Facebooku. Możesz więc zrekrutować tych ludzi. Możesz przeprowadzić zdalne testy, tak jakbyśmy prowadzili rozmowę w narzędziu takim jak narzędzie online. Możesz udostępnić ekran. Więc zrobiliśmy to również dla jakiegoś projektu.

Stephanie: Dałabym ci tylko jedną radę, to przetestować narzędzie wcześniej, ponieważ używałem, nazywało się to see.in. Ale myślę, że zmienili nazwę na Whereby lub coś takiego, ale tak naprawdę jest w przeglądarce, o której powiedziałem, ok, to miłe, ponieważ wtedy użytkownicy nie muszą niczego instalować, ale użytkownicy nie byli na prawdziwym komputerze. Byli w maszynie wirtualnej, w Citrixie i nie mieli mikrofonów, więc skończyliśmy tak, jakby używali mojego narzędzia do udostępniania ekranu. Klikali na prototyp, a ja w tym samym czasie miałem ich przez telefon, jak telefon stacjonarny, żeby rozmawiali z nimi bezpośrednio. Więc zawsze jest to dość tanie, ponieważ był to wspaniały dzień rekrutacji, myślę, że mieliśmy 10 użytkowników lub coś takiego. Tak, możesz zrobić wiele rzeczy, nawet jeśli nie możesz stanąć twarzą w twarz. Przeprowadziłem wiele testów użyteczności bezpośrednio na Skypie lub podobnych rzeczach. Więc zawsze jest kilka tanich sposobów na zrobienie tego.

Drew: Jeśli chodzi o wybór frameworka UI do pracy, czy jest to droga, którą podążasz, czy jest to coś, co pozostawiłbyś tylko programistom, czy jest to coś, w co projektanci również powinni się zaangażować?

Stephanie: Dla mnie powinieneś zaangażować cały zespół. Podobnie jak projektanci, programiści, może także architekci, jeśli takich masz, ponieważ sposób zbudowania frameworka może również wpływać na tego rodzaju rzeczy. Niestety, przez większość czasu, gdy przyjeżdżają do projektu, ramy były już ustalone. Nie, właściwie to zabawne, albo już zdecydowano, albo proszą mnie o potwierdzenie wyboru frameworka, ale nie robiłem żadnych recenzji ani badań. Nie mam pojęcia, co jest w projekcie, bo nawet nie pokazali mi swoich ekranów. Mówią: „Tak, rób swoje. Możemy użyć tego frameworka.” Nie wiem Cóż, czy mamy ekran? Skończyło się na tym, że pokazali kilka ekranów, czyli natywną aplikację systemu Windows, którą chcieli przenieść do chmury. Powiedzieli: „Tak, potrzebujemy tylko przycisków i głównie lubimy formularze i tego typu rzeczy”.

Stephanie: Ale naprawdę trudno powiedzieć: „Tak, wybierz ten framework, mamy wszystkie potrzebne komponenty”. Lub jak: „Nie idź, jeśli nie masz ogólnego pojęcia, jakie będą Twoje treści, jaka jest nawigacja”. Myślę więc, że powinieneś mieć ogólny przegląd przed wyborem swoich frameworków, chyba że jesteś w 100% pewien, że masz wszystkie komponenty. Ale mam wrażenie, że przez większość czasu wybór frameworka opiera się w zasadzie na tym, jakie technologie lubią obecnie deweloperzy, czy mają oni wcześniej doświadczenie z frameworkiem? Używaliśmy Anta w niektórych projektach tylko dlatego, że kilku programistów miało z tym doświadczenie i naprawdę im się to podobało i byli w pewnym stopniu wydajni przy użyciu Anta. Podobnie jest z interfejsem Material React. To tak, jakby programista używał go już w poprzednich projektach, więc są z nim wydajni.

Drew: Tak naprawdę musi to być równowaga między tym, z czym programiści czują się komfortowo, co wiedzą, co będzie działać z ich stosem technologicznym, a następnie, jakie są wymagania produktu w zakresie tworzenia dobrego interfejsu użytkownika. I musisz jakoś zrównoważyć te dwa, aby znaleźć idealne ramy dla tego.

Stephanie: Tak. Mam pewien specyficzny wymóg dotyczący pewnego projektu, który jest… Jestem w Luksemburgu, mamy wiele instytucji europejskich i tego typu rzeczy, więc mamy dodatkowy wymóg dostępności dla niektórych z nich. I zwykle, kiedy ustalano ramy, tak naprawdę nie sprawdzali dostępności swojego frameworka, a potem wracali kilka miesięcy po rozpoczęciu projektu, mówiąc: „Och, właśnie powiedzieli nam, że jest to nowe prawo i powinniśmy być dostępnym, ale nie wiemy, jak to zrobić”. Tak, trochę za późno. Tak więc dla mnie, aby wybrać framework, musisz naprawdę znać wszystkie ograniczenia na początku projektu, a jeśli dostępność jest jednym z nich, musisz przetestować swoje komponenty i upewnić się, że będą one dostępne. Ale nie jestem programistą React ani Angular, ale jestem prawie pewien, że przekształcenie niedostępnego frameworka UI w coś dostępnego jest bardzo skomplikowane. Myślę, że odbudowanie wszystkich komponentów może być trochę skomplikowane, więc takie rzeczy.

Drew: Jeśli pracujesz nad projektem, w którym ten proces nie miał miejsca, a framework interfejsu użytkownika został już wybrany, czy istnieje niebezpieczeństwo, że interfejs użytkownika może zacząć podlegać wpływom komponentów, które już istnieją w tym frameworku, a nie kierując się potrzebami użytkownika?

Stephanie: Naprawdę, szczerze, większość projektów, nad którymi pracowałem, kończy się na wielu kompromisach, nawet jeśli naprawdę próbujesz forsować. Więc chodzi głównie o równowagę i dyskusję z twórcami. Więc zwykle robię kilka ramek z drutu, nawet szybkich ramek z drutu papierowego, powiedzmy dobrze, na tej stronie będziemy potrzebować tego i tego i tego komponentu, pierwszą rzeczą, którą robię, jest pytanie programisty, czy mamy to w naszym w tej chwili? Jak to wygląda? A potem wspólnie decydujemy, ok, to jest składnik, który wykona zadanie lub ok, to nie zadziała. Czy to poprawiamy? Na przykład, czy nadal zachowujemy komponent, ale zmieniamy go trochę, aby spełniał swoje zadanie, czy też budujemy coś od podstaw?

Stephanie: I pod koniec dnia będzie to oczywiście zależeć od budżetu. Więc skończyło się na kompromisach. Jakbym był w porządku z małymi komponentami, które prawie nigdy nie są używane, jeśli nie są idealne i jest trochę problemów. Ale dla głównej nawigacji, głównej struktury, rzeczy, które widzisz cały czas na ekranie, na przykład, to naprawdę musi działać. Użytkownik musi zrozumieć, w jaki sposób działa wydajnie i tak, to, jak powiedziałeś, znalezienie równowagi między idealnym doświadczeniem, jakie chciałbyś mieć, gdybyś nie miał żadnych ram, a tym, co masz pod ręką, a budżetem, a także wyczucie czasu. Jeśli powiemy, OK, dla tych sprintów, funkcja musi zostać ukończona na końcu tego sprintu, a potem powiedzą, dobrze, ale jeśli chcesz mieć swoje komponenty, nigdy nie zakończymy funkcji na końcu tego sprintu, to ty zacznij dyskutować, ok, czy skończymy tę funkcję na następnym ekranie, czy zajmiemy więcej czasu, aby zrobić to poprawnie? I zwykle to naprawdę zależy.

Stephanie: Najbardziej frustruje mnie to, kiedy wiem, że używamy elementu do naprawy upraw, a oni mówią do mnie: „O nie, nie martw się”. Naprawimy to później. I wiedziałem, że później niestety może się nigdy nie wydarzyć. Więc zależy od zespołu. Ale po pewnym czasie masz doświadczenie i wiesz, czy to później nadejdzie, czy nie? Tak, chodzi o kompromisy. Kiedy pracujesz z tego rodzaju narzędziami.

Drew: Jako programista, jedną z rzeczy, które lubię we frameworkach UI, jest to, że często mają domyślny styl. Oznacza to, że niekoniecznie muszę mieć projektanta, który pomógłby mi w wyglądzie wszystkich komponentów. Czy to jest coś, na czym powinniśmy polegać w projektach? Tylko domyślna stylizacja i zaufanie, że ktokolwiek wyprodukował framework, wykonał naprawdę dobrą robotę przy projektowaniu tych komponentów? A może sam stylizowałbyś te elementy?

Stephanie: Myślę, że to naprawdę zależy. Problem na przykład z Material-UI polega na tym, że wygląd Twojej aplikacji internetowej będzie w zasadzie skonfigurowanymi produktami Google. Więc jeśli faktycznie nie zmienisz czcionki, zmienisz kilka kolorów i nie przyniesiesz własnej tożsamości marki i to zrobisz, otrzymasz produkt, który będzie wyglądał jak każdy produkt Google, co może być dobrą rzeczą, ponieważ jeśli Twoi użytkownicy są przyzwyczajeni do produktów Google, co może im pomóc w ich zrozumieniu. Więc zazwyczaj, jeśli nie masz w zespole projektanta, czy masz jakiś wybór? Podobnie jak wiele innych prac, które widziałem, mają niestandardowe motywy, więc przynajmniej możesz zmienić kolory. Myślę, że możesz również dość łatwo zmienić czcionki. Ale znowu, jeśli zmienisz kolory i nie jesteś zbyt dobry w projektowaniu, a nawet dostępności, być może kolory, których użyjesz, będą się kolidować, mogą mieć problemy z kontrastem.

Stephanie: Na przykład uwielbiam pomarańczowy, ale jest to jeden z najbardziej irytujących kolorów do pracy, ponieważ naprawdę dostępny pomarańczowy, na przykład przycisk z białym tekstem, wygląda prawie na brązowo. A jeśli chcesz mieć tę naprawdę błyszczącą pomarańczę, potrzebujesz ciemnego tekstu na wierzchu, aby była czytelna, ale to trochę sprawia, że ​​twój interfejs wygląda jak Halloween pod koniec dnia. Tak, widzę, że się śmiejesz. Ale to prawda. Więc zawsze chodzi o tego rodzaju kompromisy i mówisz, że jeśli jesteś programistą i chcesz używać frameworka takim, jaki jest, a nie masz projektanta, myślę, że to i tak lepsze niż nie mieć niczego i budować go od zera i to jest bardzo skomplikowane w użyciu. Ale chodzi o to, że tylko dlatego, że masz komponenty, nie oznacza to, że zbudujesz świetny interfejs. To jak klocki Lego. Jeśli masz klocki Lego, ok, w porządku, ale możesz zrobić naprawdę fajny statek kosmiczny lub możesz zrobić coś, co nie trzyma się razem i rozpadnie się, ponieważ tak naprawdę nie miałeś planu.

Stephanie: A więc projektowanie to coś więcej. Projekt polega na prawdziwym zrozumieniu tego, co będzie na ekranie, jak to będzie działać. I znam kilku programistów, którzy faktycznie mają takie możliwości. Są więc naprawdę dobrzy w zakresie wytycznych dotyczących użyteczności i na przykład rozumieją wiele zasad projektowania. Więc jeśli chodzi o dobór komponentów, są w tym naprawdę dobre. A znam programistów, którzy nie mają pojęcia, jakie komponenty wybrać i wybierają ten pierwszy, który spełnia swoje zadanie. Ale po chwili to już nie działa. Jak na przykład zakładki, mieliśmy interfejs, w którym niektórzy programiści wybierali zakładki. Myślę, że na początku ma to sens, gdy masz tylko trzy przedmioty. Ale potem na ekranie było 12 pozycji, a potem były zakładki, które są trzema liniami zakładek, a wszystkie są tymi samymi zakładkami pierwszego poziomu i są zakładki w zakładkach. Mieli więc komponent, który wyglądał ładnie, ponieważ używali frameworka, ale tak naprawdę nie był użyteczny.

Stephanie: I miałam to samo, na przykład z modalnymi oknami. Gdzie budują projekty bez projektanta i myślę, że po pewnym czasie klient prosił o coraz więcej rzeczy do tego modalu. Więc skończyło się na ekranie z tabelą, a kiedy klikniesz na dodaj wiersz, otworzysz modalny, a w tym modalnym masz dwie zakładki, a następnie w jednej z tych zakładek masz nawet inną tabelę, a potem chcieli dodaj do tego dodatkowe rzeczy, pomyślałem, ok, może możemy umieścić modal na modal. I w pewnym momencie projektant odpowiedziałby: OK, jeśli masz tak dużo treści w modalnym, nie powinno to być okno modalne. Powinna to być strona. Więc nawet jeśli masz ten komponent, nadal potrzebujesz architekta, który wykona plan i upewni się, że wszystkie te komponenty dobrze ze sobą współpracują.

Drew: Więc jeśli jako projektant jesteś proszony o zmianę stylu niektórych komponentów, czy spróbowałbyś po prostu zmienić całą stylizację? Czy spersonalizowałbyś to wszystko, czy są pewne obszary, na których mógłbyś się skupić?

Stephanie: Wydaje mi się, że kolory, ponieważ to pierwsza rzecz, którą widzisz, kolory mogą rzeczywiście dać ci tożsamość. Jeśli masz silną tożsamość marki, przynajmniej posiadanie kolorów twojego produktu na przyciskach lub ikonach i tym podobnych, już pomaga ci dostosować ramy. Czcionki, ponieważ myślę, że jest to łatwe, jeśli framework jest dobrze zbudowany, zwykle zmieniasz w jakimś miejscu całą rodzinę czcionek, a potem powinno to być kaskadą na reszcie witryny. Więc kolory i czcionki są moim zdaniem dwoma prostymi sposobami na szybkie dostosowanie frameworka. Ikony to kolejny fajny sposób na nadanie osobowości, ale może to być trudne, ponieważ z tego, co widziałem, większość frameworków zawiera niestandardowe ikony lub Font Awesome lub podobną bibliotekę już wbudowaną. Aby je zastąpić, najpierw potrzebujesz wiele ikon, jeśli chcesz je wszystkie zastąpić. Więc może to być trochę skomplikowane. Widziałem również frameworki, które pozwalają wybrać pakiet ikon, którego chcesz użyć. jak Font Awesome, Glyphicons i kilka innych. Więc to jest rodzaj rzeczy, które można łatwo dostosować.

Stephanie: A potem chodzi o wygląd i styl, na przykład nagłówek, zwykle masz różne rodzaje nagłówków, stopek. Jak nawigujesz takimi rzeczami. Istnieje już wiele drobnych dostosowań, które możesz wprowadzić, aby nie wyglądały na materiałowy interfejs użytkownika, bardziej przypominają twoją markę, a następnie możesz na przykład bawić się promieniem obramowania. Niezależnie od tego, czy chcesz całkowicie zaokrąglone guziki, czy chcesz kwadratowe, czy też chcesz coś pośrodku, na przykład cienie. Więc kilka małych rzeczy, które są zazwyczaj łatwe do dostosowania, ponieważ większość tych frameworków ma je w zmiennych CSS. To jest rodzaj małych rzeczy, które można dostosować bez dużego wysiłku, z wyjątkiem tych efektów. Nienawidzę tego. Zamierzam z tym walczyć. Mam nadzieję, że w końcu to zmienią.

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn't easy to change? Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. Do you know?

Drew: Yup.

Stephanie: It does. Dobra. So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.