Voitot:
- Kyky laatia ja tehdä johdonmukaisia suunnittelutunnuksia, komponenttien nimeämistä ja käyttösääntöjä tekoälyn avulla
- Kyky tuottaa nopeasti komponenttidokumentaatiota, tee/älä esimerkkejä ja käyttötekstejä tekoälyllä
- Kyky tarkistaa tekoälyehdotusten ristiriita olemassa olevan suunnittelujärjestelmän kanssa ja säilyttää singulaarisuus
Suunnittelujärjestelmä on yleinen kieli, joka saa tuoteperheen näyttämään ja käyttäytymään johdonmukaisesti: uudelleenkäytettävät komponentit (painike, kortti, lomakekenttä), suunnittelutunnukset (nimetyt arvojen määritelmät, kuten väri, väli, typografia) ja dokumentaatio, joka selittää niiden käytön. Hyvä suunnittelujärjestelmä antaa kymmenen suunnittelijaa suunnitella saman tuotteen ikään kuin se olisi valmistettu yhdestä lähteestä. Tämän järjestelmän asentaminen ja ylläpito on väsyttävää, toistuvaa ja tekstiintensiivistä työtä. Juuri täällä tekoäly loistaa. Mutta järjestelmän ydin on singulaarisuus ja johdonmukaisuus; Tekoälyn suosituksia ei voida hyväksyä ilman, että niiden ristiriidat nykyisen järjestelmän kanssa tarkistetaan.
Tokenit ja nimeäminen: johdonmukaisuuden perusta
Suunnittelutunnus on suunnittelupäätöksen nimetty, uudelleenkäytettävä arvo: väri-ensisijainen, tila-keskus, teksti-otsikko-iso. Tokenien ansiosta voit vaihtaa väriä yhdessä paikassa ja päivittää sen koko tuotteessa. Mutta merkkien teho riippuu nimeämisen johdonmukaisuudesta; Jos blue-1, main-blue, ensisijainenBlue käytetään sekaisin, järjestelmä kaatuu.
Tekoäly on hyvä kahdessa asiassa: olemassa olevan merkkijoukkosi tarkistaminen johdonmukaisen nimeämisjärjestelmän perusteella ja skeeman kanssa yhteensopivien nimien ehdottaminen uusille tunnuksille. Pyyntö, kuten "Käännä tämä merkkiluettelo semanttiseksi (merkitykseen perustuvaksi) nimeämiseksi", auttaa sinua luomaan nimiä, jotka välittävät merkityksen, kuten color-action-primary sijasta blue-500. Mutta lopullinen nimeämispäätös on joukkueen sopimus; Malli tarjoaa vain ääriviivat.
Vinkki: Kun nimeät tunnuksia tekoälylle, anna 5-6 esimerkkiä nykyisestä mallistasi ja sano "keep in the same pattern". Näytteetön pyyntö tuottaa nimiä, jotka ovat vieraita järjestelmällesi.
Komponenttien dokumentaatio: AI:n tuottavin alue
Komponentin dokumentaatio sisältää: mitä se tekee, milloin sitä käytetään, milloin sitä ei saa käyttää, sen muunnelmat, tilat (oletus, hiiri, passiivinen, virhe), esteettömyyshuomautuksia ja "tee/älä" -esimerkkejä. Näiden tekstien kirjoittaminen käsin vie tunteja, minkä vuoksi monet tiimit laiminlyövät dokumentoinnin.
Tekoäly täyttää tämän aukon: kun kuvailet komponenttia, se tuottaa luonnoksen dokumentaatiosta, käyttösäännöistä ja tee/älä tee -esimerkkejä johdonmukaisessa muodossa. Siten dokumentaatio siirtyy "ei ole" -tilaan "on luonnos, se korjataan", mikä on suuri voitto. Malli ei kuitenkaan tiedä komponentin todellista käyttäytymistä; Sinun tehtäväsi on sovittaa sen tuottamat säännöt järjestelmän todellisuuteen.
asiakirjan fragmentti
Tekoälyn panos
ihmisen vahvistusta
Mitä se tekee?
Selkeä ääriviivan määritelmä
Todellinen sopivuus tarkoitukseen
Milloin käyttää
Yleiset skenaariot
Tuotekohtaiset säännöt
Älä/älä esimerkkejä
Pikaluonnosparit
Todellisia väärinkäytöksiä
Esteettömyyshuomautus
Vakiomuistutukset
Varmistettu oikealla testillä
Vaihtoehto/tapausluettelo
mahdollinen lista
Ne, jotka todella ovat järjestelmässä
Ristiriitojen tarkistus: singulaarisuuden säilyttäminen
Suunnittelujärjestelmän perivihollinen on päällekkäisyys: kaksi painiketta tekevät samaa työtä, kaksi erilaista tilamittakaavaa, kaksi ristiriitaista sääntöä. Kun tekoäly ehdottaa uutta komponenttia tai sääntöä, ehdotus voi olla ristiriidassa olemassa olevan järjestelmän kanssa – se ei pidä koko mallijärjestelmääsi mielessä. Joten arvioin jokaisen ehdotuksen kysymällä "onko tämä ristiriidassa jo olemassa olevan kanssa?" Suodata kysymyksellä. Voit myös käyttää tekoälyä konfliktien skannauksessa: voit antaa nykyisen järjestelmän yhteenvedon ja uuden suosituksen sekä listata ristiriidat. Mutta lopullisen "yksittäisen oikean" päätöksen tekee joukkue.
kolme minilaukkua
Tapaus 1 – Asiakirjavelka selvitetty. Vain kuudella tiimin 24 osasta oli dokumentaatio. Lopuille 18 tekoälyn komponentille laadittiin asiakirjaluonnokset; Joukkue korjasi jokaisen 10-15 minuutissa. Viikkoa lykätty työ valmistui kahdessa päivässä.
Tapaus 2 – Tokenin nimeämisestä tuli johdonmukainen. Yhdessä järjestelmässä värit sekoitettiin kuten blue1, mainBlue, brand-blue. AI käänsi olemassa olevat 40 merkkiä semanttiseksi skeemaksi; Tiimi tarkisti sitä ja siirtyi yhteen standardiin. Värivirheet vähenivät huomattavasti myöhemmissä malleissa.
Tapaus 3 – Ristiriitainen osa hylättiin. Tekoäly ehdotti uutta komponenttia nimeltä "toissijainen toimintapainike". Kun tiimi etsi ristiriitoja, he havaitsivat, että se teki saman työn kuin olemassa oleva "haamupainike" ja hylkäsi ehdotuksen. Oppitunti: jokainen ehdotus ei lisää uutta komponenttia järjestelmään; Joskus on oikein käyttää sitä, mitä on saatavilla.
Kopioitavissa olevat kehotteet
Roolisi: suunnittelujärjestelmän ylläpitäjä. Dokumentoi tämä komponentti: <<komponentti ja sen toiminta>>. Muoto: Mitä se tekee | Milloin käyttää | Milloin EI saa käyttää |Variantteja | Tilanteet | Esteettömyyshuomautuksia | 2 Tee / 2 Älä anna esimerkkiä. Kehitä käyttäytymistä, jota et tiedä; Kirjoita "joukkueen on täytettävä".
Käännä tämä merkkiluettelo semanttiseksi (merkitykseen perustuvaksi) nimeämismalliksi. Nykyiset malliesimerkit: <<5-6 esimerkkiä>>. Jatka samaan malliin. Anna jokaiselle tunnukselle vanha nimi -> uusi nimi -> perustelutaulukko. Lista: <<tunnukset>>
Etsi ristiriitoja: Yhteenveto nykyisestä suunnittelujärjestelmästäni: <<yhteenveto>>. Uusi ehdotettu komponentti/sääntö: <<ehdotus>>. Onko tämä ehdotus ristiriidassa olemassa olevan järjestelmän kanssa (komponentti, joka tekee saman työn, ristiriitainen sääntö, kaksoistunnus)? Listaa ristiriidat ja ehdotuksesi.
Luo "tee/älä" -esimerkkipareja tälle komponentille: realistinen oikea käyttö ja realistiset virheelliset käyttöskenaariot. Selitä jokaiselle parille yhdellä lauseella, miksi se on tosi/epätosi. Komponentti: <<nimi ja tarkoitus>>
Heikko kehote / Vahva kehote
Heikko: "Kirjoita dokumentaatio tälle painikkeelle."
Tulos: Yleinen, muotoiltu teksti, jolla ei ole yhteyttä järjestelmään.
Vahva: "Dokomentoi tämä painike seuraavassa muodossa (mitä se tekee / milloin ei saa käyttää / muunnelmia / tapauksia / saavutettavuus / älä tee); keksi käyttäytymistä, jota et tiedä, kirjoita "tiimin on täytettävä".
Tulos: Johdonmukaisesti muotoiltu, oikein sijoitettu, muokattava käsikirjoitus.
Ero: vahva kehotemuoto + valmistuskielto + tee/älä -kehotteet.
Yleisiä virheitä
- Tokenin nimeämisen pyytäminen ilman esimerkkiä. Malli luo nimiä, jotka ovat vieraita järjestelmällesi; johdonmukaisuus on rikki.
- Komponenttien lisääminen ilman ristiriitojen etsimistä. Monistaminen on järjestelmän perimmäinen vihollinen.
- Olettaen, että mallin keksimä käyttäytyminen on oikea. AI ei tiedä komponentin todellista käyttäytymistä.
- Käytettävyysluokituksen hyväksyminen ilman testausta. Vakiomuistutus ei korvaa varsinaista testausta.
- Dokumentaation kirjoittaminen kerran, eikä sitä päivitetä. Asiakirja tulee päivittää järjestelmän muuttuessa.
Yhteenvetona
Suunnittelujärjestelmä on johdonmukaisuuden ja skaalautuvuuden infrastruktuuri; mutta sen ylläpito jätetään usein huomiotta, koska se on tekstiintensiivistä ja toistuvaa. Tekoäly korjaa tämän velan tuottamalla nopeasti komponenttidokumentaatiot, älä tee/älä -esimerkkejä, käyttöskriptejä ja tunnuksen nimeämisluonnoksia. Mutta järjestelmän ydin on singulaarisuus ja johdonmukaisuus: jokainen tunnuksen nimi on verrattava malliskeemaan, jokainen komponenttiehdotus on tarkistettava ristiriitaisesti, jokainen käyttäytymiskuvaus on tarkistettava todellisuutta vastaan. Käytä mallia tehokkaana piirtäjänä; Joukkue tekee yksilöllisen oikean päätöksen.
Sovellustehtävä
- Valitse komponentti, josta puuttuu dokumentaatio, ja luo asiakirjaluonnos ensimmäisellä kehotuksella.
- Täytä kenttiin "Tiimin on täytettävä" todellinen käyttäytyminen.
- Muunna 8-10 merkkiäsi toisella kehotteella semanttiseksi malliksi ja luo vanha/uusi nimitaulukko.
- Etsi uusi komponenttiidea etsimällä ristiriitoja kolmannen kehotteen avulla.
- Luo neljännen kehotteen avulla komponentille älä tee/älä -esimerkkiparit ja lisää ne järjestelmään.
tarkistuslista
- [ ] Linkitin tunnuksen nimeämisen esimerkkiskeemaan.
- [ ] Tarkastin uudet komponentit ristiriitojen varalta.
- [ ] Todistin mallin mukaiset käyttäytymiset todellisuudella.
- [ ] Ajattelin varmistaa esteettömyyshuomautukset varsinaisella testauksella.
- [ ] Säilytin asiakirjat yhtenäisessä muodossa.
- [ ] Säilytin singulaarisuuden ja estäin päällekkäisyyden.