Projekt na dużą skalę: rok z Figma

Z tego artykułu dowiesz się, jak duże zespoły mogą skorzystać z bardziej otwartych narzędzi do współpracy oraz jak sprawić, by adopcja i migracja były możliwe i przyjemne. Ponadto, jeśli jeszcze nie zgadłeś z tytułu artykułu, wiele z niego będzie dotyczyło Figmy i tego, jak udało nam się zastosować to narzędzie do projektowania w naszym zespole.

Docelowi odbiorcy to doświadczeni projektanci pracujący w większych zespołach z systemami projektowymi, programiści lub menedżerowie produktu, którzy chcą ulepszyć sposób pracy zespołów wielofunkcyjnych w ich organizacji.

Używam narzędzi projektowych w profesjonalnym otoczeniu od ponad dziesięciu lat i zawsze staram się, aby zespoły, którym służę, pracowały wydajniej i wydajniej. Od skryptów i działań w Photoshopie, przez biblioteki widżetów w Axure, po wtyczki Sketch, a teraz z Figma — pomogłem zespołom projektowym pozostać w czołówce, nie zostawiając programistów czy menedżerów produktu w tyle.

Podstawowa wiedza na temat systemów i narzędzi projektowych będzie pomocna, ale nie potrzebna, ponieważ mam nadzieję podzielić się konkretnymi przykładami, a także koncepcjami i metodami „wysokiego poziomu”, które możesz dostosować do swojego zespołu lub kontekstu.

Nasz proces projektowania około 2015 roku

Naszym głównym narzędziem w 2015 r. był Sketch i na tym właśnie kończyły się podobieństwa. Wszyscy mieliśmy różne metody prototypowania, eksportowania i udostępniania projektów zainteresowanym stronom (InVision, Axure, Marvel, Google Slides, a nawet przestarzały Adobe PDF) i programistom (Avocode, Zeplin, wtyczki bez samodzielnych aplikacji, takich jak Measure). W rzadkich przypadkach mogliśmy wysyłać pliki bezpośrednio do inżynierów, którzy mieli szczęście mieć rzadką kombinację licencji MacBooka i Sketch.

Kiedy InVision wypuścił wtyczkę Craft, byliśmy zachwyceni — mogliśmy prototypować i przesyłać ekrany ze Sketch do InVision, udostępniając komponenty i style w powstających bibliotekach w plikach — było to spełnienie marzeń projektanta.

Ostatecznie wszyscy połączyliśmy się na platformie InVision. Stworzyliśmy i udokumentowaliśmy procesy, które pomogły w znacznym stopniu zmniejszyć tarcia we współpracy interesariuszy i przekazywania deweloperów. Jednak ze względu na złożoną strukturę uprawnień InVision pozostał zamkniętym ekosystemem — jeśli nie byłeś projektantem, istniał łańcuch zatwierdzania, który utrudniał uzyskanie konta InVision, a gdy już je uzyskałeś, musiałeś zostać dodany do właściwych grup.

Ręczne zarządzanie wersjami i plikami, przechowywanie i organizowanie ich na dysku współdzielonym oraz radzenie sobie z konfliktami synchronizacji to tylko niektóre z rzeczy, które przysporzyły nam wielu bólów głowy.

Czy naprawdę moglibyśmy mieć uniwersalne narzędzie, które miało wszystkie najlepsze funkcje Sketch i InVision, z funkcjami współpracy i komunikacji w czasie rzeczywistym, które można znaleźć w Dokumentach Google? Oprócz zmniejszenia narzutu związanego z przełączaniem kontekstu, moglibyśmy również potencjalnie uprościć subskrypcje trzech narzędzi (makiety, prototypowanie i przekazywanie przez programistów) do tylko jednego.

Proces

Pierwsi projektanci z naszego zespołu, którzy zaadoptowali Figma, zaczęli z nim eksperymentować, gdy pierwsza wersja beta Figmy została wydana w 2016 roku. Funkcje były ograniczone, ale pokrywały 80% tego, czego potrzebowaliśmy. Import szkiców był błędny, ale nadal znaleźliśmy ogromną wartość w możliwości współpracy w czasie rzeczywistym, a co najważniejsze, mogliśmy wykonać 90% prac projektowych dla projektu w jednym narzędziu. Opinie interesariuszy, poprawki i przekazywanie deweloperów uległy znacznej poprawie.

Do 2017 roku mieliśmy kilku projektantów, którzy używali go do większości swojej pracy, a jeden z projektantów Lexicon (system projektowania Liferay), Emiliano Cicero, szybko stał się ewangelistą — co okazało się kluczowym czynnikiem w przekonaniu reszty zespół, który dokona zmiany.

Kiedy Figma 2.0 zadebiutowała latem 2017 roku z dodanymi funkcjami prototypowania i ogromnymi ulepszeniami funkcji przekazywania przez programistów, wiedzieliśmy, że może to być opłacalne narzędzie dla naszego globalnego zespołu. Ale jak przekonać ponad 20 projektantów do porzucenia narzędzi i przepływów pracy, które kochają i których wygodnie używali od lat?

Mógłbym napisać serię na ten temat, ale podsumuję, mówiąc, że dwie najważniejsze rzeczy to: zaczynać od małych i tworzyć solidną infrastrukturę .

Zaczynając od małych

Jesienią 2017 roku rozpoczęliśmy naszą pierwszą wersję próbną Figmy z zespołem ds. produktów rozmieszczonym między Stanami Zjednoczonymi a Brazylią. Mieliśmy szczęście, że odbyliśmy tygodniowy kick-off razem w naszym biurze w Los Angeles. Wspólne projektowanie przepływów i makiety w Figma było o wiele szybsze i wydajniejsze. Udało nam się podzielić zadania i udostępnić pliki oraz komponenty bez martwienia się o ciągłą synchronizację folderu lub biblioteki.

Na naszym globalnym spotkaniu w styczniu 2018 r. opracowaliśmy plan powolnego wdrażania Figma, wykorzystując doświadczenia tego zespołu, aby pomóc w stworzeniu infrastruktury, której potrzebowalibyśmy dla reszty organizacji, tak aby migracja przebiegała tak płynnie, jak to tylko możliwe.

Największym wyzwaniem, przed jakim staliśmy, był napięty termin — przerabianie naszego procesu przeglądu i przekazywania nie miało dla nas żadnego sensu ze względu na skalę projektu z wieloma zespołami inżynierskimi i menedżerami produktu rozsianymi po całym świecie. Mimo że efekt końcowy byłby lepszy, czas nie był odpowiedni. Innym czynnikiem był brak wiarygodnego doświadczenia projektowego w trybie offline przez Figmę (więcej o tym później) , iz tych powodów zespół zdecydował się użyć Sketch i Figma do makiety i makiet, ale wszelkie prototypowanie lub przegląd musiały zostać wykonane w InVision.

Tworzenie solidnej struktury Figma

Jednym z pierwszych kroków było sformułowanie ogólnych wytycznych dotyczących organizacji projektu, pliku i komponentów. Podstawę dla tych rzeczy założyli dwaj młodsi (w tamtym czasie) projektanci, Abel Hancock i Naoki Hisamoto, którzy nigdy nie wykształcili złych nawyków nazewnictwa warstw, które wydają się pochodzić od projektantów, którzy wyrzynali zęby w Photoshopie. Ta metoda organizacji, w połączeniu z rokiem spędzonym na opracowywaniu małej biblioteki komponentów dla usług Liferay.com, miała kluczowe znaczenie dla nastawienia reszty globalnego zespołu na sukces.

Wczesnym usprawnieniem organizacyjnym stworzonym przez jednego z naszych projektantów Liferay.com, zainspirowanym tweetem Bena, był nasz system okładek .

Udostępniliśmy ten plik, jeśli chcesz go skopiować, w przeciwnym razie jest to dość prosty hack:

1. Utwórz pojedynczą ramkę na pierwszej stronie pliku o wymiarach 620×320.
2. Dodaj swój projekt. Jeśli masz tekst, stwierdziliśmy, że minimalny rozmiar to ~24, tytuły w naszych przykładach są ustawione na 48.
3. Cieszyć się!

Uwaga: Wokół okładki zawsze będzie niewielki margines, ale jeśli ustawisz kolor płótna strony w tym samym kolorze, co karta, zmniejszy to wygląd tego marginesu.

Pomogło to przekształcić naszą bibliotekę, nie tylko dla projektantów, ale także dla kierowników projektów i produktów oraz inżynierów, którzy próbują szybko znaleźć rzeczy. Funkcjonalność wyszukiwania była już naprawdę dobra, ale okładki pomogły ludziom zawęzić rzeczy jeszcze szybciej, a także pozwoliły nam natychmiast komunikować status dowolnego danego pliku.

Przed użyciem Figma, oprócz głównego pliku szkicu systemu projektowania, większość projektantów posiadała pliki bazowe, które opracowali z biegiem czasu, z takimi rzeczami, jak elementy szkieletowe i podstawowe komponenty. Kiedy połączyliśmy się w jeden wzór, zaczęliśmy wszystko łączyć i udoskonalać w jedną bibliotekę. Ponieważ robiliśmy szkielety, makiety i prototypy w Figmie, zaczęliśmy również porzucać aplikacje przepływu, takie jak Lucidchart, zamiast tworzyć własne komponenty przepływu zadań w Figmie.

Inne narzędzia, które opracowaliśmy z biegiem czasu, to komponenty do tworzenia precyzyjnych specyfikacji przekazywania, karteczki do diagramów powinowactwa (i prawie wszystkiego) oraz węzły przepływu.

Jedną z największych korzyści płynących z wykonania tego w Figma było to, że ulepszenia dowolnego z tych komponentów, które każdy projektant stworzył, można łatwo przeciągnąć do biblioteki, a następnie rozesłać do wszystkich instancji. Posiadanie tego w scentralizowanym miejscu znacznie ułatwia konserwację, ponieważ każdy członek zespołu może przyczynić się do ulepszeń za pomocą stosunkowo prostego procesu.

Dokument z zaznaczoną linią ułatwia deweloperowi poznanie wymiarów, specyfikacji wizualnych i innych właściwości składnika interfejsu użytkownika lub zestawu składników. Jeśli interesuje Cię temat, możesz również zapoznać się z artykułem Dmitriy Fabrikant o planach projektowych.

Kilka zaleceń, o których należy pamiętać podczas tworzenia komponentów:

1. Korzystanie z przesterowań i wzorców dla potężnych komponentów podstawowych (więcej na ten temat tutaj);
2. Ustal spójny wzorzec nazewnictwa (używamy modelu atomowego);
3. Dokumentuj i oznaczaj wszystko — zwłaszcza warstwy.

Wraz z zaawansowanymi funkcjami stylizacji wydanymi na początku czerwca 2017 r., zespół systemowy ukończył kompletną wersję naszej biblioteki Lexicon pomiędzy naszymi dużymi wydaniami produktów w lipcu a rozwojem w sierpniu. To był ostatni element, którego potrzebowaliśmy, aby wesprzeć globalny zespół. Projektanci pracujący w działach marketingu i innych działach już od jakiegoś czasu korzystali z Figmy, ale jesienią ubiegłego roku prawie wszystkie inne zespoły produktowe sfinalizowały przejście na Figma.

Na dzień dzisiejszy większość projektantów produktów używa tylko Figmy, jest też kilku projektantów, którzy pracują w starszych systemach z wieloma istniejącymi, skomplikowanymi prototypami Sketch, których nie warto importować do Figma. Innym wyjątkiem jest kilku projektantów, którzy od czasu do czasu używają aplikacji takich jak Principle lub Adobe After Effects do bardziej zaawansowanych animacji, które nie miałyby sensu w Figmie. Mamy nawet kilku projektantów, którzy badają Framer X w celu uzyskania jeszcze solidniejszych prototypów, zwłaszcza w przypadku pracy, która wymaga wykorzystania wszelkiego rodzaju danych na dużą skalę. Podczas gdy niektórzy projektanci używają wielu narzędzi w sposób półregularny, 80% naszych projektantów produktów używa Figma do wszystkich prac projektowych i prototypowych.

Ciągłe ulepszenia

Nieustannie pracujemy nad sposobami, aby pracować wydajniej, a jedną z bieżących rzeczy, nad którymi pracujemy, są sprawdzone metody nadawania nazw stronom. Na początku nazywaliśmy strony zgodnie z nazwą strony, ale okazało się to problematyczne, a ponadto, gdy ulepszyliśmy nasze biblioteki, zmniejszono zapotrzebowanie na większe pliki z wieloma stronami.

Obecnie używamy systemu numerowania w plikach, przy czym najwyższa strona to ta, która jest dostarczana programistom. Następną fazą, którą obecnie omawiamy, jest sprawienie, aby wersje były bardziej znaczące dzięki wyraźnym etykietom (makiety, makiety, punkty przerwania itp.) oraz lepsze wykorzystanie wbudowanego wersjonowania Figma, ustalenie najlepszych praktyk dotyczących tego, kiedy i jak zapisywać wersje.

Final_Final_Last_2 — nigdy więcej!

Generalnie nienawidzę używać terminu „zmieniacz gier”, ale kiedy Figma opublikowała nazewnictwo/adnotacje do historii wersji w marcu zeszłego roku, radykalnie zmieniło to sposób, w jaki zorganizowaliśmy nasze pliki. Wcześniej wszyscy mieliśmy różne sposoby zapisywania iteracji i wersji.

Zwykle tworzyliśmy nowe strony w jednym pliku, czasami przy dużych plikach powielaliśmy je i dodawaliśmy literę na końcu nazwy pliku, aby zasygnalizować iterację. Jeśli zamierzasz wprowadzić drastyczne zmiany, możesz utworzyć nowy plik i dołączyć numer wersji. Było to bardzo naturalne, wywodzące się z paradygmatu Photoshop/Sketch zarządzania wieloma plikami dla wszystkiego.

Możliwość pracy, okresowego zatrzymywania się w celu nazwania i dodania adnotacji do punktu w czasie, będzie bardzo znana każdemu, kto wcześniej korzystał z kontroli wersji, takiej jak Git. Możesz nawet przejrzeć całą historię plików i przejść do poprzednich migawek, wybrać jedną, nazwać ją i dodać adnotacje.

Jeśli chcesz wrócić i przywrócić poprzednią wersję, możesz ją przywrócić i pracować nad tym plikiem od tego momentu w historii. Najlepsze jest to, że nie straciłeś żadnej pracy, ponieważ wersja, którą „przywróciłeś”, nie usuwała niczego; po prostu kopiował ten stan i wklejał go na górze.

Na tej ilustracji projektant osiąga wersję final 3.0 po przywróceniu final 1.1 , ale historia wersji pliku jest nadal w pełni widoczna i dostępna.

W przypadkach, gdy zaczynasz nowy projekt lub chcesz dokonać naprawdę dramatycznych zmian w pliku, konieczne może być „rozwidlenie” pliku. Figma pozwala na zduplikowanie pliku w dowolnym momencie historii, ale ważne jest, aby pamiętać, że historia pliku nie zostanie skopiowana.

Odkryliśmy, że dobrym sposobem pracy w tym systemie wersjonowanym jest użycie historii plików w sposób podobny do tego, w jaki programista używa git — pomyśl o wersji Figma jako o zatwierdzeniu lub żądaniu ściągnięcia, a następnie nazwij je i dodaj adnotacje jako taki. Aby uzyskać więcej, mądrzejszych przemyśleń na ten temat, polecam książkę Seth Robertson's Commit Frequency, Perfect Later, Publish Once: Git Best Practices — to dobra ogólna filozofia pracy w ekosystemie kontrolowanym przez wersję. Ponadto Chris Beams's How to Write a Git Commit Message to świetny przewodnik po pisaniu znaczących i użytecznych notatek podczas pracy.

Kilka praktycznych wskazówek, które odkryliśmy:

1. Tytuły powinny mieć maksymalnie 25 znaków .
   Dłuższe tytuły są obcinane i musisz dwukrotnie kliknąć notatkę w historii wersji, aby otworzyć modalne „Edytuj informacje o wersji”, aby ją przeczytać.
2. Zachowaj opis do 140 znaków lub mniej .
   Zawsze wyświetlany jest pełny opis, więc trzymanie go na miejscu pomaga zachować czytelność historii.
3. Użyj trybu rozkazującego w tytule .
   Daje to w przyszłości jaśniejsze wyobrażenie o tym, co się stanie po kliknięciu tego punktu w czasie, np. „zmiana kolorów przycisków na niebieski” lub „zmiana przycisków na niebieski”.
4. Użyj opisu, aby wyjaśnić „co” i „dlaczego” oraz „jak” .
   Odpowiadanie na pytanie „dlaczego” jest kluczową częścią każdej pracy projektanta, więc pomaga to skupić się na tym, co jest ważne podczas pracy, a także zapewnia lepsze informacje w przyszłości.

Praca w trybie offline

Zastrzeżenie: Jest to oparte na naszym własnym doświadczeniu i większość z nich to nasze najlepsze przypuszczenia, jak to działa.

Jak wspomniałem wcześniej, obsługa offline w Figmie jest słaba. Jeśli masz już otwarty plik przed przejściem do trybu offline, możesz kontynuować pracę nad plikiem. Wygląda na to, że każda wprowadzana zmiana jest oznaczona sygnaturą czasową. W przypadku, gdy ktoś inny pracuje nad tym samym plikiem w trybie offline, najnowsza zmiana zostanie wyrenderowana po powrocie do trybu online.

W tym prostym przykładzie nie wydaje się to zbyt wielkim problemem — ale w prawdziwym życiu może to być naprawdę bałaganiarskie, bardzo szybko. Oprócz dużej prawdopodobieństwa, że ​​ktoś nadpisze twoją pracę, ramki i grupy mogą zostać ułożone jedna na drugiej.

Nasz przepływ pracy polega na zduplikowaniu strony przed (lub po) przejściu do trybu offline, a następnie wykonaniu pracy w tej kopii. W ten sposób pozostanie nietknięty, gdy wrócisz do trybu online, i będziesz mógł ręcznie wykonać wszystkie niezbędne połączenia.

„F” to przyszłość

Przyjęcie nowego narzędzia nigdy nie jest łatwe, ale ostatecznie korzyści mogą znacznie przewyższyć koszty.

Największe obszary doskonalenia, jakich doświadczył nasz zespół to:

• Współpraca
  O wiele łatwiej jest dzielić się naszą pracą i ulepszeniami z zespołem i społecznością.
• Przezroczystość
  System, który jest domyślnie otwarty, jest naturalnie bardziej inkluzywny dla osób spoza dziedziny projektowania.
• Ewolucja
  Usunięcie „warstw” między projektantami i inżynierami, co umożliwi nam wykonanie kolejnego kroku w dojrzałości projektowej.
• Operacje
  Przyjęcie jednego narzędzia do tworzenia makiet, makiet, prototypów i materiałów do przekazania programistom ułatwia życie księgowości, informatyce i zarządzaniu.

Zmniejszenie ogólnej liczby subskrypcji było bardzo pomocne dla naszego zespołu, ale ponieważ koszty mogą wahać się od „bezpłatnych” do ponad 500 USD rocznie, może to nie mieć sensu w konkretnym kontekście i potrzebach. Pełne zestawienie znajduje się na stronie cennika Figma.

Rozwijaj się i stawaj się lepszy

Oczywiście żadne narzędzie nie jest doskonałe i zawsze jest miejsce na ulepszenia. Niektóre rzeczy, których brakowało w poprzednich narzędziach, z których korzystaliśmy, to:

1. Brak ekosystemu wtyczek .
   Rozszerzalność Sketcha była ogromnym czynnikiem, który sprawił, że przejście z Photoshopa było oczywiste. Figma ma interfejs API sieciowy, ale obecnie nie ma funkcji „zapisu”. Na razie Sketch pozostaje liderem rynku dzięki żywej społeczności rozszerzeń i wtyczek. (Oczywiście wszystko może się zmienić w przyszłości, jeśli Figma otworzy również scenę do tworzenia wtyczek.)
2. Importowanie danych internetowych lub JSON w prototypach .
   Dużo łatwiej byłoby nam projektować na rzeczywistych danych. Sketch niedawno wprowadził funkcję „Dane” w wersji 52. Wtyczka InVision Craft jest nadal złotym standardem, jeśli chodzi o łatwe dodawanie dużych ilości różnych danych — a na razie utknęliśmy ręcznie wypełniając pola tekstowe.
3. Więcej ruchu .
   Integracja z Principle jest fajna (jeśli masz Principle), ale posiadanie podstawowej animacji i zaawansowanych funkcji prototypowania w Figma byłoby o wiele lepsze.
4. Płynniejsze działanie offline
   Jak wspomniano wcześniej, o ile masz otwarty plik Figma przed przejściem do trybu offline, wszystko jest w porządku. Jest to prawdopodobnie w porządku dla większości ludzi — ale jeśli lubisz wyłączać komputer każdej nocy, może to być bolesne, gdy otworzysz go rano w pociągu lub samolocie i zdasz sobie sprawę, że zapomniałeś zostawić Figma otwartą.

Projektowanie open source

Kilka miesięcy temu zawsze kontrowersyjny Dann Petty napisał na Twitterze, że programiści mają GitHub, fotografowie mają Unsplash — ale projektanci nie mają platformy do dzielenia się rzeczami za darmo. Design Twitter️ wpadł i usunął swój tweet, zanim zdążyłem zrobić zrzut ekranu, ale chciałbym wspomnieć, że to, co nas bardzo pasjonuje w Liferay, to open source. W tym celu stworzyliśmy projekt Figma, aby udostępnić zasoby społeczności projektantów.

Aby uzyskać dostęp do któregokolwiek z tych plików, odwiedź liferay.design/resources/figma i bądź na bieżąco, gdy będziemy się rozwijać i udostępniać więcej!

Dalsza lektura

• „Nasze pierwsze 6 miesięcy z Figmą”, Danny Saltaren
• „Czekam na znak, aby rozpocząć tworzenie biblioteki komponentów zespołu projektowego?”, William Newton
• „Jak usprawnić przepływ pracy UI/UX za pomocą Figma”, Nicole Saidy
• „Pierwsze kroki z zespołami w organizacji Figma” Thomas Lowry
• „5 sposobów na uporządkowanie przepływu pracy za pomocą stron w Figma”, Josh Dunsterville
• „Najlepsze praktyki: komponenty, style i biblioteki współdzielone”, Thomas Lowry
• „Figma: płynne i modułowe podejście projektowe do typografii z komponentami”, Mirko Santangelo

Inne zasoby

• Społeczność Figma na Spectrum
• Podręcznik projektowania Figma autorstwa Davida Ukauwa