Cercetare · Propunerea completă

Propunerea completă: Sistemul de Design al Guvernului României (SDGR)

Aceasta este propunerea mea completă pentru un sistem de design comun al serviciilor publice digitale, în versiunea 3.0 din 20 octombrie 2026. Nu este un document oficial al Guvernului sau al Autorității pentru Digitalizarea României (ADR). Găsești aici ce aș construi, cine ar decide, calendarul pe 36 de luni, bugetul estimat și criteriile după care programul ar continua sau s-ar opri. Costurile, calendarul și soluțiile juridice sunt ipoteze care trebuie validate.

0. Decizia propusă

Propun ca SDGR să fie aprobat ca program în etape, cu un orizont public de 36 de luni și cu etape de verificare bazate pe rezultate:

• Prima tranșă (lunile 0–9): descoperire, produs minim viabil (MVP, cea mai mică versiune testabilă în servicii reale) și primele două servicii-pilot. Finanțarea nucleului ar fi confirmată pentru cel puțin 18–24 de luni.
• Extinderea s-ar aproba pe baza dovezilor din servicii reale, nu după numărul de componente publicate.
• Obligațiile pentru instituții ar crește numai după ce produsul este stabil și evaluat.

Cele șapte condiții de lansare:

1. Mandat clar: se știe cine deține produsul, cine aprobă și cine susține piloții.
2. Finanțare dovedită: bugetul nucleului asigurat pentru 18–24 de luni, cu sursa aprobată.
3. Parteneri reali: instituțiile-pilot au date inițiale, echipe și responsabili numiți.
4. Produs limitat: MVP-ul e separat de platformele de plăți, identitate și interoperabilitate.
5. Auditabilitate: cod, documentație, decizii, rezultate ale testelor și costuri publice.
6. Ieșire controlată: programul poate fi oprit sau replanificat.
7. Continuitate: memorandum aprobat de Guvern, mai mulți responsabili de cod, plan pentru schimbarea conducerii, ca programul să nu depindă de o singură echipă.

1. Problema publică și obiectivele

1.1 Problema

Interfețele serviciilor publice diferă de la o instituție la alta (formulare, mesaje de eroare, navigare, accesibilitate). Așa că oamenii reînvață fiecare serviciu, iar statul plătește de mai multe ori pentru același lucru. Accesibilitatea se verifică de regulă abia după lansare, deși OUG nr. 112/2018 stabilește obligații. Cine nu vorbește bine românește înțelege greu ce are de făcut. În 2025, doar 25,4% dintre utilizatorii de internet din România au folosit un site sau o aplicație a unei autorități publice, cel mai mic procent din UE (Eurostat). În Indicele guvernării digitale 2025 al Organizației pentru Cooperare și Dezvoltare Economică (OCDE), România are cel mai mic scor dintre cele 42 de țări evaluate: 0,24 din 1.

1.2 Limitele problemei

Registrele care nu comunică, procesele redundante sau sistemele vechi nu se rezolvă prin interfețe comune. SDGR ar documenta explicit dependențele de alte programe: interoperabilitatea, ROeID (identitatea electronică națională) și Ghișeul.ro.

1.3 Rezultatul urmărit pentru cetățean

Omul găsește serviciul potrivit și înțelege pașii și costurile; termină cererea mai des fără ajutor; folosește serviciul cu tastatura, cu tehnologii asistive, pe mobil și pe o conexiune lentă; primește informații în limba lui; înțelege ce date se colectează și ce urmează.

1.4 Trei rezultate verificabile ale programului

2. Viziunea: un produs pentru cetățean

SDGR n-ar fi un regulament și nici un kit grafic, ci un produs digital întreținut permanent, al cărui client final este contribuabilul. Ar avea:

• utilizatori finali (oamenii) și intermediari (echipele din instituții și de la furnizori), pentru care ar trebui să fie varianta cea mai simplă și mai ieftină;
• un responsabil de produs și o echipă permanentă;
• o foaie de parcurs publică, cu versiuni și note de lansare;
• măsurarea rezultatelor și un canal de feedback.

Fără un proprietar, un sistem de design nu mai e întreținut. Exemplul sistemului de design al guvernului SUA (USWDS) din 2025–2026 o arată (Sistemul american (USWDS)).

3. Principii

Douăsprezece principii: nevoile reale ale oamenilor, testate cu utilizatori, inclusiv cu persoane cu dizabilități; utilitatea înaintea uniformității; accesibilitate și limbaj clar din prima zi, ca criterii de acceptare; mai multe limbi pentru același serviciu; progres dovedit, cu posibilitatea de oprire; consecvent, nu identic; varianta cea mai ușoară să fie cea corectă; deschis și neutru față de furnizori; un proprietar pentru fiecare livrabil; minimalism operațional; „dovedim, apoi cerem”; continuitate protejată de schimbările politice.

4. Ce este și ce nu este SDGR

4.1 Trei domenii, trei proprietari

Instituția ar răspunde de serviciul final și de conformitatea lui.

4.2 Ce nu este SDGR

Nu ar fi un portal unic, un sistem de dosare, o platformă de plăți, un registru de persoane, un furnizor de identitate sau o autoritate care certifică site-uri. Ar oferi interfețele și regulile de integrare, fără să preia exploatarea acestor servicii.

5. Ce aș prelua din Europa și din SUA

Am pornit de la analiza celorlalte 26 de state UE (Legile statelor UE, Sistemele de design din Europa) și a sistemului american (Sistemul american (USWDS)). Aș prelua:

• tipare de servicii bazate pe cercetare (GOV.UK, Regatul Unit) → §6.5;
• model federat cu teme pe instituții și proces de maturizare a componentelor (NL Design System, Țările de Jos; Designsystemet, Norvegia) → §6.4, §6.8;
• componente web cu accesibilitatea pe primul loc (KoliBri/KERN, Germania; gov.cz, Cehia; DÁP, Ungaria), ca ipoteză de testat → §6.6;
• portal de cunoaștere (Aksel, Norvegia) → §6.7;
• plata după verificarea independentă a conformității (Italia, măsura 1.4.1 din Planul Național de Redresare și Reziliență, PNRR, aproximativ 6.000 de primării aliniate) → §13, §14.4;
• inventar inițial și calendare publice (Portugalia, Decretul-lege 49/2024) și verificarea conformității la avizarea investițiilor IT (Portugalia, Cehia) → etapa 0, §13;
• cerințe minime într-o anexă, procedura de 10+10 zile lucrătoare pentru componente noi, bară de feedback, responsabil cu experiența utilizatorului (UX) (ID-SK, Slovacia) → §6.8, §8, §13;
• servicii prioritare și 24 de luni pentru o versiune majoră nouă (DSFR, Franța) → §10.5;
• răspuns la sesizările de accesibilitate în 2 săptămâni (Finlanda, Legea 306/2019) → §8;
• echipa care construiește separată de cea care controlează (Ungaria) → §10;
• banner oficial, trepte de culoare calibrate, pagini de teste, model de maturitate, scanarea adoptării (USWDS, SUA) → §6.3, §6.4, §8, §15.

Aș evita: mandatul legal înaintea produsului; doar recomandări, fără pârghii (în SUA, adoptarea era sub 20% în 2025, după 10 ani); o singură echipă fără buget protejat (SUA, 2025–2026); avizarea standardului de un forum din care fac parte firme; obligații locale fără finanțare; autoevaluarea conformității fără măsurare independentă.

6. Arhitectura produsului

6.1 Straturile și domeniile

Șapte straturi: (1) principii, conținut, accesibilitate, cercetare; (2) fundamente (design tokens) și teme; (3) stratul de încredere; (4) componente; (5) tipare de servicii românești; (6) șabloane de pagină; (7) modele de site pentru primărie, școală, spital, minister. Straturile 1–4 formează nucleul, 5–6 tiparele de servicii, iar stratul 7 intră în lista de lucrări amânate, după validare.

6.2 MVP și lucrările amânate

Nucleul MVP, până în luna 9: principii de conținut și ghid pentru erori și formulare; design tokens pe trei niveluri, plus teme, cu contrast verificat; bannerul oficial și identificatorul instituțional; în jur de 12 componente de bază, plus elementele stratului de încredere (lista în Anexa B); primele tipare (date personale, CNP, adresă, „Înainte să începeți”, verificare, confirmare); documentație, pachet sursă, bibliotecă Figma, note de lansare; arhitectură multilingvă (texte externalizate, limba păstrată pe tot parcursul, fonturi cu diacritice și chirilice).

Lucrări amânate (backlog), decise după cererea reală și costul total: pachete pentru CMS-uri (sisteme de administrare a conținutului), începând cu unul ales din inventar, de exemplu WordPress; pachete React, Angular, Vue doar dacă le folosesc piloții; modele complete de site; asistent conversațional, integrarea cu portofelul european de identitate digitală, automatizări de back-office. Nu sunt respinse, ci amânate până după primele implementări.

6.3 Stratul de încredere: un prim rezultat vizibil

Bannerul oficial ar apărea pe fiecare site al statului, cu textul propus „Un site oficial al statului român. Cum verificați?”; la extindere ar explica domeniul .gov.ro și HTTPS. Ar avea variante în limbile de interfață, iar regula domeniilor pentru autoritățile locale s-ar clarifica în etapa 0. Identificatorul instituțional (subsolul standard) ar conține numele instituției și legăturile cerute de lege: accesibilitate, protecția datelor, informații de interes public, contact, petiții. Bannerul e un indicator educativ, nu un mecanism de autentificare: un site fals îl poate copia. Valoarea lui vine din combinația cu .gov.ro, HTTPS și campaniile de informare, iar prezența lui se poate verifica automat.

6.4 Design tokens și teme

Ierarhia ar fi: de bază → semantice → ale componentelor → tema instituției, iar o temă ar putea modifica doar un set explicit de design tokens. Culorile ar avea trepte de la 0 (alb) la 100 (negru), calibrate pe intervale exacte de luminanță, ca în USWDS. Numai așa diferența de treaptă garantează contrastul. De exemplu, o diferență de 50+ trece nivelul AA din WCAG (Ghidurile pentru accesibilitatea conținutului web). Fonturile ar fi deschise, cu ș și ț cu virgulă, cu ő și ű și cu chirilice. Grila ar folosi unitatea de 8 px, cu proiectare întâi pentru telefoane ieftine, iar valorile din Figma și din cod ar corespunde una la una.

6.5 Tipare românești

În MVP: nume (mai multe prenume, diacritice, alte alfabete), CNP (validare clară, fără să înlocuiască validarea de pe server), adresă românească (județ → localitate cu cod SIRUTA, codul din registrul oficial al localităților → stradă, bloc, scară, apartament; adresă din străinătate), „Înainte să începeți” (ce îți trebuie, cost, durată, limbi de răspuns, în acord cu Regulamentul UE 2018/1724 privind portalul digital unic), verificarea răspunsurilor și confirmarea.

După MVP: IBAN, telefon, e-mail; încărcarea documentelor; interfața de plată (plata o asigură Ghișeul.ro); interfața de autentificare (ROeID, apoi portofelul european); „Stadiul cererii mele”; date pe care statul le are deja, după principiul „o singură dată” (Legea nr. 242/2022); programarea la ghișeu; feedback la final; selectarea limbii.

6.6 Decizii tehnice: testare înainte de standardizare

Direcția propusă este HTML și CSS plus componente web, cu pachete pentru framework-uri. Ar fi verificată prin trei probe: un site static, o aplicație de formulare și CMS-ul unei instituții-pilot. Testele obligatorii ar acoperi accesibilitatea (inclusiv funcționarea fără JavaScript), compatibilitatea, întreținerea și performanța pe conexiuni lente. Ar mai acoperi corespondența design–cod și securitatea (listă publică a componentelor software, SBOM, pachete semnate). Rezultatele s-ar consemna în decizii de arhitectură documentate public înainte de etapa 2.

6.7 Publicare, securitate și protecția datelor

Cod public, cu versiuni semnate și verificări automate de accesibilitate și de regresie. Site-ul design.gov.ro ar fi și portal de cunoaștere: pentru fiecare componentă, utilizare, greșeli de evitat, exemple, rezultatele testelor și limite cunoscute. Ar exista un proces pentru vulnerabilități și revenire la versiunea anterioară. Componentele nu ar colecta implicit date analitice sau personale, iar exemplele ar folosi date fictive.

6.8 Niveluri de maturitate a componentelor

7. Multilingvism: arhitectură din prima zi, traduceri pe etape

Obiectivul: oricine locuiește în România să înțeleagă ce are de făcut, într-o limbă pe care o înțelege. Arhitectura ar fi multilingvă din prima zi; traducerile ar veni pe etape, după obligațiile legale, numărul de utilizatori și capacitatea de întreținere.

7.1 Pe cine ar servi

Toți utilizatorii, în română clară; minoritățile naționale, cu maghiara prioritară, apoi germana, ucraineana, romani, sârba, turca și altele, după nevoi și pragul legal; cetățenii UE și rezidenții străini, în engleză; persoanele sub protecție temporară, în ucraineană; persoanele surde, în limba semnelor române pentru informațiile-cheie; persoanele cu competențe de citire reduse, prin text ușor de citit.

7.2 Traducerile, pe etape

Componentele ar suporta texte cu 30–40% mai lungi, ar exista un glosar oficial, textele cu efect juridic ar fi revizuite de oameni, iar româna ar rămâne versiunea de referință juridică. Baza legală (pragul din Codul administrativ, limba semnelor, portalul digital unic, protecția temporară) s-ar verifica în etapa 0.

8. Accesibilitate și utilizabilitate pentru absolut toți

Ținta tehnică ar fi WCAG 2.2 nivel AA, asumată voluntar. Referința legală rămâne standardul european EN 301 549 și OUG nr. 112/2018; versiunile noi ale WCAG nu devin automat obligații. Verificarea s-ar face pe trei niveluri: componenta (echipa SDGR, cu pagină publică de teste și raport de conformitate la fiecare versiune majoră), fluxul complet (instituția, cu utilizatori) și serviciul publicat (proprietarul, cu declarație de accesibilitate și plan de remediere).

O componentă ar deveni „stabilă” doar după teste automate, teste manuale (tastatură, mărire 200–400%, contrast), teste cu cititoarele de ecran NVDA, JAWS, VoiceOver și TalkBack, cu voce în română și sesiuni plătite cu persoane cu dizabilități. Instituția ar răspunde sesizărilor de accesibilitate în cel mult 10 zile lucrătoare (țintă propusă). Componentele accesibile nu garantează un serviciu accesibil; răspunderea rămâne la instituție.

9. Modelul de colaborare: patru piloni

Cei patru piloni ar fi ADR, echipa tehnică permanentă, universitățile și mediul privat, în jurul cărora lucrează instituțiile, organizațiile persoanelor cu dizabilități, organizațiile civice de tehnologie și cetățenii. Universitățile și firmele aduc capacitate și calitate, dar nu înlocuiesc echipa plătită și nu răspund de serviciile în producție.

9.1 ADR: responsabilitate instituțională, finanțare, guvernanță, continuitate

ADR ar deține produsul, ar numi un responsabil de produs cu mandat de cel puțin 3 ani și ar prezida Comitetul director. Ar asigura o linie bugetară multianuală, guvernanța și continuitatea, și ar raporta public prin panoul de adoptare și raportul anual. Nu ar decide detaliile tehnice și nu ar sancționa instituțiile pentru un produs nestabil. Competența juridică exactă a ADR s-ar confirma printr-o notă juridică în etapa 0.

9.2 Echipa tehnică permanentă: arhitectură, întreținere, securitate, versiuni, suport

Echipa plătită (§14) ar răspunde de arhitectură, întreținere, securitate, versiuni, suport, porțile de calitate și integrarea contribuțiilor externe. Fiecare componentă stabilă ar avea un responsabil și un înlocuitor, ar exista cel puțin doi administratori care pot publica versiuni, iar echipa nu ar administra sistemele interne ale instituțiilor.

9.3 Universitățile și studenții: dezvoltare, cercetare UX, testare, accesibilitate, documentație

Forme propuse: 3–5 laboratoare SDGR universitare în centre regionale diferite, cu grant anual; proiecte de semestru cu credite ECTS (sistemul european de credite de studiu); lucrări de licență și disertații; stagii plătite de 3–6 luni; testare cu utilizatori, inclusiv în mediul rural; audituri de accesibilitate; documentație și traduceri; un hackathon anual.

Exemple de universități: Politehnica București, Babeș-Bolyai, „Alexandru Ioan Cuza”, Universitatea de Vest din Timișoara, Universitatea Națională de Arte din București (UNArte), Universitatea de Arhitectură și Urbanism „Ion Mincu” (UAUIM), Academia de Studii Economice (ASE), Universitatea de Artă și Design (UAD) din Cluj. Exemplele nu reprezintă angajamente. Studenții nu ar lucra direct în producție. Contribuțiile s-ar face sub EUPL-1.2 (licența publică a UE, pentru cod) sau CC BY 4.0 (pentru documentație), cu DCO (certificatul de origine a contribuției).

9.4 Mediul privat: expertiză, revizuire de cod, mentorat, practici validate în producție

Specialiști detașați, cu ore donate de angajator („SDGR Fellows”), revizori externi de cod, mentori pentru laboratoare și furnizori care folosesc SDGR și raportează problemele. Garanții: firmele nu au drept de vot asupra standardului; contribuțiile sunt publice; experții depun declarații de interese; participarea nu aduce avantaje în achiziții; rolurile consultative se ocupă prin rotație; partenerii nu au acces la producție sau la date; verificarea conformității e separată de firma care face migrarea.

9.5 Ceilalți participanți

Instituțiile utilizatoare, cu un responsabil UX numit treptat și fără drept să modifice singure nucleul; organizațiile persoanelor cu dizabilități, cu loc permanent în Consiliul consultativ; structurile asociative ale administrației locale (asociațiile municipiilor, orașelor și comunelor și Uniunea Națională a Consiliilor Județene); organizațiile civice de tehnologie, de exemplu Code for Romania; cetățenii, prin feedback și teste.

10. Guvernanța

10.1 Structuri, mandate și limite

Comitetul director (ADR, responsabilul de produs, arhitectul tehnic, reprezentanți ai Guvernului și ai administrației locale) ar decide strategia, bugetul și foaia de parcurs, fără deciziile tehnice obișnuite. Responsabilul de produs ar stabili prioritățile și ar publica indicatorii. Echipa tehnică ar răspunde de arhitectură, testare și lansări. Consiliul consultativ ar face recomandări publice, fără drept de veto și fără avantaje în achiziții. Instituțiile-pilot ar răspunde de serviciul final. Grupurile de lucru deschise (accesibilitate; conținut și limbi; componente; integrare) ar lucra prin procesul public de propunere.

10.2 Cine decide ce (RACI)

R = execută, A = răspunde de decizie, C = este consultat, I = este informat

10.3 Reguli de decizie

Orice schimbare de arhitectură ar avea o decizie documentată public. Contribuțiile externe ar trece prin verificarea licenței, revizuire de cod și audit de calitate. Conținutul cu efect juridic l-ar decide autoritatea competentă, nu comunitatea open-source. Excepțiile instituționale ar fi publice, motivate și cu termen de expirare.

10.4 Continuitate

Cel puțin 3–5 responsabili de cod din organizații diferite, acces partajat la infrastructura de publicare și un plan pentru schimbarea sponsorului sau a furnizorului.

10.5 Politica de versiuni

Versionare semantică strictă, cel mult o versiune majoră pe an și 24 de luni pentru adoptare, timp în care versiunea anterioară primește corecturi de securitate.

11. Serviciile-pilot

11.1 Cum ar fi alese

Printr-un apel cu criterii publice, după capacitatea de a produce dovezi, nu după prestigiu. Prima serie: două servicii, plus un al treilea opțional. Criterii: tranzacții recurente și abandon demonstrabil; cel puțin 8 săptămâni de date comparabile înainte de intervenție; un sponsor și o echipă în instituție; integrare fezabilă fără refacerea sistemului intern; un flux simplu și unul mediu, din instituții de mărimi diferite; participanți cu nevoi diferite; de preferat un pilot cu vorbitori de maghiară sau de altă limbă.

11.2 Tipuri de pilot

Pilotul A: cerere cu documente (date personale, CNP, adresă, încărcare de fișiere, confirmare). Pilotul B: programare sau solicitare simplă. Pilotul C (opțional): serviciu cu plată, doar dacă integrarea cu plățile funcționează și operatorul cooperează.

11.3 Fișa fiecărui pilot (cel mult 5 pagini)

Problema, utilizatorii, fluxul actual, ce rămâne în afara pilotului, sistemele conectate, responsabilitățile, costul estimat, datele de pornire, criteriile de succes și planul de revenire. Instituția ar păstra răspunderea pentru tranzacțiile reale.

12. Calendarul pe etape, cu etape de verificare obligatorii

36 de luni până la decizia de instituționalizare, cu cinci etape de verificare (G0–G4). Duratele sunt orientative; o etapă nu ar începe dacă cea anterioară nu și-a îndeplinit criteriile. După etapa 4 ar urma funcționarea permanentă.

12.1 Când s-ar opri sau replanifica programul

• Nu există un proprietar operațional pentru cel puțin două servicii-pilot.
• Un defect grav de accesibilitate sau de securitate rămâne nerezolvat la stabilizare.
• Costul de integrare depășește semnificativ estimarea și nu există perspectivă de reutilizare.
• Nu se pot colecta date comparabile despre finalizarea serviciilor.
• Echipa nu poate întreține versiunile publicate sau nu poate oferi suportul promis.

13. Adoptare, achiziții și cadru juridic

13.1 Adoptare prin utilitate, nu prin amenzi premature

13.2 Garanții pentru achiziții

Cerințele s-ar descrie prin standarde, nu prin furnizori preferați; contribuitorii voluntari nu ar primi tratament diferit; verificarea conformității ar fi separată de firma care migrează; orice obligație pentru administrația locală ar veni cu analiză de impact și sursă de finanțare. Propunerea nu afirmă că ADR poate impune singură condiții de avizare sau de achiziție: sunt necesare o notă despre competențele ADR, o analiză a PL-x 300/2026 și corelarea cu legislația în domeniu.

13.3 Relația cu inițiativele existente

PL-x 300/2026 (vezi Analiza proiectului de lege) ar putea fi amendat la Camera Deputaților ca lege-cadru pentru un proces pe etape, sau adoptat după G4, ca să consacre un sistem care funcționează deja. Diferențele față de sistemul din proiect: produsul înaintea obligației; etape de verificare în locul datei fixe de 1 ianuarie 2028; pârghii de finanțare în locul amenzilor între instituții; drept la feedback cu termen de răspuns; firmele nu avizează standardul. Legea guvernanței digitale integrate, anunțată în programul de guvernare din octombrie 2026, menționează „standardele unice de interfață”. Acestea ar putea fi chiar SDGR, ca să nu existe două standarde paralele. SDGR ar respecta și ar face mai ușor de aplicat OUG nr. 112/2018, Legea nr. 242/2022, ROeID, portofelul european de identitate digitală și art. 50 din Regulamentul UE privind inteligența artificială.

14. Echipă, resurse și buget

Toate sumele sunt estimări orientative (calcul propriu), de validat cu piața muncii și cu regulile de recrutare. Ipoteza de calcul: 55.000–65.000 € pe an pentru un post echivalent normă întreagă (FTE).

14.1 Echipa, pe etape

Universitățile și voluntarii aduc capacitate suplimentară, nu înlocuiesc nucleul.

14.2 Bugetul central

Estimări (calcul propriu), în milioane de euro.

14.3 Ce nu intră în bugetul central

Implementarea în fiecare instituție (migrare, integrare, testare, conținut, instruire) și modificările sistemelor interne rămân în bugetele și proiectele instituțiilor. Fondul de adoptare pentru autoritățile locale ar veni din fonduri UE, după formula din §14.4.

14.4 Formula fondului de adoptare

Fond = Σ (instituții eligibile din categoria i × costul standard validat pentru categoria i) + verificare independentă + rezervă de risc

Costul standard ar include doar activitățile dovedite în piloți, cu cel puțin trei estimări comparabile pe tip de migrare și verificare ex-post. Numărul de autorități locale finanțate s-ar stabili după calcul, nu înainte, după modelul italian al plății după verificare.

14.5 Surse de finanțare

Bugetul ADR (linie multianuală pentru nucleu); Instrumentul de sprijin tehnic al UE pentru etapele 0–1, care se poate lega de proiectul ADR început în iunie 2026; PoCIDIF (Programul Creștere Inteligentă, Digitalizare și Instrumente Financiare) și cadrul financiar 2028–2034; Digital Europe; contribuții în natură, care nu înlocuiesc nucleul plătit.

15. Măsurarea impactului și evaluarea economică

15.1 Indicatori principali, folosiți la etapele de verificare

15.2 Indicatori secundari: adoptare și acoperire

Site-uri cu banner oficial (scanare automată), servicii construite cu SDGR, servicii pe niveluri de traducere, timpul de răspuns la sesizări, comunitatea, sustenabilitatea (echipă completă, buget pe 3 ani). Nu sunt criterii de trecere la etapele de verificare.

15.3 Reguli pentru comparații

Datele de pornire s-ar colecta înainte de intervenție, ideal cel puțin 8 săptămâni, iar indicatorii s-ar stabili înainte de pilot. Comparațiile s-ar face pe aceeași perioadă și pe aceleași tipuri de utilizatori. S-ar publica și limitările, iar efectele sistemului de design s-ar separa de cele ale altor schimbări.

15.4 Modelul minim de cost-beneficiu

Beneficiul anual net estimat = (reducerea costului pe tranzacție × volumul anual) + costuri de dezvoltare evitate + costuri de suport reduse − costuri suplimentare de întreținere și integrare

Investiția inițială s-ar contabiliza separat. Nu aș publica o rentabilitate (ROI) în cifre până nu există date de pornire, costuri auditate și dovezi pentru fiecare valoare.

16. Riscuri și mecanisme de control

17. Primele 90 de zile

18. Criterii de acceptare pentru versiunea 1.0

Versiunea 1.0 ar fi acceptată când:

• cel puțin două servicii reale folosesc o versiune stabilă a nucleului, fără ramificări critice;
• fiecare componentă stabilă are specificație, exemple, teste automate și manuale și limite publicate;
• interacțiunile esențiale funcționează cu tastatura și cu tehnologii asistive;
• există un raport de conformitate a accesibilității pentru 1.0;
• nivelul 1 de multilingvism e complet în cel puțin 3 limbi (română, maghiară, engleză), cu glosar;
• codul, versiunile, procedura pentru vulnerabilități și suportul sunt disponibile;
• compatibilitatea e demonstrată pe platformele din inventar;
• datele comparabile din piloți sunt publicate;
• există responsabil, buget și nivel de serviciu pentru întreținere;
• există proces de contribuție și de excepții;
• evaluarea separă efectele sistemului de design de alte schimbări.

19. Opțiunile de decizie

Propunerea concretă: opțiunea A, cu bugetul pentru lunile 0–9 aprobat pe bază de deviz, finanțarea nucleului confirmată pe 18–24 de luni, un punct de verificare public în luna 9 și decizia de extindere după raportul comparativ din luna 18.

Anexe

Anexa A. Documente necesare înainte de aprobare

Notă juridică (competențele ADR, avizare, legătura cu PL-x 300/2026 și cu legea guvernanței digitale integrate, multilingvism); inventarul platformelor și serviciilor; situația de pornire pentru accesibilitate și utilizare; deciziile de arhitectură documentate; fișele piloților și acordurile; devizul multianual; planul de evaluare independentă, cu metoda de cost-beneficiu.

Anexa B. Componente: MVP față de v1.0

Anexa C. Glosar

• Sistem de design: principii, design tokens, componente, tipare, șabloane și ghiduri, plus un proces de guvernanță.
• Design tokens: valorile de bază ale designului (culori, mărimi, spații), definite o dată și folosite peste tot.
• MVP (produs minim viabil): cea mai mică versiune care poate fi testată în servicii reale.
• Punct de verificare (gate): momentul în care se decide, după criterii publice, trecerea la etapa următoare.
• Raport de conformitate a accesibilității: arată în ce măsură un produs respectă standardele de accesibilitate.
• Decizie de arhitectură documentată: înregistrarea publică a unei decizii tehnice și a motivelor ei.
• EUPL-1.2: licența publică a Uniunii Europene pentru software deschis.
• DCO: certificat de origine a contribuției.

Anexa D. Documente de fundamentare

• Regulile europene: cadrul european de accesibilitate, utilizabilitate și sisteme de design.
• Sistemele de design din Europa: sistemele de design guvernamentale din Europa.
• Parcursul proiectului de lege și Analiza proiectului de lege: traseul și analiza PL-x 300/2026.
• Legile statelor UE: comparația cu actele adoptate în celelalte 26 de state UE.
• Ce există deja în România: regulile, ghidurile și resursele românești pe care se sprijină propunerea.
• Sistemul american (USWDS): sistemul american și lecțiile lui.

Surse

• Eurostat: folosirea serviciilor publice online (isoc_ciegi_ac)
• OCDE: Digital Government Outlook 2026, fișa României
• GOV.UK Service Standard
• USWDS: folosirea culorii
• Comisia Europeană: standarde pentru Directiva privind accesibilitatea web

← Toate documentele de cercetare