Oszukali nas!

Kilka słów o tym, czego nauczyłem się wprowadzając design system od zera. Bez słodzenia i bez idealnych obrazków. Tylko o problemach i o sposobach w jaki je rozwiązywałem.

Transcript

2. Oszukali nas! Jakub Hajduk Senior Frontned Developer Czyli czego nauczyłem się wprowadzając Design System od zera
3. Dlaczego o tym mówię?
4. Design System
5. Czym jest Design System?
6. “The complete set of design standards, documentation, and principles along with the toolkit (UI patterns and code components) to achieve those standards” Zack Rutherford - uxpin.com
7. “Simply put, a design system is a collection of reusable components to tie whole products together” Naema Baskanderi - freecodecamp.org
8. “Everything that makes up your product” — “From typography, layouts and grids, colors, icons, components and coding conventions, to voice and tone, style-guide and documentation, a design system is bringing all of these together in a way that allows your entire team to learn, build and grow” Ara Abcarians - css-tricks.com
9. Simply put, a design system is a complete collection of design standards, typography, layouts and grids, colors, icons, components, coding conventions, voice and tone, style-guide, documentation and principles along with the toolkit to achieve those standards and tie whole products together Zack Rutherford - uxpin.com Naema Baskanderi - freecodecamp.org Ara Abcarians - css-tricks.com
10. https://adele.uxpin.com
11. Jak to było u nas?
12. – O krok od enterprise – Spójność stylistyczna – Prędkość dostarczania wartości – Spontaniczna rozbudowa komponentów Problemy …czy raczej „wyzwania”
13. – Najlepiej od początku, ale nie ma kiedy! – Niewielki zespół – bezproblemowa i szybka komunikacja – Nagły rozwój projektu – więcej ludzi i gorsza komunikacja – Później byłoby znacznie ciężej O krok od enterprise
14. – Przemyślane procesy – Zarezerwowany czas – Zarezerwowane zasoby O krok od enterprise
15. – Pierwszy powód, dla którego wprowadza się DS – Rotacja – Zmiana układu, dodatkowe kolory, te same elementy - różne funkcje i te same funkcje - różne elementy – Łatwo skupić się na jednej funkcjonalności i pominąć pełny obraz Spójność stylistyczna
16. – Jednolita stylistyka – Jednolite zachowanie – Brak potrzeby skupiania się na pełnym obrazie Spójność stylistyczna
17. – Każdy ma swoją wizję, rozumienie, potrzeby i priorytety – Cały zespół mamy podzielony na podzespoły – Synchronizacja to ciągle za mało – Generowanie czasochłonnych, męczących i niepotrzebnych dyskusji Prędkość dostarczania wartości
18. – Dyskusje przeniesione do innej przestrzeni – Katalog gotowych elementów – UX nie wymyśla ciągle tego samego – Frontend wie co ma użyć Prędkość dostarczania wartości
19. – Brak zastanowienia nad ich rozszerzaniem – Rozszerzenie rozszerzenia rozszerzające rozszerzenie – Powstanie ciężkiego w utrzymaniu, niereużywalnego potwora Spontaniczna rozbudowa komponentów
20. – Osobne repozytorium – Komponenty lepszej jakości – Spontaniczna rozbudowa nie ma miejsca Spontaniczna rozbudowa komponentów
21. Jak nas oszukali?
22. DSM miał dać tokeny…
23. Style Dictionary!
24. DSM <3 Style Dictionary!
25. Nie powiedzieli nic o procesie…
26. Jira to the rescue!
27. A jak trzymać paczki?
28. GIT, .tar.gz i verdaccio
29. DevOps? Halo, jest tu jakiś?
30. CLI
31. Dokumentacja zmienną jest
32. Wersjonowanie
33. Najważniejsze są wnioski
34. Nasze 5 głównych zasad
35. 1. Project independent.
36. 2. Simplicity.
37. 3. Composition over configuration.
38. 4. Rule of three.
39. 5. No future predicting.
40. No i to by było na tyle!
41. Q&A
42. Thank you pgs-soft.com jhajduk@pgs-soft.com