Gdyby szukać materiałów o design systemach, większość skupia się na Figmie: jak budować komponenty, jak stosować zmienne, jak porządkować bibliotekę. I bardzo dobrze – to ważne. Ale… to dopiero początek. Rzeczywistość design systemów jest znacznie szersza niż plik Figmowy. I właśnie o tej szerszej perspektywie dziś kilka słów – szczególnie o dokumentacji.
Figma to nie wszystko – dokumentacja!
Design system to nie tylko biblioteka komponentów. To także kod, framework, logika działania i… dokumentacja. Ta ostatnia może przyjmować różne formy – techniczną, UX-ową, produktową albo łączoną. Dobra dokumentacja wspiera osoby projektujące, wdrażające, zarządzające produktami i testujące. Zwiększa szansę na zachowanie spójności, porządku i jasnych zasad stosowania komponentów.
Po co nam dokumentacja?
Dla porządku. Dla efektywności. Pracując w większych zespołach łatwo zauważyć, że brak dokumentacji szybko prowadzi do niespójności. Ten sam komponent może wyglądać i działać inaczej w różnych miejscach produktu, bo różne osoby podjęły różne decyzje – w dobrej wierze, ale bez wspólnego „źródła prawdy”.
Dokumentacja może między innymi:
- wskazywać, które warianty komponentów są domyślne,
- pokazywać przykłady użycia (w kontekście całego produktu),
- dawać kontekst (kiedy używamy przycisków, a kiedy linków),
- zawierać dobre praktyki, ale też przykłady błędów,
- opisywać zasady dostępności,
- dostarczać wytycznych do treści – UX writing (np. co i jak pisać na przyciskach).
Dla mnie dużą wartością jest dokumentacja bardzo rozbudowanych produktów lub serii produktów, które tworzy wiele zespołów. Wtedy, mając dokumentację, jeśli chcę sprawdzić, które komponenty i jak używane powinny być dla nowej funkcji w jednych z produktów, mogę sięgnąć do dokumentacji właśnie.
To też świetny materiał do onboardingu nowych osób w zespole!
Od czego zacząć?
Najlepiej… od jednego komponentu. Nie rzucajcie się na całą bibliotekę na raz. Zacznijcie od przycisków, selektorów albo nawigacji. Przetestujcie format, zobaczcie ile to zajmuje czasu, pokażcie innym i iterujcie.
Dobrze też zadać sobie (i zespołowi) kilka ważnych pytań:
- Jakie są obecnie największe bolączki przy korzystaniu z design systemu?
- Co musi się znaleźć w dokumentacji?
- Jakie informacje możemy uzupełniać stopniowo?
- Jakie błędy się powtarzają?
- Kto będzie odpowiadał za dokumentację i jej aktualizację?
Takie stopniowe podejście oparte na bliskiej współpracy, sprawi, że łatwiej będzie nam ocenić, estymować budowanie dokumentacji. To wbrew pozorom dość czasochłonne zadanie.
Inspirujcie się innymi
To, co najlepsze, to fakt, że nie musicie wymyślać wszystkiego od nowa! Świetne wzorce znajdziecie w dokumentacjach takich systemów jak:
- Material 3 od Google,
- Atlassian,
- Base od Ubera,
- Gestalt (Pinterest)
- Carbon Design od IBM,
- frameworki jak Material Angular, Prime UI czy Kendo UI.
Patrzcie, jak opisują komponenty, jak pokazują przykłady, jak łączą treści techniczne z wizualnymi. Ja zwracam szczególną uwagę na strukturę (jak podzielone są opisy) oraz nazwy komponentów i ich grupowanie.
Oczywiście, nie wszystko co robione przez duże firmy, jest doskonałe i warto podążać za nimi na ślepo. Ciekawym przykładem jest choćby dokumentacja design systemu Gestalt – od Pinteresta. Autor, odpowiedzialny min. za nazwy tokenów kolorów, przyznał po czasie, że bycie „zbyt kreatywnym” było dużym błędem.
Gdzie trzymać dokumentację?
Możliwości jest wiele: ZeroHeight, Gitbook, Notion, Confluence czy własny CMS. Niektóre zespoły trzymają część opisów nawet w samej Figma – i to działa, o ile dokumentacja techniczna żyje gdzie indziej. Ważniejsze od narzędzia jest to, by dokumentacja była łatwo dostępna, aktualna i rzeczywiście używana.
Tu najlepiej skupić się najpierw na narzędziach, do których już w firmie mamy dostępy i które są znane przez innych. Unikniemy dzięki temu ryzyka, że trzeba będzie czekać miesiącami na płatne licencje lub dojdzie dodatkowy element edukacji, dla osób w naszej firmie.
Użyteczna, niekoniecznie idealna
Pamiętajcie – dokumentacja nie może być tylko dla samej dokumentacji. Musi być użyteczna. Nie każda osoba z zespołu ma czas (ani chęci), żeby czytać długie eseje o zasadach używania przycisków. Krótkie instrukcje, praktyczne przykłady, checklisty – to się sprawdza. A na długie teksty zawsze przyjdzie czas później (albo i nie, bo zawsze jest coś ważniejszego do roboty).
I na koniec… Dokumentacja to nie projekt na miesiąc. To proces. To współpraca. I to bardzo realne wsparcie dla całego zespołu produktowego. Niech nie będzie wypracowaniem, którego nikt nie czyta, tylko narzędziem, z którego wszyscy chętnie korzystają. Zacznijcie małymi krokami, zbierajcie feedback i rozwijajcie ją razem z design systemem.
