Ehitaja jutustus

Origin

Ma tõmbasin varakult esiplaanile, sest see on pind, kus kavatsus kohtub reaalsusega: pikslid, latentsus, kopeerimine ja vool otsustavad, kas keegi jätkab või vaikselt lahkub. See on alandav koht töötamiseks - te ei saa peita abstraktsioonide taha, kui kasutaja vaatab tulemust. Aastate jooksul muutus instinkt korratavaks objektiiviks: millist tööd see ekraan teeb, millist piirangut ei saa läbi rääkida ja mis on väikseim muutus, mida saame saata, mis mõõdetavalt parandab usaldust, selgust või kiirust? Kirjutan endiselt kasutajaliidest, kuid kasutajaliidese taga on küsimus, milline on meeskondade ja toodete skaala.

Evolutsioon

Luma Healthis veetsin sisukat aega kommunikatsioonikeskuses - raske, suure liiklusega töövoog, kus jõudlus ja selgus ei ole poleeritud; nad on osa hoolduse koordineerimisest. Toode oli üles võtnud UX hõõrdumise ja pärandkoodi teede kihid, mis panid iga muutuse tundma riskantsena, mis on see, kuidas meeskonnad aeglustavad märkamata. Ma aitasin seda pinda refaktoreerida, nii et kogemus tundus reaalsetele kasutajatele kergem, ja me kasutasime tagasisidekanaleid (sh kasutajaaruandeid), et kinnitada, et me fikseerisime seda, mida inimesed tegelikult tundsid - mitte ainult seda, mida oli armatuurlaual lihtne mõõta. Paralleelselt käsitlesin turvalisust kasutajakogemuse osana: kasutaja loodud rikas tekst on XSS-i klassikaline jalapüstol, kui te ainult puhastate "kuskil". Ma aitasin kõrvaldada kriitilist kokkupuudet, puhastades sisu enne API töötlemist ja uuesti piiride muutmist ning andsin panuse jagatud komponentide API-desse ja disainisüsteemi otsustesse, nii et teised meeskonnad ei pidanud samu teravaid servi uuesti avastama.

Toote mõtlemine praktikas

Mõned minu kõrgeima võimendusega tööd asuvad seal, kus UX, taustaprogrammi käitumine ja operatsioonid kohtuvad - kus haprast integratsioonist saavad piletid, churn või hilisõhtune leht. Üks näide: SFTP ringhäälingutoru, kus "see töötab minu masinal", ei olnud tundlike andmevoogude klientidele piisav. Ma kujundasin selle ümber nii, et meeskonnad konfigureerisid kasutajaliideses välise→sisemise välikaardistuse valideerimisega, selle asemel et arvata ja üleujutusi toetada. Valekonfiguratsiooni piletid langesid järsult ja me kaitsesime suhet, mis ei saanud endale lubada lohakaid üleandmisi. Sisnetis töötasin kureeritud turul, kus sisu kiirus oli sama oluline kui koodi kvaliteet. Ma ehitasin Node.js-ile AdminJS-i CMS-i, et turundus ja opid saaksid iga tweaki jaoks ilma insenerideta saata koopiat, kujundeid ja stiili - iganädalased tulekahjuõppused langesid "peaaegu kunagi" ja meeskond võiks keskenduda tellimustele, Stripe'ile ja Klaviyole ning toote sügavusele tavapärase avaldamisega.

Membrus – hoone tõeliste kogudustega

Väljaspool oma täiskohaga rolle asutasin Membrus: platvorm kirikutele, et juhtida liikmelisust, suhtlemist ja operatsioone ühes sidusas süsteemis, mitte arvutustabelite, grupivestluste ja ad hoc tööriistade kogumit. Töö ei olnud "lisage veel üks CRUD-rakendus". See oli arusaam sellest, kuidas pastorid ja töötajad tegelikult nädala jooksul liiguvad - kes vajab juurdepääsu millele, mis katkeb, kui andmed on vastuolulised ja kuidas saata administraatori töövooge, mida mittetehnilised inimesed saavad omada. Ma omasin toodet ja kohaletoimetamist üle pindade: avalik kohalolek, liikmega seotud kogemused ja sisemised tööriistad, iterating koos kiriku juhtidega, kes olid ausa tagasisidega helded. See on selline toode, mida ma tahan jätkuvalt ehitada: põhineb tegelikel piirangutel, tarnitakse tegelikele kasutajatele, parandatakse avalikult - mitte slaidid.

Jätkusuutlik tempo surve all

Shiftingis töötasin väikeses meeskonnas, kes toimetas piletimüügiturgu tegeliku ulatuse surve all - kiirus oli oluline, kuid nii ei põletanud inimesi. Ma käitusin sageli inimesena, kes pidi valima: mida me kärbime, mida me karmistame ja mille osas me keeldume kompromissidest? Minu eelarvamus oli laevandus hästi, mitte laevandus kaootiliselt: igapäevane blokeerimine, järjepidev koodi läbivaatamine, nii et tagasiside oli prognoositav, ja väikesed DX parandused, mis tegid järgmise nädala lihtsamaks kui viimane. Ehitasin ka sisemise CMS-stiilis tööriista, nii et mittetehnilised meeskonnakaaslased saaksid sisu itereerida, ilma et insenerid muutuksid pudelikaelaks. Tulemuseks ei olnud lihtsalt "me käivitasime" - see oli funktsionaalne turg, mis tarniti jätkusuutlikus tempos, kus klient tundis tõeliselt hästi. See on sama oluline kui iga tehniline detail.

See veebileht – loodud tootena

See veebisait on tahtlikult rohkem kui staatiline jätkamine. See on i18n-esimene, jagab UI-d üle monorepo ja paigutus seab prioriteediks loetava hierarhia ja nii pikkade lehekülgede vahe, nagu see, on meeldiv lugeda. Lucas AI on osa samast väitekirjast: assistent, kes vastab esimeses isikus, kuid ainult siin avaldatud struktureeritud kontekstist - projektid, kogemused ja kuidas ma mõtlen kompromissidele - nii et uurimine tundub üldise asemel maandatud. Kui loete nii kaugele, näete miniatuurset käsitöö argumenti: narratiivi, süsteeme ja tootepinda, mis kutsub sügavust.

Kuidas ehitada

  • Alustage kasutaja tööst, et teha, seejärel kujundage väikseim silmus, mis vähendab riski ja tõestab väärtust varakult.
  • Kohtle turvalisust, ligipääsetavust ja jõudlust kui UX-i - inimesed tunnevad neid isegi siis, kui nad ei saa põhiprobleemile viidata.
  • Eelistage selgeid lepinguid ja korduvkasutatavaid primitiive ühekordsele kohandamisele; disainisüsteem peaks tarnet mitmekordistama, mitte seda kaunistama.
  • Valige teadlikult surve all ulatus: kaitsta kvaliteeti, ohverdamata meeskonna tempot ja tervist.
  • Käsitle pileteid, tuge ja kvalitatiivset tagasisidet kui tootesignaale ja sulge silmus, et sama probleemiklass ei naaseks vaikselt.