--- title: Kasutajaliidese parendamine description: Auditeerib olemasolevat tootevaadet selle enda disainipõhimõtete alusel ja kirjutab parendusplaanid. category: Design sublabel: Kasutajaliides author: Julien Thibeaut (ibelick) tags: license: MIT source: https://github.com/ibelick/ui-skills --- # Kasutajaliidese parendamine Auditeeri üht terviklikku tootepinda selle süsteemi suhtes, mis seda tegelikult juhib. Säilita toote identiteet, kasuta olemasolevaid omanikke uuesti ja eelista pigem leiu puudumist kui põhjendamata leidu. Kirjuta plaanid ainult nende muudatuste kohta, mille kasutaja valib; neid teostab teine agent. ## Piirid - Ära kunagi muuda toote lähtekoodi. Loo või muuda faile ainult kaustas `design-plans/`. - Ära paigalda sõltuvusi, ära käivita vormindajaid, ära tee commit'i ega push'i ega muuda tööpuud muul viisil. - Ära uuenda disainidokumentatsiooni. Pane aktsepteeritud dokumentatsioonimuudatused kirja plaani, et teostaja need teeks. - Kasuta renderdatud tõendeid ainult siis, kui kasutaja need annab või palub selgesõnaliselt visuaalset kontrolli. - Tee iga plaan iseseisvaks; selle teostajal pole auditi ega vestluse konteksti. ## 1. Vali pind Austa kasutaja määratud ulatust. Kui päring on lai, vali üks juurutatav rakendus ja üks terviklik pinnaperekond, mis esindab toote põhiülesannet. Ütle valik välja; ära sünteesi kogu repositooriumi üheks tooteks. Alusta pinna marsruutidest ja paigutustest. Jälgi renderdatud rada läbi kompositsioonide, jagatud komponentide, variantide, lahendatud tokenite ja stiilide. Ära alusta kogu repositooriumi hõlmavast ebakõlade otsingust. Seos on olemas ainult siis, kui see on tõestatud renderdamise, importide, prop'ide, lahendatud konfiguratsiooni, CSS-i pärimise või pinna poolt laaditud genereeritud artefakti kaudu. Ühised nimed, sarnased tokenid, lähedus repositooriumis ja kontseptuaalsed seosed ei tõenda seost. Jäta välja muud rakendused, eelvaated, konfiguraatorid, genereeritud registrid, pärandsüsteemid ja ettevõtte variandid, kui need ei osale jälgitud rajal. ## 2. Taasta kohalik süsteem Kontrolli, kas on olemas `DESIGN.md`, repositooriumi juhised ja pinnaspetsiifiline disainidokumentatsioon. Kasuta allikat ainult pärast seda, kui oled tõestanud, et see on ajakohane ja juhib valitud pinda; mustandid, ettepanekud, migratsioonid ja ülesandeloendid kirjeldavad tulevast kavatsust, kui neid pole selgesõnaliselt aktsepteeritud ja need pole ajakohased. Disainidokumentatsiooni puudumine ei ole leid. Uuri ainult neid tokeneid, muutujaid, teemasid, primitiive, variante ja kompositsioone, mis on jälgitud raja jaoks olulised. Lahenda aliased ja variandid nende definitsioonideni. Liigita teostus kohalikuks või pärandiks ainult siis, kui repositoorium nii ütleb. Pane kirja: ```markdown ## Design language - Audited surface: - Design sources: - Documented decisions: - Governing owners and consumers: - Explicit exceptions: ``` Kirjuta `Explicit exceptions` alla `None documented`, välja arvatud juhul, kui viidatud allikas tuvastab erandi selgesõnaliselt. ## 3. Tõesta leiud Enne tõendusvärava rakendamist uuri iga jälgitud pinna kasutajale nähtavaid silte, aktiivse oleku esitust, responsiivseid harusid ja sõsarvariante sisemiste vastuolude suhtes. Käsitle tulemusi ainult kandidaatidena. Leid kuulub ulatusse ainult siis, kui selle parandus muudab eelkõige visuaalset esitust, liidese teksti, paigutust, komponendi stiili või vastavust dokumenteeritud disainireeglile. Kui parandus muudab eelkõige seda, kas toote käitumine töötab, lükka see tagasi. Otsingutulemused, kordumine ja teostuserinevused annavad kandidaate, mitte leide. Hoia kandidaat alles ainult siis, kui kõik kolm tõendit on olemas: 1. **Leping** — Viita selle omaduse ja ulatuse kohta siduvale disainiotsusele või otsesele vastuolule kasutajale nähtavas esituses või sisus sama ülesande piires. „Eelista“, „üldiselt“, nimed, väljajätmised, kordumine ja erandi puudumine ei loo lepingut. 2. **Käitusaeg** — Tõesta, et viidatud omanik, väärtus või käitumine jõuab mõjutatud pinnale jälgitud käitusaja raja kaudu. Ära võrdle eraldi omanikukihte ega elutsükli olekuid. 3. **Parandus** — Nimeta üks muudatus, mida tõendid nõuavad. Kui see sõltub olemasolevast tokenist, variandist, primitiivist või eeskujust, nimeta see täpselt. Kui tõendite põhjal ei saa õiget valikut määrata, kavandatud tingimus on mitmetähenduslik, ettepanek sisaldab alternatiive või parandus nõuab tootekavatsuse väljamõtlemist, lükka kandidaat tagasi. Lähtekood võib tõestada tokeni, tüpograafia, värvi, vahede, paigutuse, teksti, komponendivariandi, responsiivse esituse ja selgesõnalise disainilepingu rikkumisi. See ei saa muuta funktsionaalset käitumist, olekuhaldust ega interaktsiooni korrektsust disainileidudeks. Hierarhia, esiletõstetus, tihedus, selgus, leitavus, kasutatavus ja tajutav sidusus nõuavad renderdatud või kasutajatõendeid. Jäta kõrvale ligipääsetavuse ja HTML/ARIA semantika leiud, kui kasutaja neid selgesõnaliselt ei palu. Jäta kõrvale katkised marsruudid, ümbersuunamised, andmete ühendamine, toimingute tõrked, metaandmed, paketi API, jõudlus, arhitektuur ja koodikvaliteedi leiud, kui kasutaja neid ei palunud või neid ei juhi tootespetsiifiline disainileping. Määra usaldusväärsus alles pärast seda, kui kõik tõendid on läbitud. Kasuta olemasolevat omanikku uuesti, kui tõendid seda toetavad; ära loo jagatud primitiivi pelgalt kordumise põhjal. ## 4. Kontrolli leide Enne aruandmist ava uuesti iga viidatud allikas ja proovi iga kandidaati ümber lükata. Kustuta see, kui: - Probleem ei vasta täpselt viidatud teostusele. - Reegel ei juhi seda omadust ja pinda. - Vastutõendid näitavad, et erinevus on kehtiv või tahtlik. - Tõendid toetavad mitut parandust. - Parandus mõtleb välja tootekavatsuse. - Mõni teine leid kirjeldab sama algprobleemi. Tabelisse võivad pääseda ainult need leiud, mis selle kontrolli üle elavad. ## 5. Aruanne Järjesta allesjäänud leiud usaldusväärsuse, kasutajamõju, ulatuse ja parandamise kulu järgi. Peatu kolme juures. Kasuta seda struktuuri: ```markdown ## Design language - Audited surface: - Design sources: - Documented decisions: - Governing owners and consumers: - Explicit exceptions: ## Findings | # | Problem | Evidence | Proposed change | Scope | Confidence | | --- | --- | --- | --- | --- | --- | ## Improve first ``` Tõendid peavad kinnitama lepingu, käitusaja seose ja deterministliku liidesetagajärje. Kavandatud muudatus peab sisaldama üht parandust. Kustuta enne tagastamist põhjendamata või kattuvad read. Kustuta iga leid, millel pole kõiki nõutud veerge, sealhulgas Confidence. Vali `Improve first` alla üks allesjäänud leid, millel on tugevaimad tõendid ja suurim võimendus. Ära kunagi kombineeri leide. Kui ükski kandidaat ei jää alles, kirjuta `## Findings` alla `No supported findings were found.` ja `## Improve first` alla `No supported recommendation.`. Kui leide jääb alles, peatu ja küsi, millistest teha plaanid. Kui kasutaja on juba leiu valinud või selgesõnaliselt palunud kirjeldatud parenduse jaoks plaani, jätka selle ulatusega. Kui sul palutakse midagi otse parandada või parendada, paku plaani; ära seda kunagi ise teosta. ## 6. Kirjelda valitud muudatused Loe [references/plan-template.md](references/plan-template.md). Kirjuta üks plaan iga valitud muudatuse kohta, mitte kunagi üks plaan iga sümptomi kohta. Enne kirjutamist ava uuesti iga viidatud allikas, pane võimalusel kirja praegune commit, tuvasta täpsed korduvkasutatavad primitiivid ja eeskujud ning jälgi mõjutatud pindu. Ühtlusta olemasolev plaan, selle asemel et seda dubleerida. Ära mõtle väärtusi välja, kui repositoorium pakub tokenit või komponendilepingut. Võta uus primitiiv kasutusele alles pärast seda, kui oled tõestanud, miks olemasolev süsteem ei suuda otsust väljendada ja millised tarbijad peaksid seda jagama. Kui sul palutakse ühtlustada, kontrolli olemasolevaid plaane uuesti praeguse lähtekoodi ja dokumenteeritud otsuste suhtes; uuenda aegunud tõendid, mõjutatud pinnad ja olek.