Research · The full proposal

The full proposal: the Romanian Government Design System (SDGR)

This is my full proposal for a shared design system for digital public services, in version 3.0 of 20 October 2026. I call it SDGR, from the Romanian Sistemul de Design al Guvernului României (the Romanian Government Design System). It is not an official document of the Government or of the Romanian Authority for Digitalisation (ADR), the government agency responsible for digitalisation. Here you will find what I would build, who would decide, the 36-month timeline, the estimated budget and the criteria for continuing or stopping the programme. The costs, the timeline and the legal solutions are assumptions that need to be validated.

0. The proposed decision

I propose that SDGR be approved as a phased programme, with a public 36-month horizon and with review points based on results:

• The first tranche (months 0–9): discovery, a minimum viable product (MVP, the smallest version that can be tested in real services) and the first two pilot services. Funding for the core would be confirmed for at least 18–24 months.
• Expansion would be approved on the basis of evidence from real services, not on the number of components published.
• Obligations for institutions would increase only after the product is stable and has been evaluated.

The seven launch conditions:

1. A clear mandate: it is known who owns the product, who approves and who supports the pilots.
2. Proven funding: the core budget is secured for 18–24 months, with an approved source.
3. Real partners: the pilot institutions have baseline data, teams and named people in charge.
4. A limited product: the MVP is kept separate from the payment, identity and interoperability platforms.
5. Auditability: code, documentation, decisions, test results and costs are public.
6. A controlled exit: the programme can be stopped or replanned.
7. Continuity: a memorandum approved by the Government, several code maintainers and a plan for a change of leadership, so that the programme does not depend on a single team.

1. The public problem and the objectives

1.1 The problem

The interfaces of public services differ from one institution to another (forms, error messages, navigation, accessibility). So people have to learn each service all over again, and the state pays several times for the same thing. Accessibility is usually checked only after launch, even though Government Emergency Ordinance (OUG) no. 112/2018 sets out obligations. People who do not speak Romanian well find it hard to understand what they have to do. In 2025, only 25.4% of internet users in Romania used a website or an app of a public authority, the lowest share in the EU (Eurostat). In the 2025 Digital Government Index of the Organisation for Economic Co-operation and Development (OECD), Romania has the lowest score of the 42 countries assessed: 0.24 out of 1.

1.2 The limits of the problem

Registers that do not talk to each other, redundant processes and legacy systems cannot be fixed with shared interfaces. SDGR would explicitly document its dependencies on other programmes: interoperability, ROeID (the national electronic identity) and Ghișeul.ro (the national online payment platform).

1.3 The intended result for citizens

People find the right service and understand the steps and the costs; they complete the application more often without help; they use the service with a keyboard, with assistive technologies, on a mobile phone and on a slow connection; they get information in their own language; they understand what data is collected and what happens next.

1.4 Three verifiable results of the programme

2. The vision: a product for citizens

SDGR would be neither a regulation nor a graphics kit, but a digital product that is permanently maintained, whose end customer is the taxpayer. It would have:

• end users (people) and intermediaries (teams in institutions and at suppliers), for whom it should be the simplest and cheapest option;
• a product owner and a permanent team;
• a public roadmap, with versions and release notes;
• measurement of results and a feedback channel.

Without an owner, a design system stops being maintained. The example of the US government's design system (USWDS) in 2025–2026 shows this (The American system (USWDS)).

3. Principles

Twelve principles: people's real needs, tested with users, including people with disabilities; usefulness before uniformity; accessibility and plain language from day one, as acceptance criteria; several languages for the same service; proven progress, with the option to stop; consistent, not identical; the easiest option should be the right one; open and vendor-neutral; an owner for every deliverable; operational minimalism; “prove first, then require”; continuity protected from political change.

4. What SDGR is and what it is not

4.1 Three domains, three owners

The institution would be responsible for the final service and for its compliance.

4.2 What SDGR is not

It would not be a single portal, a case management system, a payment platform, a population register, an identity provider or an authority that certifies websites. It would provide the interfaces and the integration rules, without taking over the operation of these services.

5. What I would take from Europe and the US

I started from the analysis of the other 26 EU member states (EU member states' laws, Design systems in Europe) and of the American system (The American system (USWDS)). I would take:

• research-based service patterns (GOV.UK, United Kingdom) → §6.5;
• a federated model with themes for each institution and a maturity process for components (NL Design System, the Netherlands; Designsystemet, Norway) → §6.4, §6.8;
• web components with accessibility first (KoliBri/KERN, Germany; gov.cz, Czechia; DÁP, Hungary), as a hypothesis to be tested → §6.6;
• a knowledge portal (Aksel, Norway) → §6.7;
• payment after independent verification of compliance (Italy, measure 1.4.1 of the National Recovery and Resilience Plan, PNRR, about 6,000 municipalities aligned) → §13, §14.4;
• an initial inventory and public timelines (Portugal, Decree-Law 49/2024) and compliance checks when IT investments are approved (Portugal, Czechia) → stage 0, §13;
• minimum requirements in an annex, the 10+10 working-day procedure for new components, a feedback bar, a person responsible for the user experience (UX) (ID-SK, Slovakia) → §6.8, §8, §13;
• priority services and 24 months for a new major version (DSFR, France) → §10.5;
• a response to accessibility complaints within 2 weeks (Finland, Act 306/2019) → §8;
• the team that builds kept separate from the team that checks (Hungary) → §10;
• an official banner, calibrated colour grades, test pages, a maturity model, adoption scanning (USWDS, US) → §6.3, §6.4, §8, §15.

I would avoid: a legal mandate before the product; recommendations only, with no levers (in the US, adoption was below 20% in 2025, after 10 years); a single team without a protected budget (US, 2025–2026); having the standard approved by a forum that includes companies; local obligations without funding; self-assessment of compliance without independent measurement.

6. The product architecture

6.1 Layers and domains

Seven layers: (1) principles, content, accessibility, research; (2) foundations (design tokens) and themes; (3) the trust layer; (4) components; (5) Romanian service patterns; (6) page templates; (7) website models for a town hall, school, hospital or ministry. Layers 1–4 form the core, 5–6 the service patterns, and layer 7 goes into the list of deferred work, after validation.

6.2 The MVP and the deferred work

The MVP core, by month 9: content principles and a guide to errors and forms; design tokens on three levels, plus themes, with checked contrast; the official banner and the institutional identifier; around 12 basic components, plus the elements of the trust layer (the list is in Annex B); the first patterns (personal details, CNP (Romanian personal numeric code), address, “Before you start”, check your answers, confirmation); documentation, a source package, a Figma library, release notes; a multilingual architecture (externalised text, the language kept throughout, fonts with Romanian diacritics and Cyrillic).

Deferred work (backlog), decided according to real demand and total cost: packages for CMSs (content management systems), starting with one chosen from the inventory, for example WordPress; React, Angular and Vue packages only if the pilots use them; complete website models; a conversational assistant, integration with the European Digital Identity Wallet, back-office automation. They are not rejected, only deferred until after the first implementations.

6.3 The trust layer: a first visible result

The official banner would appear on every state website, with the proposed text „Un site oficial al statului român. Cum verificați?” (“An official website of the Romanian state. How can you check?”); when expanded, it would explain the .gov.ro domain and HTTPS. It would have versions in the interface languages, and the domain rule for local authorities would be clarified in stage 0. The institutional identifier (the standard footer) would contain the name of the institution and the links required by law: accessibility, data protection, information of public interest, contact, petitions. The banner is an educational signal, not an authentication mechanism: a fake website can copy it. Its value comes from the combination with .gov.ro, HTTPS and information campaigns, and its presence can be checked automatically.

6.4 Design tokens and themes

The hierarchy would be: base → semantic → component → institution theme, and a theme could change only an explicit set of design tokens. Colours would have grades from 0 (white) to 100 (black), calibrated to exact luminance ranges, as in USWDS. Only then does the difference in grade guarantee contrast. For example, a difference of 50+ passes level AA of WCAG (the Web Content Accessibility Guidelines). Fonts would be open, with ș and ț with a comma below, with ő and ű, and with Cyrillic. The grid would use an 8 px unit, designed first for low-cost phones, and the values in Figma and in code would match one to one.

6.5 Romanian patterns

In the MVP: name (several first names, diacritics, other alphabets), CNP (clear validation, without replacing validation on the server), Romanian address (county → locality with its SIRUTA code, the code from the official register of localities → street, block, entrance, flat; address abroad), “Before you start” (what you need, cost, duration, response languages, in line with Regulation (EU) 2018/1724 on the single digital gateway), check your answers and confirmation.

After the MVP: IBAN, telephone, email; document upload; the payment interface (payment is provided by Ghișeul.ro); the sign-in interface (ROeID, then the European wallet); “My application status”; data the state already holds, under the “once-only” principle (Law no. 242/2022, the Romanian interoperability law); booking an appointment at the counter; feedback at the end; language selection.

6.6 Technical decisions: testing before standardisation

The proposed direction is HTML and CSS plus web components, with packages for frameworks. It would be checked through three trials: a static website, a forms application and the CMS of a pilot institution. The mandatory tests would cover accessibility (including working without JavaScript), compatibility, maintenance and performance on slow connections. They would also cover design–code correspondence and security (a public list of software components, SBOM, signed packages). The results would be recorded in architecture decisions documented publicly before stage 2.

6.7 Publishing, security and data protection

Public code, with signed releases and automated accessibility and regression checks. The design.gov.ro website would also be a knowledge portal: for each component, usage, mistakes to avoid, examples, test results and known limitations. There would be a process for vulnerabilities and for rolling back to the previous version. Components would not collect analytics or personal data by default, and the examples would use fictitious data.

6.8 Component maturity levels

7. Multilingualism: architecture from day one, translations in stages

The objective: anyone who lives in Romania should understand what they have to do, in a language they understand. The architecture would be multilingual from day one; translations would come in stages, according to legal obligations, the number of users and the capacity to maintain them.

7.1 Who it would serve

All users, in plain Romanian; national minorities, with Hungarian as the priority, then German, Ukrainian, Romani, Serbian, Turkish and others, according to need and the legal threshold; EU citizens and foreign residents, in English; people under temporary protection, in Ukrainian; Deaf people, in Romanian Sign Language for key information; people with low reading skills, through easy-to-read text.

7.2 Translations, in stages

Components would support text 30–40% longer, there would be an official glossary, texts with legal effect would be reviewed by people, and Romanian would remain the legal reference version. The legal basis (the threshold in the Administrative Code, sign language, the single digital gateway, temporary protection) would be checked in stage 0.

8. Accessibility and usability for absolutely everyone

The technical target would be WCAG 2.2 level AA, adopted voluntarily. The legal reference remains the European standard EN 301 549 and OUG no. 112/2018; new versions of WCAG do not automatically become obligations. Checks would be done on three levels: the component (the SDGR team, with a public test page and a conformance report for each major version), the complete flow (the institution, with users) and the published service (the owner, with an accessibility statement and a remediation plan).

A component would become “stable” only after automated tests, manual tests (keyboard, 200–400% zoom, contrast), tests with the NVDA, JAWS, VoiceOver and TalkBack screen readers, with a Romanian voice, and paid sessions with people with disabilities. The institution would respond to accessibility complaints within 10 working days at most (proposed target). Accessible components do not guarantee an accessible service; responsibility remains with the institution.

9. The collaboration model: four pillars

The four pillars would be ADR, the permanent technical team, universities and the private sector, around which the institutions, organisations of people with disabilities, civic tech organisations and citizens work. Universities and companies bring capacity and quality, but they do not replace the paid team and are not responsible for services in production.

9.1 ADR: institutional responsibility, funding, governance, continuity

ADR would own the product, would appoint a product owner with a mandate of at least 3 years and would chair the Steering Committee. It would secure a multi-year budget line, governance and continuity, and would report publicly through the adoption dashboard and the annual report. It would not decide technical details and would not penalise institutions for a product that is not stable. ADR's exact legal competence would be confirmed through a legal note in stage 0.

9.2 The permanent technical team: architecture, maintenance, security, releases, support

The paid team (§14) would be responsible for architecture, maintenance, security, releases, support, the quality gates and the integration of external contributions. Each stable component would have an owner and a deputy, there would be at least two administrators who can publish releases, and the team would not run the institutions' internal systems.

9.3 Universities and students: development, UX research, testing, accessibility, documentation

Proposed forms: 3–5 SDGR university labs in different regional centres, with an annual grant; semester projects with ECTS credits (the European Credit Transfer System); bachelor's and master's theses; paid internships of 3–6 months; user testing, including in rural areas; accessibility audits; documentation and translations; an annual hackathon.

Examples of universities: Politehnica Bucharest, Babeș-Bolyai University, Alexandru Ioan Cuza University, the West University of Timișoara, the National University of Arts in Bucharest (UNArte), the “Ion Mincu” University of Architecture and Urbanism (UAUIM), the Bucharest University of Economic Studies (ASE), the University of Art and Design (UAD) in Cluj. The examples are not commitments. Students would not work directly in production. Contributions would be made under EUPL-1.2 (the EU public licence, for code) or CC BY 4.0 (for documentation), with a DCO (Developer Certificate of Origin).

9.4 The private sector: expertise, code review, mentoring, practices proven in production

Seconded specialists, with hours donated by their employer (“SDGR Fellows”), external code reviewers, mentors for the labs and suppliers who use SDGR and report problems. Safeguards: companies have no vote on the standard; contributions are public; experts submit declarations of interest; taking part brings no advantage in procurement; advisory roles rotate; partners have no access to production or to data; compliance checks are kept separate from the company doing the migration.

9.5 The other participants

The user institutions, with a UX lead appointed gradually and with no right to change the core on their own; organisations of people with disabilities, with a permanent seat on the Advisory Council; the associations of local government (the associations of municipalities, towns and communes and the National Union of County Councils); civic tech organisations, for example Code for Romania; citizens, through feedback and tests.

10. Governance

10.1 Structures, mandates and limits

The Steering Committee (ADR, the product owner, the technical architect, representatives of the Government and of local government) would decide the strategy, the budget and the roadmap, without the day-to-day technical decisions. The product owner would set priorities and publish the indicators. The technical team would be responsible for architecture, testing and releases. The Advisory Council would make public recommendations, with no right of veto and no advantage in procurement. The pilot institutions would be responsible for the final service. The open working groups (accessibility; content and languages; components; integration) would work through the public proposal process.

10.2 Who decides what (RACI)

R = carries out the work, A = is accountable for the decision, C = is consulted, I = is informed

10.3 Decision rules

Every architecture change would have a publicly documented decision. External contributions would go through a licence check, code review and a quality audit. Content with legal effect would be decided by the competent authority, not by the open-source community. Institutional exceptions would be public, justified and have an expiry date.

10.4 Continuity

At least 3–5 code maintainers from different organisations, shared access to the publishing infrastructure and a plan for a change of sponsor or supplier.

10.5 Versioning policy

Strict semantic versioning, at most one major version a year and 24 months for adoption, during which the previous version receives security fixes.

11. The pilot services

11.1 How they would be chosen

Through a call with public criteria, according to the capacity to produce evidence, not prestige. The first round: two services, plus an optional third. Criteria: recurring transactions and demonstrable drop-out; at least 8 weeks of comparable data before the intervention; a sponsor and a team in the institution; feasible integration without rebuilding the internal system; one simple flow and one medium flow, from institutions of different sizes; participants with different needs; preferably a pilot with speakers of Hungarian or another language.

11.2 Types of pilot

Pilot A: an application with documents (personal details, CNP, address, file upload, confirmation). Pilot B: an appointment booking or a simple request. Pilot C (optional): a paid service, only if the integration with payments works and the operator cooperates.

11.3 The sheet for each pilot (5 pages at most)

The problem, the users, the current flow, what stays outside the pilot, the connected systems, the responsibilities, the estimated cost, the baseline data, the success criteria and the rollback plan. The institution would remain responsible for the real transactions.

12. The phased timeline, with mandatory review stages

36 months until the decision on institutionalisation, with five review stages (G0–G4). The durations are indicative; a stage would not start if the previous one had not met its criteria. After stage 4, permanent operation would follow. In the tables, L0–L3 means months 0 to 3 (L stands for luna, Romanian for “month”).

12.1 When the programme would be stopped or replanned

• There is no operational owner for at least two pilot services.
• A serious accessibility or security defect remains unresolved at stabilisation.
• The integration cost significantly exceeds the estimate and there is no prospect of reuse.
• Comparable data on service completion cannot be collected.
• The team cannot maintain the published versions or cannot provide the promised support.

13. Adoption, procurement and the legal framework

13.1 Adoption through usefulness, not premature fines

13.2 Safeguards for procurement

Requirements would be described through standards, not through preferred suppliers; voluntary contributors would not receive different treatment; compliance checks would be kept separate from the company doing the migration; any obligation for local government would come with an impact assessment and a source of funding. The proposal does not claim that ADR can impose approval or procurement conditions on its own: a note on ADR's competences, an analysis of bill PL-x 300/2026 and alignment with the legislation in the field are needed.

13.3 The relationship with existing initiatives

Bill PL-x 300/2026 (see Analysis of the bill) could be amended in the Chamber of Deputies as a framework law for a phased process, or adopted after G4, to enshrine a system that already works. The differences from the system in the bill: the product before the obligation; review points instead of the fixed date of 1 January 2028; funding levers instead of fines between institutions; a right to feedback with a response deadline; companies do not approve the standard. The law on integrated digital governance, announced in the government programme of October 2026, mentions „standardele unice de interfață” (“single interface standards”). These could be SDGR itself, so that there are not two parallel standards. SDGR would also comply with, and make it easier to apply, OUG no. 112/2018, Law no. 242/2022, ROeID, the European Digital Identity Wallet and Article 50 of the EU Artificial Intelligence Act.

14. Team, resources and budget

All amounts are indicative estimates (my own calculation), to be validated against the labour market and the recruitment rules. The calculation assumption: €55,000–65,000 a year for one full-time equivalent post (FTE).

14.1 The team, by stage

Universities and volunteers bring additional capacity; they do not replace the core.

14.2 The central budget

Estimates (my own calculation), in millions of euros.

14.3 What is not included in the central budget

Implementation in each institution (migration, integration, testing, content, training) and changes to internal systems remain in the institutions' own budgets and projects. The adoption fund for local authorities would come from EU funds, according to the formula in §14.4.

14.4 The formula for the adoption fund

Fund = Σ (eligible institutions in category i × validated standard cost for category i) + independent verification + risk reserve

The standard cost would include only activities proven in the pilots, with at least three comparable estimates per type of migration and ex-post verification. The number of local authorities funded would be set after the calculation, not before, following the Italian model of payment after verification.

14.5 Sources of funding

The ADR budget (a multi-year line for the core); the EU Technical Support Instrument for stages 0–1, which could be linked to the ADR project started in June 2026; PoCIDIF (the Smart Growth, Digitalisation and Financial Instruments Programme) and the 2028–2034 financial framework; Digital Europe; in-kind contributions, which do not replace the paid core.

15. Measuring impact and economic evaluation

15.1 Main indicators, used at the review points

15.2 Secondary indicators: adoption and coverage

Websites with the official banner (automated scan), services built with SDGR, services by translation level, response time to complaints, the community, sustainability (a full team, a 3-year budget). They are not criteria for passing the review points.

15.3 Rules for comparisons

Baseline data would be collected before the intervention, ideally for at least 8 weeks, and the indicators would be set before the pilot. Comparisons would be made over the same period and for the same types of users. The limitations would also be published, and the effects of the design system would be separated from those of other changes.

15.4 The minimum cost-benefit model

Estimated net annual benefit = (reduction in cost per transaction × annual volume) + development costs avoided + reduced support costs − additional maintenance and integration costs

The initial investment would be accounted for separately. I would not publish a return on investment (ROI) figure until there are baseline data, audited costs and evidence for each value.

16. Risks and control mechanisms

17. The first 90 days

18. Acceptance criteria for version 1.0

Version 1.0 would be accepted when:

• at least two real services use a stable version of the core, without critical forks;
• each stable component has a specification, examples, automated and manual tests, and published limitations;
• the essential interactions work with a keyboard and with assistive technologies;
• there is an accessibility conformance report for 1.0;
• level 1 of multilingualism is complete in at least 3 languages (Romanian, Hungarian, English), with a glossary;
• the code, the releases, the vulnerability procedure and support are available;
• compatibility is demonstrated on the platforms in the inventory;
• the comparable data from the pilots are published;
• there is an owner, a budget and a service level for maintenance;
• there is a process for contributions and for exceptions;
• the evaluation separates the effects of the design system from other changes.

19. The decision options

The concrete proposal: option A, with the budget for months 0–9 approved on the basis of a cost estimate, funding for the core confirmed for 18–24 months, a public review point in month 9 and the decision on expansion after the comparative report in month 18.

Annexes

Anexa A. Documents needed before approval

Legal note (ADR's competences, approval, the link with bill PL-x 300/2026 and with the law on integrated digital governance, multilingualism); the inventory of platforms and services; the baseline for accessibility and use; the documented architecture decisions; the pilot sheets and the agreements; the multi-year cost estimate; the independent evaluation plan, with the cost-benefit method.

Anexa B. Components: MVP compared with v1.0

Anexa C. Glossary

• Design system: principles, design tokens, components, patterns, templates and guidance, plus a governance process.
• Design tokens: the basic values of the design (colours, sizes, spacing), defined once and used everywhere.
• MVP (minimum viable product): the smallest version that can be tested in real services.
• Review point (gate): the moment when the move to the next stage is decided, according to public criteria.
• Accessibility conformance report: shows to what extent a product meets accessibility standards.
• Documented architecture decision: the public record of a technical decision and the reasons for it.
• EUPL-1.2: the European Union Public Licence for open-source software.
• DCO: Developer Certificate of Origin.

Anexa D. Background documents

• European rules: the European framework for accessibility, usability and design systems.
• Design systems in Europe: government design systems in Europe.
• The bill's legislative journey and Analysis of the bill: the path and the analysis of PL-x 300/2026.
• EU member states' laws: the comparison with the acts adopted in the other 26 EU member states.
• What already exists in Romania: the Romanian rules, guides and resources on which the proposal rests.
• The American system (USWDS): the American system and its lessons.

Sources

• Eurostat: use of online public services (isoc_ciegi_ac)
• OECD: Digital Government Outlook 2026, Romania country note
• GOV.UK Service Standard
• USWDS: using colour
• European Commission: standards for the Web Accessibility Directive

← All research documents