CoR & EESC · EU public sector · 2020–May 2026
Core impact
One shared design system used across CoR and EESC products in three frameworks
This project covered design-system and cross-application UX work for institutional platforms used by staff and members, built on the Europa Component Library (ECL). The work focused on making related products feel coherent, improving complex administrative journeys, and giving teams reusable patterns they could implement across different frameworks.
WCAG 2.2 AA was the design and validation baseline, built into component specifications and checked through a combination of accessibility tools and manual review. This was sustained modernization work across legacy products, not a single redesign or framework rewrite.
BSprint 0 & problem discovery
Applications had evolved separately, so familiar tasks could behave differently from one platform to another. The opportunity was to improve consistency and accessibility without ignoring existing business logic, framework differences, release schedules, or the need to keep daily services running.
Primary persona
Internal persona
Mapping journeys across products surfaced duplicated work, inconsistent behaviours and friction in high-use search and data tasks. The baseline recorded where the same task used different patterns in different products, and logged accessibility issues by severity.
CUsability and accessibility audit
I reviewed existing interfaces against the 10 usability rules of Nielsen Norman Group, the EU design guidelines and the WCAG 2.2 AA accessibility standard, then turned the findings into shared system decisions.
| Usability rule | What I evaluated | Design-system response |
|---|---|---|
| Visibility of system status | State feedback, loading indicators and how clearly each screen showed what the system was doing. | Complete, documented component states, including loading, empty, error and success. |
| Match between system and real world | Institutional domain terminology in labels, navigation and data grids. | Descriptive labels and content guidance written for each component. |
| Consistency and standards | Colour, typography, data-grid and filter behaviour across products, compared with ECL and the EU guidelines. | Shared design tokens and 140+ reusable components with one interaction language. |
| Recognition rather than recall | How much users had to remember to search and narrow large result sets. | Reusable search and filter patterns with visible, editable criteria. |
| Accessibility and contrast | Contrast, keyboard behaviour, focus, semantics and reflow (WCAG 2.2 AA, EN 301 549). | Contrast verified for every token pair (headings 10.06:1, buttons 10.0:1); keyboard and ARIA requirements in each spec. |
Review contrast, typography, responsive reflow, content hierarchy, and status communication so information is not conveyed by colour alone.
Specify keyboard behaviour, visible focus, logical order, sufficiently usable targets, and clear interaction states for common components.
Design predictable navigation, descriptive labels, helpful instructions, and clear error messages that say how to fix the problem.
Document semantic structure and ARIA requirements for engineering review, then check behaviour with assistive technology where available.
My validation toolkit combined automated checks (including axe and WAVE), contrast review, manual keyboard checks, and assistive-technology review where available. Findings were prioritised by severity and user impact, then discussed with product and engineering partners.
When a legacy backend or framework constrained the ideal solution, I explored the most accessible feasible pattern, documented the trade-off, and kept unresolved work visible for follow-up. Automated results supported review; they did not replace human evaluation.
DIteration & user testing
I worked in short cycles with product owners and developers and tested each pattern in real tasks, with 5 participants from staff and members.
Reviewed existing interfaces and accessibility issues; mapped journeys across products to find duplicated work, inconsistent behaviours, and friction.
Aligned user needs, product priorities, policy requirements, and implementation constraints with application owners and delivery teams.
Created flows, wireframes, prototypes, design tokens, component states, usage guidance, and accessibility requirements in Figma.
Used usability feedback, heuristic review, accessibility checks, and developer collaboration to refine patterns before and during implementation.
| Test scenario | Legacy pattern | System pattern |
|---|---|---|
| Find a record with search and filters | Search and filters behaved differently in each product. | One search and filter pattern with visible, editable criteria. |
| Complete a common admin task | The same task had different steps and labels per application. | Shared components and labels across applications. |
| Complete the task by keyboard only | Missing focus states and inconsistent tab order. | Visible focus and documented keyboard behaviour in every component spec. |
Frequent users relied on habits built in one application and were slowed down when the next one behaved differently.
ESystem architecture & data grids
The system connected visual decisions to implementation guidance: shared foundations, reusable components, interaction states, and documented behaviour for HTML, React and Angular, responsive down to compact phone viewports. Explore the full design system documentation.
I wrote the logo and colour guidelines for the CoR and EESC brands so both institutions sit clearly within the European family. Logo usage follows the rules of the European emblem, the twelve gold stars on Reflex Blue, so institutional marks and the EU emblem appear together consistently.
Corporate Blue, shared with the EU emblem, with Pantone, HEX, RGB and CMYK values for print and screen.
The EESC and CoR logos side by side, both built around the EU flag.
A map of the shared styles and components used in every product.
Persona work helped keep the needs of experienced, frequent users visible while improving clarity for less frequent users.
One view of a document’s progress across all 24 EU languages, from translation to printshop and distribution, built from the system’s data-grid and dialog components.
Key figures, commission deadlines and active opinions on one screen, with date, theme and commission filters, colour-coded by commission.
Colour decisions were checked against contrast requirements and documented as part of the accessibility work.
UX metrics give the team one way to measure usability and check whether a change really helps users.
FBusiness impact & retrospective
140+ components and 70+ documented patterns, specified for HTML, React and Angular, with WCAG 2.2 AA requirements in every component.
Shared patterns gave related products a common interaction language while leaving room for application-specific needs.
Tokens, component states, and framework-aware specifications gave design and engineering teams a shared reference for decisions.
Accessibility is now part of every component from day one, not a fix at the end.
Rather than treating handoff as the finish line, I stayed involved as designs met existing code and release constraints, helping teams make informed trade-offs without losing sight of the user need.
This project strengthened my ability to align product owners, policy stakeholders, and engineers around evidence and shared standards, especially when the best solution must work within an existing platform.