A CMS for the Banking Sector: 7 Lessons from 20 Years of Implementing Banking Portals

In 2020, we celebrated 20 years of cooperation between e-point SA and ING Bank Śląski that revolved around the bank's portal, www.ing.pl.

The project catalyzed the development of our original platform, e-point CMS . At the same time, it opened the door to many other implementations in the financial sector, including www.santander.pl, www.bnpparibas.pl, www.pzu.pl, and www.nntfi.pl. This anniversary has inspired us to share key takeaways from these projects.

1. User Journeys Start with Google.

Back in the 1990s, banking websites were used to showcase status – with no immediate impact on the sales process. Frequently, the PR department owned the project. The ultimate goal then was ensuring that non-technical  marketing or PR staff could easily edit the portal.  

A real breakthrough happened with the rise of Google. Online presence became a business must-have. Since then, Google algorithms have been driving the evolution of CMS-class systems. 

The change is largely about understanding portal architecture. A user’s journey began with Google search results, after which they hit the selected website or portal section and skipped the main site. In the eyes of the user, every sub-site automatically became the "main site" of the portal; as such, it required steady attention from designers and editors.  

The situation revolutionized our CMS platform in a number of ways.  First, we extended it by introducing an advanced page builder tool that allowed editors to create appealing messages on web pages. Thanks to it, editors could deliver a top-notch customer experience on mobile as well as desktop, which ultimately affects positioning. (Google has a set of metrics called UX Signals that are used to assess websites on their transparency to the user and how the sites drive user actions.)  

Simultaneously, a CMS platform became the tool used to combine particular websites and portal sections into a coherent whole. This had to be based on clear navigation, which makes it easier for Google web crawlers to freely move around the portal. In turn, this helps Google optimize portal indexing and present it in search results. 

CMS supports SEO and positioning also via other tools, such as:

• Aliases. 
• Friendly URLs (i.e. web addresses that are easy for people to read). 
• Meta-tag editing. 
• A/B tests. 

In the coming years, Google will continue to define the evolution of banking portal trends and CMS growth. Keep an eye on enhanced mobile support via PWA technologies, content personalization, and voice channel support; these will be increasingly important in the future. 

2. Editors Should Exercise Full Control Over Content and Zero Control Over Form.

Over time, banks' former ‘online shop windows’ evolved into huge portals comprising thousands of pages and managed by large teams of editors. Today, a bank’s CMS must give editors full control over the content published, with support for: 

• Particular types of content – such as search engines, ATM or location maps, currency exchange rates, and stock exchange listings – all supported with dedicated modules. 
• Other data formats – such as videos, rules, and regulations in the form of downloadable files – supported by a Digital Asset Management module. 
• Website versioning. Information published on banking portals can significantly affect the financial decisions made by clients. This aspect is closely overseen by a financial supervision authority. Consequently, a CMS must support website versioning so that when a complaint is lodged, the information the client specifically accessed can be easily verified. 
• Strong authentication for portal editors and a two-factor approval of their actions. This is to effectively mitigate the risk of publishing unauthorized information.

It should be also borne in mind that financial institutions are conglomerates of various business models, structures, and companies. Thus, marketing teams must be able to independently launch various digital initiatives – such as portals for companies owned by a group or mini-services on different themes, landing pages, or campaigns – without the help of IT.   

In a traditional CMS, the basic mechanism for content creation was the text editor, which allowed basic content pasting and formatting. However, while entering or editing content, editors frequently failed to obey UX guidelines. In an effort to respond to immediate needs, they created their own content structures and conventions. As a result, after a portal had been launched and put in the hands of editors, it usually suffered rapid aesthetic degradation, becoming chaotic and incoherent.  

We solved this problem by extending the content management system with a mechanism for user interface componentization. Components are small visual widgets used for designing websites. They impose a visual form for a particular type of content – one that’s uniform across the entire service. Examples of components include:

• Page titles 
• Paragraphs 
• Article lists
• Carousels
• Tabs
• Calculators and other tools.

A standard implementation includes several dozen components that are configured for a specific website by entering content or specifying its source, as shown in the video below: 

*Active Content is now called e-point CMS

Currently, a CMS implementation involves first of all styling the existing components or preparing new ones as provided by the UX/UI design.  Components constitute a technical implementation of design systems. As a result of component implementation, editors have been deprived of their freedom to determine message form; however, overall the portal is more visually consistent and its user experience is taken to a whole new level.    

3.  Content Is What Makes a Portal Meaningful, So Content Must Be Meaningful. 

In many portal pitches, we see clients focusing on the technological dimension – looking for a supplier who will implement a versatile platform allowing for independent website content management by editors with no technical background.  Initially, hardly anyone seems to care if the supplier can provide support while designing a meaningful and clear information architecture (including a precisely tailored navigation system that matches customer needs).

Actually, it is content that poses the biggest project challenge and risk. Whether our users are able to find what they are looking for and whether they leave the portal with a sense of having received excellent customer service depends directly on their ability to understand the language we speak with them. The ultimate success of the implementation is predicated completely on the content.  

Thus, working with content must become an integral part of the portal design process. For the purpose of our projects, we have developed an original design process known as Content-Driven UX Design. These are its key elements: 

1. Before we create the website content containing the offer description, we collect thorough insights into our customer's business. We talk to experts, ask them questions and run interviews, visit outlets/points of sale to identify the real value proposition of the offering, and decide how to communicate its particular elements.
2. While designing any portal's model pages, we start from what we want to communicate and how we will reach and interact with the audience (as opposed to focusing solely on what standard components a CMS can offer).
3. We do not work on Lorem ipsum! While building mock-ups and graphic designs, we base the target copy on what should be said/shown in a given place. This makes it easier to select suitable forms of information presentation.
4. We understand that today a portal acts as a gateway to the purchasing processes. This holds true even for banking portals, so we make sure users are carefully prepped for purchase. 
5. Key words or phrases serve as a starting point for content design; these help position the site in Google’s (and other search engines’) search results. However, SEO concerns, key phrases, and text size should never override the importance of good user experience. We have always warned our clients to create content using plain, easily understandable language.  
6. We use the mobile-first approach. Starting with a small interface in mind generates synthetic thinking, good prioritization, and better content structure.  
7. As soon as the design of key websites and the portal structure have been completed, we try to make sure that the editing team complies with these standards in the future. We prepare instructions and manuals for clients on how to create content for particular types of sites; thus, the base we have worked out will be retained in the future. 

4. Start with Mobile  

Over 90% of users browse the Internet using mobile devices. Therefore, things which seemed to be passing fads (Responsive Web Design, or RWD) have become standard, irrelevant of whether we are building a portal, an e-commerce site, or a service system. Currently, it is a standard requirement to design portals so that websites will automatically adjust to the size of users’ screens – and will look good on that screen, as well.  

The small size of smartphone screens is the usual challenge: how can we present messages built for desktops on a small device screen in an accessible and intuitive way? Our approach is to work in reverse: We begin design work from the mobile perspective (i.e. mobile-first design). This method obliges us to prioritize the message and construct the story in a nutshell. On top of that, the following principles are held as good mobile design: 

• Limiting the number of scrolls to about 5. 
• Creating a suitable hierarchy of headlines for each "layer" of information. 
• Adjusting particular elements (e.g. a calculator) to the screen’s viewport (visible area). 

Mobile-first design poses some challenges to a CMS. First of all, a page builder must support RWD, i.e. it must allow users to structure websites to match the various devices’ resolutions. The very components used to create RWD sites must be customized for mobile – both in terms of appearance, readability, and the appropriate space between navigation elements as well as in terms of support for mobile-specific interactions (e.g. swipe). 

A CMS should also support: 

• Previewing QR code, which allows for scanning and verifying a draft copy on a physical device before the code is published.
• The possibility of configuring dedicated actions and displaying dedicated content in the mobile channel along with an operational system detection (e.g. banners encouraging the installation of applications for Android/iOS).
• Efficiency optimizations - e.g. picture size/resolution that can be adjusted for slow connections.

5. Portals Are Banks' E-Commerce Sites. 

The time when a website was just a bank's showcase is long gone. Today's expectations are for portals to be selling banking products. Even a very quick glance at a banking service’s navigation clearly indicates its function as a product catalogue, just like in e-commerce. The difference is that product pages are expanded and customized for each product. It flows from the fact that financial products are naturally complex and difficult to grasp; they require a particularly advanced form of communication.  

For the same reason, many products are accompanied by tools designed to facilitate a customer’s decision, such as financial calculators, product comparisons, creditworthiness analysis tools, repayment simulations, configurators, etc. Thus, a banking CMS is a platform within which numerous (or even several dozen) applications that offer total customer experience support are developed and implemented. Increasingly, such applications are designed in a microservice architecture and support the entire digital banking ecosystem.

As with e-commerce, conversion (usually obtaining a lead) is a key challenge for bank portals. Most frequently, this means a user filling out a suitable form – either a simple contact form or a more complex application that initiates a sales process. In this perspective, a banking CMS should provide a form engine allowing for the quick and flexible creation of forms for various campaigns.  

6.  Portal Content Is Consumed Across Many Channels.

Over time, banking portals have become the main, if not the only, user-friendly information hubs for outlining various financial institutions’ product ranges. As a result, it became necessary to use the data in other systems – mostly in online and mobile banking systems, front office systems, and call centers.