01. WHY WE STARTED
For a bank, the public website is not just a marketing tool. It is often the first point of contact for people trying to understand products, compare options, or complete important next steps.
In this case, the site had become difficult to navigate because different departments had been creating pages independently for years. Some teams produced polished pages, others published the bare minimum, and teams without designers often created content in whatever way they could. Over time, that led to a site that looked full, but did not work as a unit.
At first, the project was framed only as a CMS migration. But after looking closely at the site, I realized that simply moving the existing pages into a new platform would preserve the same usability problems.
02. THE CHALLENGE
We had to answer questions like:
Which pages were actually important?
Which ones were outdated, duplicated, or unnecessary?
How could we reduce inconsistency without creating something too rigid?
How could we create a system that worked for real content, real brand requirements, and real technical constraints?
This meant balancing clarity, business priorities, user needs, publishing process, and the limitations of the new CMS all at once.
03. MY APPROACH
I started by helping audit the site from both a user and business perspective.
500 pages
Analyzed using data
Together with my UX partner, I analyzed data from Google Analytics, existing traffic dashboards, and custom funnels created with support from data engineers.
We ranked pages by traffic and by business importance. That process revealed one of the biggest problems in the site: pages that should have been highly visible were getting far less traffic than expected, which pointed to a deeper navigation and information architecture issue.
We combined that quantitative analysis with qualitative input from user interviews
Users felt overwhelmed, and many preferred calling instead of browsing the site. We conducted 20 interviews with customers. This revealed a major disconnect between what the bank thought users needed and what users actually wanted.
Users weren’t reading because the content wasn’t designed for them, it was designed to satisfy internal teams.
04. MY ROLE
Redesigning meant aligning many departments with very different needs. With dozens of teams owning parts of the site, the redesign required extensive coordination. Each team had different goals, content types, and metrics to move.
My responsibilities were:
Analyzing the site's data
Defining the new architecture logic
Creating the UI component library
Aligning cross-functional teams
Delivering guidelines for future use
I also led recurring working sessions and workshops that brought together people from brand and communications, product stakeholders, the external technical provider, and our internal technical team.
Those sessions were important because the component system could not be created in isolation. I used them to pitch early design directions, test whether the components worked with real content, gather feedback from different teams, and make sure what I was proposing could support the bank’s needs.
05. UI STRATEGY
Components were designed to solve the needs of ~80% of pages.
The remaining 20% were edge cases and handled separately.
Trying to cover every exception would quickly recreate the fragmentation we were trying to eliminate.
06. KEY DECISIONS AND TRADEOFFS
1
Treat the project as a structural redesign, not just a migration
One of the biggest turning points was recognizing that the migration was a chance to fix the system, not just replicate it in a new CMS. If we had moved everything as-is, we would have preserved the same clutter and fragmentation in a new tool.
2
Use data to identify what mattered most
Because the site was so large, we could not treat every page equally. Reviewing analytics across 500+ pages helped us prioritize what deserved attention, identify pages that were underperforming despite their importance, and support decisions with evidence instead of opinion.
3
Standardize around one master template with flexible components
Instead of letting each team continue to build pages their own way, we created a model with one master page structure. Some freedom and visual variety had to be sacrificed, but the gain was much larger: a more coherent user experience, cleaner governance, and a system that teams could actually sustain over time.
4
Design for real publishing workflows, not just ideal screens
The component system was designed to help people know exactly what kind of content they needed to provide. That made the process more efficient and reduced ambiguity during page creation. It also made it easier to maintain quality.
07. WHAT CHANGED
User side
The website became easier to navigate, important pages became easier to reach, and the overall experience became more consistent. After launch, bounce rate dropped by 12%.
Business side
Dozens of outdated and duplicate pages were removed or merged, product pages were standardized through the component library, and the CMS supported a more controlled governance model.
08. WHY THIS CASE MATTERS
I am comfortable stepping into messy systems, using research and analytics to understand what is really happening, and then translating that complexity into structures that are clearer for both users and teams. In this case, the final output was a redesigned banking website, but the real work was creating alignment, reducing fragmentation, and building a system that could scale.