De ce constrângerile fac tehnologia mai umană
Formularul care a salvat după-amiaza
Un student mi-a arătat odată un formular de înregistrare pe care toată lumea din organizație îl ura. Avea câmpuri stricte, date obligatorii, opțiuni controlate și un refuz atunci când documentul sursă lipsea. Oamenii îl numeau birocratic, firește. Birocratic este cuvântul pe care îl folosim atunci când un sistem refuză să coopereze cu dorința noastră de a improviza. Apoi echipa l-a comparat cu vechiul formular de înregistrare cu text liber. Formularul urât era inestetic. Vechea înregistrare era o mlaștină.
În procesul vechi, oamenii scriau note în propriul stil. Datele migrau între formate. Consimțământul era subînțeles prin optimism. Câmpurile critice erau ascunse în paragrafe. Departamentul următor trebuia să citească, să interpreteze, să alerge după informații și să ghicească. Când ceva mergea prost, organizația nu putea spune dacă eșecul fusese cauzat de date lipsă, de interpretare greșită sau de faptul că toți acceptaseră tacit să trateze speranța ca pe un câmp de bază de date.
Formularul cu constrângeri nu a făcut munca mai poetică. A făcut-o mai blândă. Îi spunea utilizatorului ce era necesar. Refuza să continue atunci când procesul devenea nesigur. Făcea responsabilitățile vizibile. Reducea cantitatea de interpretare cerută persoanei următoare. Nu înlocuia judecata. Nu se mai prefăcea că judecata ar trebui să curețe orice mizerie din amonte.
Aceasta este valoarea umană trecută cu vederea a constrângerilor. Ele nu sunt doar limite. Sunt declarații. Un sistem constrâns spune ce poate accepta, ce nu poate accepta, unde se mută responsabilitatea și unde trebuie implicat un om. Automatizarea vagă pare adesea prietenoasă pentru că acceptă orice. Apoi costul apare mai târziu, de obicei în mâinile cuiva cu mai puțină putere.
Sistemele fără constrângeri împing munca în aval
Multe sisteme digitale sunt lăudate pentru că sunt flexibile. Flexibil înseamnă adesea că sistemul lasă datele proaste să călătorească până când un om trebuie să le repare. Un chatbot acceptă o cerere imposibilă și produce ceață plină de încredere. Un flux de lucru acceptă un document fără consimțământ și lasă conformitatea să descopere problema mai târziu. O conductă de date acceptă câmpuri necunoscute și lasă analiza să se întrebe de ce un grafic arată ca și cum ar fi fost asamblat în timpul unei pene de curent.
Această muncă din aval nu este neutră. Cade pe umerii personalului de suport, al gestionarilor de cazuri, al administratorilor de date, al asistentelor, al profesorilor, al funcționarilor publici, al clienților și al oricui altcuiva care stă aproape de punctul în care automatizarea întâlnește realitatea. Utilizatorul poate percepe primul ecran ca fiind fluid. Instituția percepe restul ca muncă refăcută. Fluiditatea la intrare poate fi cruzime la ieșire.
Constrângerile inversează acest tipar. Ele fac sistemul responsabil chiar la punctul de intrare. Ele spun că sursa trebuie numită, consimțământul trebuie să fie explicit, data trebuie să fie validă, acțiunea trebuie să fie permisă, nivelul de încredere trebuie să fie suficient, politica trebuie să fie actuală, iar refuzul trebuie înregistrat. Acest lucru este mai puțin spectaculos decât o interfață conversațională. La fel este și o centură de siguranță. Se pare că le-am acceptat pe amândouă.
Specialiștii în tehnică își fac uneori griji că constrângerile fac sistemele fragile. Constrângerile proaste fac asta. Constrângerile bune numesc condițiile în care sistemul are voie să acționeze. Există o diferență între a refuza pentru că lumea este incomodă și a refuza pentru că sistemului îi lipsește autoritatea. Primul caz este leneș. Al doilea este onest.
Refuzul este o caracteristică, nu o defecțiune
Tehnologia umană trebuie să știe să spună nu. Fraza aceasta sună dur doar pentru că software-ul a petrecut ani de zile prefăcându-se că fiecare cerere merită un răspuns. Într-un sistem serios, nu poate însemna că datele lipsesc, că utilizatorul nu este autorizat, că modelul nu este suficient de sigur, că scopul este în afara domeniului de aplicare, că politica a expirat sau că acțiunea ar prejudicia un drept. Un nu cu motive este mult mai respectuos decât un da care creează o problemă trei pași mai târziu.
Refuzul protejează, de asemenea, sistemul de a deveni un teatru al competenței false. Interfețele generative sunt deosebit de vulnerabile aici. Ele pot produce o frază pentru aproape orice. O frază nu este autoritate. Un răspuns fluent la o întrebare din afara domeniului nu este un serviciu; este un risc decorativ. Constrângerea umană este cea care spune că această întrebare necesită un profesionist, că aceste date nu pot fi folosite în acest scop sau că acest răspuns nu poate fi produs din dovezile disponibile.
Oamenii rareori obiectează la refuz atunci când acesta este clar, consecvent și însoțit de o cale de urmat. Ei obiectează la refuzul misterios. Ei obiectează la refuzul care se ascunde în spatele sistemul spune nu. Ei obiectează la refuzul care nu poate fi contestat. Ei obiectează la refuzul aplicat inegal, pentru că regulile trăiesc în mintea celui care a configurat fluxul de lucru după o întâlnire lungă. De aceea, constrângerea trebuie să vină cu explicație, înregistrare și responsabilitate.
Constrângerile fac responsabilitatea vizibilă
Responsabilitatea în tehnologie dispare adesea în abstracțiuni. Modelul a decis. Platforma a recomandat. Fluxul de lucru a direcționat. Panoul de control a afișat. Aceste fraze sunt confortabile pentru că scot oamenii din verb. Constrângerile îi pun pe oameni înapoi. Cineva a ales pragul. Cineva a aprobat politica. Cineva a definit scopul permis. Cineva a decis ce dovezi sunt suficiente. Cineva deține excepțiile.
Faptul că această vizibilitate contează pentru utilizatori se datorează faptului că daunele apar, de obicei, la granițe. O persoană este lipsită de un beneficiu, un pacient nu este direcționat mai departe, un angajat este marcat, un client este blocat în afara sistemului, un cetățean este rugat să prezinte mai multe documente. Sistemul poate conține multe componente ingenioase, dar utilizatorul simte granița. Dacă nimeni nu deține acea graniță, utilizatorul nu are cui să adreseze o întrebare. Acest lucru nu este eficient. Este un labirint cu ecran de autentificare.
Un sistem constrâns poate afișa deținătorul regulii, versiunea politicii, dovezile utilizate, dovezile lipsă și calea de corectare. Acest lucru nu face fiecare decizie plăcută. O face guvernabilă. Alternativa este un sistem care pare adaptiv până când ceva nu merge bine, moment în care toată lumea descoperă că adaptivitatea este un substitut slab pentru responsabilitate.
Organizațiile se tem uneori că asumarea explicită a responsabilității va genera răspundere. Realitatea este, de obicei, mai aproape de contrariu. Responsabilitatea ascunsă nu elimină răspunderea. O amână, adaugă confuzie și face explicația finală să pară improvizată. O constrângere declarată este, cel puțin, inspectabilă. O presupunere ascunsă este un raport de incident care așteaptă o vineri liniștită.
Experiența utilizatorului în cazul limitelor
Aici există o lecție de design. Constrângerile trebuie să fie vizibile înainte de a produce daune. Dacă un utilizator descoperă o limită doar după ce finalizează un proces lung, constrângerea pare punitivă. Dacă sistemul explică cerința de la început, utilizatorul poate acționa. O interfață umană nu doar blochează acțiunile nevalide. Îl ajută pe utilizator să înțeleagă ce ar presupune o acțiune validă.
De aceea, sistemele constrânse au nevoie de un limbaj adecvat. Un mesaj care spune „intrare nevalidă” nu este o îndrumare. Un mesaj care spune că data documentului trebuie să fie în ultimele trei luni, deoarece decizia depinde de venitul curent, este mai bun. Un mesaj care spune că această cerere nu poate fi procesată automat, deoarece lipsește consimțământul, și care arată cum să adaugi consimțământul sau să soliciți o analiză manuală, este și mai bun. Constrângerea devine parte a serviciului.
Echipele de design încearcă uneori să ascundă constrângerile de teama fricțiunii. Dar fricțiunea nu este întotdeauna inamicul. Există fricțiune dăunătoare, precum solicitarea acelorași date de trei ori, deoarece sistemele nu comunică între ele. Există fricțiune protectoare, precum solicitarea confirmării înainte de ștergerea înregistrărilor sau trimiterea unei decizii sensibile. Tehnologia umană face distincție între cele două. Elimină risipa și păstrează prudența.
Constrângerea trebuie să se potrivească activității
O constrângere nu este umană doar pentru că este strictă. O constrângere proastă poate fi la fel de leneșă ca lipsa totală a constrângerilor. Poate cere un document pe care unii utilizatori nu îl pot obține în mod rezonabil. Poate codifica o politică învechită. Poate face cazul ușor să pară frumos și cazul dificil să pară umilitor. Poate forța o asistentă medicală, un profesor sau un funcționar să mintă sistemul pentru că realitatea nu a ajuns în forma aprobată. În acel moment, constrângerea nu a îmbunătățit fluxul de lucru. A creat o mică taxă pe onestitate.
Constrângerile bune sunt proiectate pornind de la muncă. Ele întreabă ce fapte sunt necesare înainte de acțiune, ce incertitudine poate călători în siguranță, ce incertitudine trebuie oprită și ce rol uman are autoritatea de a decide o excepție. Sunt stricte acolo unde consecința este gravă și mai permisive acolo unde costul unei greșeli este scăzut. Lasă loc pentru explicații atunci când oamenii se confruntă cu circumstanțe neobișnuite. Nu confundă introducerea ordonată a datelor cu introducerea corectă a acestora.
De aceea contează cercetarea de teren. Oamenii cei mai apropiați de fluxul de lucru știu de obicei care reguli protejează și care reguli doar pedepsesc. Ei știu ce câmpuri sunt cu adevărat necesare și care au fost adăugate după o ședință pentru că cineva voia să pară minuțios. Ei știu unde se blochează utilizatorii, unde personalul inventează canale paralele și unde sistemul transformă o excepție normală într-un obstacol procedural. O constrângere proiectată fără acești oameni va părea de obicei ordonată de sus și se va comporta prost la ghișeu.
Versiunea tehnică este aceeași. Un sistem de tipuri, o schemă, un motor de politici sau un strat de validare ar trebui să exprime contractul real. Nu ar trebui să devină un altar al completitudinii teoretice. Cea mai bună constrângere este adesea mică, denumită clar și testată. Ea spune exact ce trebuie să fie adevărat înainte ca sistemul să acționeze și lasă restul contextului disponibil pentru analiză. Așa devine o limită grijă, nu birocrație.
Constrângeri înainte de automatizare
Cel mai prost moment pentru a inventa constrângeri este după ce automatizarea acționează deja. Până atunci, sistemul și-a format obiceiuri. Datele au ajuns în locuri unde nu ar fi trebuit. Oamenii au construit soluții de ocolire. Rapoartele depind de câmpuri pe care nimeni nu le deține. Modelul a învățat din istorii care nu au fost niciodată menite să devină material de instruire sau de regăsire. Apoi vine guvernanța cu clipboard-ul și toată lumea se preface surprinsă, ca și cum cauza și efectul ar fi un subiect de cercetare de nișă.
Constrângerile ar trebui proiectate înainte de automatizare pentru că ele definesc spațiul de operare sigur. Ce scopuri sunt permise. Ce date pot fi folosite. Ce surse necesită consimțământ. Ce rezultate cer analiză umană. Ce decizii trebuie înregistrate. Ce utilizatori pot anula. Ce înregistrări trebuie să expire. Acestea nu sunt decorațiuni în jurul modelului. Ele sunt forma sistemului.
Când constrângerile vin primele, automatizarea poate fi mai utilă pentru că are o sarcină mai mică și mai clară. Nu trebuie să deducă granițele instituționale din vibrații. Poate opera într-un spațiu declarat, poate refuza în afara lui și poate lăsa dovezi în urmă. Asta este o ușurare, sincer. Mașinile sunt excelente la viteză. Nu devin mai bune dacă le cerem să ghicească guvernanța pentru că adulții nu voiau o ședință dificilă.
Există și un beneficiu de învățare. Constrângerile produc feedback mai bun. Dacă multe cazuri eșuează pentru că lipsesc dovezi, îmbunătățește colectarea inițială. Dacă multe refuzuri sunt răsturnate la apel, analizează regula. Dacă mulți utilizatori se opresc la aceeași cerință, reproiectează explicația. Un sistem fără constrângeri poate părea eficient pentru că nu se oprește niciodată. Doar amână măsurarea eșecului.
Instituțiile au nevoie și ele de limite
Constrângerile nu protejează doar utilizatorii de tehnologie. Ele îi protejează pe utilizatori de instituțiile care folosesc tehnologia ca scuză. Fără constrângeri, automatizarea poate deveni o modalitate de a lua decizii fără a numi cine a decis. Cu constrângeri, instituția trebuie să își scrie limitele. Trebuie să spună ce nu are voie sistemul să facă. Aceasta este o stare de disconfort sănătoasă.
O școală care folosește analize de date ar trebui să declare ce semnale pot influența sprijinul acordat și care nu. O primărie care folosește automatizarea ar trebui să declare când un caz trece la un om. O bancă care folosește modele de risc ar trebui să declare ce dovezi contează și cum poate un client să conteste un rezultat. Un spital care folosește sisteme de sprijin pentru decizii ar trebui să declare când recomandările sunt doar orientative și când responsabilitatea clinică rămâne la un profesionist. Aceste declarații nu sunt împotriva inovației. Sunt fundația pe care se construiește aceasta.
Cuvântul „uman" poate deveni sentimental dacă nu este legat de mecanisme. În tehnologie, „uman" înseamnă adesea că lucrurile plictisitoare au fost făcute: limite de scop, reguli privind sursele, programe de păstrare a datelor, permisiuni pe roluri, jurnale de audit, căi de refuz, rute de contestație, politici cu versiuni și transferuri testate. Nu foarte cinematografic. Bine. Oamenii rareori au nevoie de cinematografie de la sistemele administrative. Au nevoie ca acestea să nu piardă firul.
Politica excepțiilor
Orice sistem cu constrângeri întâlnește, la un moment dat, un caz care nu se potrivește. Întrebarea nu este dacă există excepții. Ele există întotdeauna, chiar și ascunse în conturile de administrator, în modificări directe ale bazei de date, în apeluri informale sau în persoana care știe ce buton ocolește regula. Întrebarea umană este dacă excepția este numită, limitată, înregistrată și supusă revizuirii. Flexibilitatea secretă nu este compasiune. Este privilegiu cu tastatură.
O cale de excepție ar trebui să spună cine o poate folosi, din ce motive, pe baza căror dovezi, cu ce a doua pereche de ochi și cât timp rămâne valabilă excepția. Ar trebui să creeze o evidență care poate fi auditată, fără să transforme angajații în suspecți pentru că fac o muncă dificilă. Ar trebui, de asemenea, să alimenteze îmbunătățirea. Dacă aceeași excepție apare în mod repetat, constrângerea poate fi greșită, politica poate fi incompletă sau lumea s-ar fi putut schimba în timp ce sistemul se străduia să arate îngrijit.
Aici supravegherea umană devine reală. Supravegherea nu este un nume de comitet. Este o relație proiectată între regulă, excepție, responsabilitate și dovezi. Un om care aprobă automat rezultatele mașinii nu este supraveghere. Un om care poate vedea regula, înțelege condiția lipsă, înregistrează motivul și declanșează o revizuire a politicii este mult mai aproape. Mai puțin dramatic, mai util. Cea mai mare parte a bunei guvernanțe are prezența scenică a unei liste de verificare bine întreținute.
Scopul nu este să faci tehnologia timidă. Scopul este să o faci decentă sub presiune. Un sistem care poate spune da, poate spune nu, poate cere dovezi, poate escalada, poate explica, poate înregistra și poate învăța nu este mai puțin avansat decât unul care răspunde la orice. Este mai matur. Are limite, iar limitele sunt modul în care sistemele împart lumea cu oameni care nu își pot permite să devină personal de curățenie pentru optimismul software-ului.
Aceeași logică se aplică și în interiorul echipelor. Constrângerile le oferă colegilor un obiect comun pe care să îl conteste. În loc să dezbată dacă cineva a fost suficient de atent, echipa poate inspecta regula, dovezile, excepția și responsabilul. Astfel, dezacordul trece de la personalitate la proiectarea sistemului, ceea ce este mai blând și mult mai ușor de îmbunătățit. Este, de asemenea, mai greu de ascuns în spatele lui. Un proces vag le permite tuturor să aibă dreptate în privat. O constrângere declarată cere organizației să greșească în public, apoi să repare problema.
Lecția
Tehnologia devine mai puțin umană atunci când acceptă fiecare cerere, ascunde fiecare incertitudine și lasă oamenii să descopere limitele abia după ce răul a călătorit deja. Devine mai umană atunci când își declară granițele devreme. Pot face asta. Nu pot face asta. Am nevoie de această dovadă. Trebuie să refuz aici. Această persoană este responsabilă. Așa faci apel.
Constrângerile nu sunt opusul inovației. Ele sunt modul în care inovația serioasă intră în instituții fără să transforme utilizatorii în material de testare. Ele protejează oamenii de automatizarea vagă, făcând limitele explicite, refuzurile specifice și responsabilitatea vizibilă. Un sistem care știe unde se oprește este mai ușor de încredere decât unul care spune politicos da până când realitatea trimite factura.