FUND. GRUPO SOCIAL
I redesigned the internal knowledge management portal of Fundación Grupo Social, transforming an unusable system with no real architecture into a WCAG 2.1 Level AA-accessible platform — the highest compliance decision the client made based on my work — centralised for the bank's 5,000+ employees.
The Centro del Saber portal had years of growth without design rationale or architecture: information scattered across 5+ locations, a useless search engine, links indistinguishable from plain text, and real operational risk in a banking context.
Redesign the portal to centralise 5,000+ employees in a single access point, with information architecture based on how users think and WCAG 2.1 AA accessibility as a non-negotiable standard.
4 interviews + inception UX workshop + actor map → Customer Journey Map + MoSCoW → UI design in Adobe XD with macro-process IA and WCAG 2.1 AA patterns from day one.
Client implemented WCAG 2.1 Level AA as the platform standard — compliance with MinTIC Resolution 1519/2020. Portal centralised for 5,000+ bank employees, approved by Product Owners and taken to implementation.
The Centro del Saber Portal was the mandatory access point for all bank employees to reach the regulatory and operational information they needed to do their jobs. The problem was that the portal had grown for years without design rationale or information architecture: information was scattered across multiple locations without consistent naming, the internal search engine was practically useless, and the design didn't visually distinguish links from plain text. Employees had developed their own workarounds — bookmarking pages in their browser, using Chrome's search instead of the portal's, asking colleagues directly — just to get their work done.
The outcome was predictable: every query that should take seconds took minutes. The informality in communication processes generated a critical level of 'meeting-itis' — people preferred to ask directly rather than navigate the portal. Duplicated and outdated information created real regulatory confusion at service points. And technical restrictions (only Chrome and Microsoft Edge approved for security) effectively excluded employees without access to those browsers.
The business risk was real: a bank operates on regulatory compliance. If employees can't efficiently consult the correct procedures, the operational and regulatory risk is direct. A knowledge portal that nobody effectively uses isn't a UX problem — it's a risk management problem.
- Inception, design and delivery process over approximately 8 months
- Solo UX/UI at Intergrupo; benchmarking and sketching removed from scope by client agreement due to time constraints
- Key stakeholders: bank Product Owners; Marco (client-side project lead); Centro del Saber content managers
- Microsoft technical infrastructure; access restricted to Chrome and MS Edge only; high risk of duplicated content, no naming standards and documents nested inside other documents
Fundación Grupo Social employees needed to consult regulatory and operational information in the Centro del Saber Portal autonomously and efficiently during their working day — instead of relying on colleagues, external search engines or browser bookmarks to compensate for the system's failures.
The system made it hard: the portal was technically functional but experientially broken — no information architecture based on how users think, no usable search engine, no visual hierarchy and no content organisation criteria.
I conducted 4 interviews with users from different profiles and built an actor map to visualise the relationships between those who produce content and those who consume it. The most compelling finding was that the browser search workaround was universal: all users had accepted the system was broken and developed their own ways to survive it. According to Coveo's 2022 report, employees spend on average 3.6 hours a day searching for information — 40% more than in 2021. With a search engine no user was using and information scattered across up to 5 different locations, the bank was absorbing that productivity loss systemically.
| Indicator | Data |
|---|---|
| Users using the portal search engine | 0 of 4 interviewees — all used the browser search engine instead |
| Different consultation locations per user | Up to 5 different sites to find information from the same system |
| Risk level of duplicated or unstandarised content | Critical — documents with different names for the same content; files nested inside other files |
| Browser-based access restriction | Only Chrome and MS Edge approved for security — de facto exclusion of employees without those browsers |
| Users who felt 'lost' in the portal | Common pattern in 3 of 4 interviews |
Built from real behaviour patterns observed in the 4 interviews and actor map — not from client assumptions.
Asesor Integral
Long company tenure. Uses the portal multiple times a day to consult regulations, manuals and formats during client service. Has developed personal workarounds to survive the current portal.
Find the correct, up-to-date information in seconds. A search engine that works like Google.
Gestor de Formación
Advanced knowledge of the portal structure. Manages training processes for other colleagues. Knows where information is but recognises the navigation is complex.
Total centralisation in one single place. Related content visible together. Cleaner navigation that can be taught to others.
Gestor de Contenidos
Responsible for loading and updating portal content. Faces the lack of naming standards and duplicated information problem from the creator's side.
Clear macro-process structure. Defined organisation criteria. Traceability of who publishes what.
Colaborador Ocasional
Accesses the portal when they need to resolve a specific situation (returns, formats, new processes). Values the portal but uses it as an intuitive expert, not a regular user.
Fast access by content type. Summary of latest updates. Video tutorials integrated with the content.
Inception UX workshop with stakeholders — externalising assumptions before validating
I facilitated a co-creation workshop with the client team to align objectives, capture risks and document the challenges to solve. What I found: the client underestimated the informality level in consultation processes and didn't have clarity on who the actual actors influencing portal content were. Key decision: run the workshop before the interviews, not after — so the client's assumptions were documented before being confronted with user reality.
Interviews and actor map — listening before proposing
I conducted 4 interviews with users from different profiles and built an actor map to visualise the relationships between content producers and consumers. The most compelling finding: the browser search workaround was universal — all users had accepted the system was broken and built their own survival strategies. Key decision: start by listening because the client already had ideas about what needed to change — my job was to separate their hypotheses from real user needs.
Personas + User Centre Design Canvas — aligning the solution to real needs
I built 4 user profiles based on real behaviour patterns observed in the interviews, and facilitated a User Centre Design Canvas workshop with stakeholders to align the solution proposal around identified needs. I used the UCDC because it combines the user and business perspectives in a single artefact — allowing more concrete prioritisation conversations with the client without leaving the people-centred design frame.
MoSCoW prioritisation + Customer Journey Map — what to build and how it's lived
I facilitated a MoSCoW Matrix prioritisation exercise to define which features went into the MVP and which were deferred. In parallel, I built the Customer Journey Map of the full consultation process — from when the employee detects an information need to when they find (or fail to find) what they're looking for. This dual perspective — what to build and how it's experienced — was the basis for the new information architecture design.
UI design and prototyping — accessibility as a decision, not a final review
I designed the interface proposal in Adobe XD focused on: information architecture organised by organisational macro-processes, functional search engine as the central navigation element, clear visual hierarchy between content types, an update notification system, and WCAG 2.1 AA accessibility patterns from the very start of the process — not as a final review layer. Key decision: propose WCAG 2.1 AA as the platform standard before the client asked for it. MinTIC Resolution 1519/2020 had required it since January 2022 for the banking sector. The design process was the trigger for the client to make that decision.
There is no formal quantitative adoption metric — the design was delivered to Product Owners on 2 June 2023 and moved to development. The most concrete result is a decision the team made based on my work.
- From non-functional internal search engine (0/4 users used it) to search as the central experience element with macro-process information architecture
- From information scattered across up to 5 different locations per user to centralisation in a single consultation portal for 5,000+ employees
- From portal with no accessibility criteria to WCAG 2.1 Level AA implementation as the platform standard — fulfilling MinTIC Resolution 1519/2020
- From design with no visual hierarchy (links indistinguishable from plain text) to a design system with clear visual patterns and defined interaction states
- From duplicated content with no naming standards to a content architecture with defined organisation criteria as a development prerequisite
The design was approved by the client's Product Owners and moved to development. The platform was implemented for the bank's entire workforce.
I'd have insisted on keeping the benchmarking and sketching exercise within scope, even done lightly. They were removed by time constraints agreed with the client, but they're two activities that would have enriched the proposal with external references and generated earlier team alignment around the visual direction.
The bank's security restrictions limited portal access to Chrome and Microsoft Edge only. That constraint fell outside the design scope — it's not a UX decision but a corporate security policy. But from the user's perspective it's a real, persistent friction: if you don't have access to those browsers, the portal simply doesn't exist for you. Designing systems that depend on constraints you can't change is one of the most common tensions in corporate design contexts, and it doesn't always have a solution within the project.
Due to contractual and confidentiality conditions with Fundación Grupo Social, original platform screenshots are not shown. The images are approximate representations for illustrative purposes.
