Case study · Enterprise · Pegasystems 2019–2025
Consistency at scale.
20+ enterprise projects across Europe for banking, insurance and the public sector. My job: turning business requirements into consistent, accessible interfaces, and leaving a system and processes the team could keep running without me.
- My role
- Design systems, UX quality and process · Senior UI Solutions Developer
- Period
- April 2019 – July 2025
- Teams
- Scrum, international, cross-functional
- Sectors
- Banking · Insurance · Public sector
Recreation of a component catalog page for a fictitious brand. It shows the Button component page with its four states (default, hover, focus and disabled), a text field in default, error and disabled states, the style guide with the brand's colours and typography, and two best practices: “Do” and “Don't”.
The context
Many teams, many countries, one interface.
For more than six years I worked on Pegasystems projects for banks, insurers and public bodies across Europe. They were large, critical applications, built by international teams that brought together business, architecture and development profiles.
The challenge wasn't just designing one screen well. It was making screen number one hundred still look like the first one, even if someone else had built it, in another country, months later.
UI came too late
It was considered at the end of development, when changing it was expensive.
Everyone their own way
With no written criteria, each person solved the same problem differently.
Knowledge walked away
When someone changed projects, their decisions were lost.
How we worked
Inside the team, not at the end of the line.
- Planning
- Sprint
- Demo
Scrum, sprint by sprint
Almost every project ran on Scrum. I estimated stories and, depending on the project, also wrote stories and acceptance criteria for the UI side.
From requirements to interface
I worked with business architects, UX designers and developers to turn requirements into consistent, accessible interfaces, and sometimes directly with the client.
Audits and proposals
On some projects my role was to assess the existing interface, spot problems and present stakeholders and teams with findings and improvement proposals.
Demos that teach
I demoed the component catalog and best practices to development teams, and supported the rest of the team in their demos.
What I did
Bringing the team what it was missing.
1 · Component catalog
On every project I created a component catalog: a reference page with the reusable components, the style guide adapted to the client's brand and the best practices for creating new pieces without breaking what already existed.
2 · Tailored standards
I defined standards and components based on each client's needs: accessibility, responsive design and branding. The system grew with the project, not against it.
3 · Training and processes
I trained development and business colleagues in UI/UX best practices and helped make sure the interface was considered from day one, not at the end.
Before
- Business
- Development
- UI at the end
The interface got a “makeover” when almost everything was already built. Fixing it took time and every team ended up with its own version.
After
- UI from day 1
- Components
- Living guide
UI was part of the conversation from the start, with ready-made pieces and written criteria anyone on the team could consult.
The result
Projects that stayed consistent without me.
- +20enterprise projects across Europe
- +20international Scrum teams
- 1component catalog per project
- Across 20+ projects, teams could create new screens by consulting the component catalog, without depending on me.
- Less back-and-forth at the end of each delivery, because the UI was solved from the start.
- A shared language between design, development and business to talk about the interface.
- Processes that kept working as the team changed: onboarding someone new meant handing them the catalog, not repeating explanations.
What truly sets her apart is her ability to learn and adapt beyond the boundaries of her role, all while staying focused on meeting project goals.
What I take with me
Today I apply it to product.
Six years in Scrum teams taught me that a good product depends as much on process as on screens: clear requirements, shared criteria, honest audits and documentation that travels with the team. That's what I bring to Hithabit and Lab Beauty today, including making sure AI builds with your system, not against it.