Chapter 6 of 8 · How I see collaboration~3 minutes
The state is accountable, a permanent team builds, universities and companies help
So far I have described what a common system could look like. Now comes the harder part: who builds it, who maintains it and who is accountable for it.
I have seen two ways in which a design system for the state dies:
- in Romania, in 2016–2017: a good guide, but with no institution to own it, no budget and no team. It was abandoned;
- in the United States, in 2025–2026: the best-known government design system in the world came to depend on a very small team. It went 15 months without a single new version.
That is why I believe responsibility has to be clear, and the work has to be shared among several parties, without anyone being able to take control.
1. The state, through the Romanian Authority for Digitalisation (ADR)
What it does: it is accountable to the public for the system. It secures funding over several years, approves the direction, publishes decisions and results, and guarantees that the system carries on when the leadership changes.
What it doesn’t do: it does not decide day-to-day technical details, and it does not penalise institutions for a product that is not ready yet.
Alongside it: the General Secretariat of the Government (SGG), the office at the centre of government that already owns the Government’s visual identity and the .gov.ro registry, should be part of the system’s leadership.
2. A permanent technical team
What it does: it builds and maintains the system: architecture, security, versions, testing, support for institutions. It checks everything that comes from outside before it enters the system.
What it doesn’t do: it does not run institutions’ internal systems.
Why permanent: a design system is a living product. It needs people who are paid to look after it every day, not just a project with an end date.
Size: 8–10 people at first, 13–18 when the system is mature.
3. Universities and students
What they do: research with users (including in rural areas), testing, accessibility checks, documentation, translations, prototypes.
What they don’t do: they do not work directly on services that are live. Everything they produce goes through the permanent team.
What they gain: real projects, credits for semester projects, bachelor’s and research dissertations, paid internships, grants for university labs.
Suitable faculties: computer science, design, arts and architecture, psychology and sociology, letters and foreign languages, special needs education.
4. Companies and industry specialists
What they do: they bring experience of products used by millions of people: they review code and design, mentor students, and share practices that work.
What they don’t do: they do not vote on the standard and they get no advantage in public procurement.
What they gain: an open standard, the same for everyone, and public recognition for their contribution.
And the others
- Organisations of people with disabilities: a permanent seat on the advisory council and paid testing sessions.
- Local government, through the associations of town halls and county councils: it sets out its needs.
- Civic organisations that already run open digital projects.
- Citizens: feedback, taking part in tests, public proposals.
The rules that keep the balance
- A single institution is accountable. Not a committee with no one in charge.
- The permanent team makes the technical decisions. Outside contributions are welcome, but they go through the team.
- Companies do not vote and have no advantage in procurement. Experts declare their conflicts of interest.
- Everything is public: the code, the decisions, the costs, the test results.
- Several people, from different organisations, can publish versions. The system does not depend on a single person.
For specialists
- Structures: a Steering committee (ADR, the product owner, the technical architect, the Government’s representative, the representative of local government; I propose including the SGG); an Advisory council with no right of veto; open working groups; pilot institutions.
- A RACI matrix for strategy, architecture, new components, major versions, contributions, accessibility tests and the checkpoints.
- Universities: 3–5 regional labs, ECTS credits, internships of 3–6 months, an internal “SDGR Auditor” certification (SDGR: the Government of Romania Design System, as I propose it), contributions under EUPL-1.2 / CC BY 4.0 with a DCO, a path from contributor → trusted contributor → code maintainer.
- The private sector: an “SDGR Fellows” programme (hours donated by the employer), external reviewers, mentors for the labs; seven safeguards against conflicts of interest.
- Continuity: 3–5 code maintainers from different organisations, at least two release administrators, a memorandum approved by the Government, a multi-annual budget.
- ADR’s exact legal powers (for example, whether it can set conditions when it gives its opinion on projects) need to be confirmed by a legal note. The proposal does not assume them.
- Why not a forum with companies that endorse the standard: the current National Council for Digital Transformation (CNTD) is, under Government Decision (HG) no. 89/2020, advisory, and its members include private organisations.
What I base this on
The links lead to the public versions of my research documents; the section number (§) takes you straight to the paragraph cited.
| Claim | Document | Where |
|---|---|---|
| The four-pillar model, the roles and the limits | The full proposal | §9 |
| Governance, RACI, continuity | The full proposal | §10 |
| The size of the team | The full proposal | §14.1 |
| The SGG in the leadership | What already exists in Romania | §3.3, decision 12 |
| GovITHub abandoned | What already exists in Romania | §12 |
| The USWDS crisis 2025–2026, 15 months without a version | The American system (USWDS) | §0, §4 |
| The CNTD is advisory, with private members | Analysis of the bill | §6.3 |
| The RoCHI academic community | What already exists in Romania | §13 |
| Governance models in Europe (NL community-based, Hungary: building kept separate from oversight) | Design systems in Europe; EU member states' laws | §3; §3.2 |