Zyski:
- Możliwość tworzenia i tworzenia spójnych tokenów projektowych, nazewnictwa komponentów i zasad użytkowania za pomocą sztucznej inteligencji
- Możliwość szybkiego tworzenia dokumentacji komponentów, przykładów typu „rób/nie” i tekstów użytkowych za pomocą sztucznej inteligencji
- Możliwość sprawdzenia sugestii sztucznej inteligencji pod kątem konfliktu z istniejącym systemem projektowym i zachowania osobliwości
System projektowania to wspólny język, który sprawia, że rodzina produktów wygląda i zachowuje się spójnie: komponenty wielokrotnego użytku (przycisk, karta, pole formularza), tokeny projektowe (nazwane definicje wartości, takich jak kolor, odstępy, typografia) oraz dokumentacja wyjaśniająca, jak z nich korzystać. Dobry system projektowania pozwala dziesięciu projektantom zaprojektować ten sam produkt tak, jakby był wytwarzany przez jedno źródło. Instalacja i konserwacja tego systemu jest męczącą, powtarzalną i wymagającą dużej ilości tekstu pracą; To właśnie tutaj błyszczy sztuczna inteligencja. Ale istotą systemu jest wyjątkowość i spójność; Zaleceń AI nie można zaakceptować bez sprawdzenia, czy są one sprzeczne z bieżącym systemem.
Tokeny i nazewnictwo: podstawa spójności
Token projektowy to nazwana wartość decyzji projektowej, którą można ponownie wykorzystać: kolor-podstawowy, przestrzeń-środek, tekst-tytuł-duża litera. Dzięki tokenom możesz zmienić kolor w jednym miejscu i zaktualizować go w całym produkcie. Ale siła tokenów zależy od spójności nazewnictwa; Jeśli zostaną użyte mieszane kolory niebieski-1, główny-niebieski i podstawowy, system ulegnie awarii.
Sztuczna inteligencja jest tutaj dobra w dwóch rzeczach: sprawdzaniu istniejącego zestawu tokenów pod kątem spójnego schematu nazewnictwa i sugerowaniu nazw nowych tokenów zgodnych ze schematem. Żądanie takie jak „Przetłumacz tę listę tokenów na nazewnictwo semantyczne (oparte na znaczeniu)” pomoże Ci wygenerować nazwy, które przekazują znaczenie, takie jak kolor-akcja-podstawowy zamiast niebieski-500. Jednak ostateczną decyzją dotyczącą nazewnictwa jest kontrakt zespołu; Model przedstawia jedynie zarys.
Wskazówka: Nadając tokeny AI, podaj 5-6 przykładów swojego obecnego schematu i powiedz „zachowaj ten sam wzór”. Żądanie bez próbki generuje nazwy obce dla twojego systemu.
Dokumentacja komponentów: najbardziej produktywny obszar AI
Dokumentacja komponentu obejmuje: co robi, kiedy go używać, kiedy nie, jego warianty, stany (domyślny, po najechaniu, pasywny, błąd), uwagi dotyczące dostępności i przykłady „rób/nie rób”. Ręczne pisanie tych tekstów zajmuje wiele godzin, dlatego wiele zespołów zaniedbuje dokumentację.
Sztuczna inteligencja wypełnia tę lukę: kiedy opisujesz komponent, tworzy ona wersję roboczą dokumentacji, zasady użytkowania oraz przykłady „rób/nie” w spójnym formacie. W ten sposób dokumentacja zmienia się z „nie ma” na „jest projekt, zostanie poprawiony”, co jest dużym zyskiem. Jednakże model nie zna rzeczywistego zachowania komponentu; Twoim zadaniem jest dopasowanie reguł, które generuje, do rzeczywistości systemu.
fragment dokumentu
Wkład sztucznej inteligencji
weryfikacja przez człowieka
Co to robi?
Jasna definicja konturu
Prawdziwa przydatność do określonego celu
Kiedy używać
Ogólne scenariusze
Zasady specyficzne dla produktu
Przykłady „rób/nie rób”.
Szybkie pary draftu
Faktyczne nadużycia
Uwaga dotycząca dostępności
Standardowe przypomnienia
Potwierdzone prawdziwym testem
Lista wariantów/przypadków
możliwa lista
Ci, którzy faktycznie istnieją w systemie
Sprawdzanie sprzeczności: zachowanie osobliwości
Największym wrogiem systemu projektowania jest powielanie: dwa przyciski wykonujące tę samą pracę, dwie różne skale przestrzenne, dwie sprzeczne zasady. Kiedy sztuczna inteligencja sugeruje nowy komponent lub regułę, sugestia ta może kolidować z istniejącym systemem — nie uwzględnia całego systemu modelowego. Dlatego oceniam każdą sugestię, zadając pytanie „czy jest to sprzeczne z czymś, co już istnieje?” Filtruj z pytaniem. Możesz także użyć sztucznej inteligencji do skanowania konfliktów: możesz podać podsumowanie bieżącego systemu i nowe rekomendacje oraz wyświetlić listę konfliktów. Ale ostateczna „wyjątkowo słuszna” decyzja należy do zespołu.
trzy mini etui
Przypadek 1 – Dług dokumentacyjny uregulowany. Tylko 6 z 24 komponentów zespołu miało dokumentację. Dla pozostałych 18 komponentów wykorzystujących sztuczną inteligencję przygotowano projekty dokumentów; Zespół naprawiał każdą usterkę w ciągu 10–15 minut. Odroczone o kilka tygodni zadanie zostało ukończone w ciągu dwóch dni.
Przypadek 2 — Nazewnictwo tokenów stało się spójne. W jednym systemie kolory były mieszane jak niebieski1, głównyniebieski, brand-niebieski. AI przetłumaczyła istniejące 40 tokenów na schemat semantyczny; Zespół poprawił go i przeszedł na jeden standard. W kolejnych projektach błędy kolorystyczne zostały zauważalnie zmniejszone.
Przypadek 3 – Odrzucono komponent powodujący konflikt. AI zaproponowała nowy komponent o nazwie „drugorzędny przycisk akcji”. Kiedy zespół skanował w poszukiwaniu sprzeczności, stwierdził, że spełnia on tę samą funkcję, co istniejący „przycisk widmo” i odrzucił tę sugestię. Lekcja: nie każda sugestia dodaje nowy komponent do systemu; Czasami warto skorzystać z tego, co jest dostępne.
Monity, które można kopiować
Twoja rola: administrator systemu projektowania. Udokumentuj ten komponent: <<komponent i jego zachowanie>>.Format: Do czego służy | Kiedy używać | Kiedy NIE używać |Wariantów | Sytuacje | Uwagi dotyczące dostępności | 2 Zrób / 2 Nie dawaj przykładu. Wymyśl zachowanie, którego nie znasz; Napisz „zespół musi wypełnić”.
Przetłumacz tę listę tokenów na semantyczny (oparty na znaczeniu) schemat nazewnictwa. Moje obecne przykłady schematów: <<5-6 przykładów>>. Kontynuuj według tego samego wzoru. Dla każdego tokena podaj starą nazwę -> nową nazwę -> tabelę uzasadniającą. Lista: <<tokeny>>
Skanuj w poszukiwaniu sprzeczności: Podsumowanie mojego obecnego systemu projektowego: <<podsumowanie>>. Nowy proponowany komponent/reguła: <<sugestia>>. Czy ta sugestia jest sprzeczna z istniejącym systemem (komponent wykonujący to samo zadanie, sprzeczna reguła, zduplikowany token)? Wypisz konflikty i swoje sugestie.
Wygeneruj przykładowe pary „rób/nie” dla tego komponentu: realistyczne poprawne użycie i realistyczne nieprawidłowe scenariusze użycia. Dla każdej pary wyjaśnij w jednym zdaniu, dlaczego jest to prawda/fałsz. Komponent: <<nazwa i cel>>
Słaba zachęta/silna zachęta
Słabe: „Napisz dokumentację dla tego przycisku”.
Wynik: ogólny, sformatowany tekst bez połączenia z systemem.
Mocne: „Udokumentuj ten przycisk w następującym formacie (co robi / kiedy nie używać / warianty / przypadki / dostępność / nie robić); wymyśl zachowanie, którego nie znasz, napisz „zespół musi wypełnić”.
Wynik: Konsekwentnie sformatowany, odpowiednio rozmieszczony, edytowalny rękopis.
Różnica: mocny format podpowiedzi + zakaz produkcji + podpowiedzi typu „rób/nie”.
Typowe błędy
- Żądanie nazewnictwa tokenów bez przykładu. Model generuje nazwy obce Twojemu systemowi; konsystencja jest zepsuta.
- Dodawanie komponentów bez szukania sprzeczności. Powielanie jest największym wrogiem systemu.
- Zakładając, że zachowanie wymyślone przez model jest prawidłowe. AI nie zna rzeczywistego zachowania komponentu.
- Akceptacja oceny dostępności bez testowania. Standardowe przypomnienie nie zastępuje faktycznego testowania.
- Jednorazowe napisanie dokumentacji i jej nieaktualizowanie. Dokument należy aktualizować w miarę zmian w systemie.
Podsumowując
System projektowy to infrastruktura spójności i skalowalności; ale jego utrzymanie jest często zaniedbywane, ponieważ wymaga dużej ilości tekstu i jest powtarzalne. Sztuczna inteligencja rozwiązuje ten problem, szybko tworząc dokumentację komponentów, przykłady nakazów/nie, skrypty użycia i wersje robocze nazewnictwa tokenów. Ale istotą systemu jest wyjątkowość i spójność: każda nazwa tokenu musi zostać zweryfikowana z przykładowym schematem, każda propozycja komponentu musi zostać zeskanowana pod kątem sprzeczności, każdy opis zachowania musi zostać zweryfikowany z rzeczywistością. Użyj modelu jako skutecznego kreślarza; Zespół podejmuje indywidualną, właściwą decyzję.
Zadanie aplikacji
- Wybierz komponent z brakującą dokumentacją i utwórz wersję roboczą dokumentu, korzystając z pierwszego monitu.
- Wypełnij pola oznaczone „Zespół musi wypełnić” rzeczywistym zachowaniem.
- Po wyświetleniu drugiego monitu przekonwertuj 8–10 tokenów na schemat semantyczny i utwórz starą/nową tabelę nazw.
- Aby znaleźć pomysł na nowy komponent, poszukaj sprzeczności za pomocą trzeciego monitu.
- Po wyświetleniu czwartego monitu wygeneruj przykładowe pary typu „rób/nie” dla komponentu i dodaj je do systemu.
lista kontrolna
- [ ] Powiązałem nazewnictwo tokenów z przykładowym schematem.
- [ ] Przeskanowałem nowe komponenty pod kątem konfliktów.
- [ ] Zweryfikowałem wzorcowe zachowania z rzeczywistością.
- [ ] Planowałem potwierdzić uwagi dotyczące dostępności rzeczywistymi testami.
- [ ] Prowadziłem dokumentację w spójnym formacie.
- [ ] Zachowałem wyjątkowość i zapobiegłem powielaniu.