ATB Financial
TMC: Banner Tool
Role
Product design lead
Duration
Q2, 2024
Create a feature for the ATB Business internal tool allowing non-developer team members to deploy banners to the ATB Business production site and app.
ATB's internal console for its ATB Business platform utilizes site and mobile banners to notify its user base of upcoming changes and other important information. These banners required developer action in order to implement, making them expensive and annoying to implement. This project was intended to democratize the banner-creation process, allowing product managers the ability to create, schedule, and deploy banners to the live web and mobile sites.
The first question that we asked ourselves was: how can we make this a great experience with the scope that is available to us? Our development resources were slim—one student developer for the entirety of the project (and an additional senior developer to support when necessary)—so we wanted to be careful to avoid scope creep.
We quickly identified the primary "functionality pillars" required to make the feature work well.
The ability to create banners (immediate)
The ability to create and schedule future banners
The ability to edit scheduled or live banners without removing them from the production site
The ability to cancel live and scheduled banners
The ability to view all live, scheduled, and expired or cancelled banners
We also needed to allow users to choose what kind of banner would be installed. Outages required "warning" banners, while expected statutory holiday affected hours would need "informational" banners to remain informationally appropriate.
Finally, we also wanted to allow the administrative team member to be able to choose which platform the banner would appear on. In our mind, (i.e.) mobile-specific issues would require mobile-specific banners, and likewise for web.
As a "for future considerations" note, we hoped to expand the functionality of the site to allow specific feature-related notes to only appear for users who utilized those features, though this was determined to be out of scope.
The look and feel of the site had already been established, but there wasn't existing infrastructure in place to build the features that we had identified as necessary for the project to succeed.
We settled on a modal approach to the banner creation as opposed to inputting the information on its own page. I believed this to be the most effective approach as modals were already a well-established pattern within the site, especially when changing permissions or adding entitlements to user profiles.
Putting together a few rough ideas for how a modal might play out. Typically I would sketch out a few diverse approaches before beginning the ideation phase of design, but technical constraints limited us to a modal approach, so I stuck with that.
High-fidelity design overview page
First, we began by finalizing the "overview page" for the new feature. This page was key and required the user to be able to create a new banner as well as edit and cancel existing banners. For auditing purposes, we also included a history section for all previously created banners.
I separated the page into three main sections for easy . The first, "Active banner" would include any live banners currently featured on the production site. We identified an edge case that might arise that helped inform this design: banners would also possess "emergency" or "standard" attributes. Emergency banners would include outages, fraud concerns, technical failures, or other critical communications. These banners, when created, would automatically override standard banners.
I opted to include both banners in the "live" section of the page as, once the emergency banner has been removed, the previously scheduled standard banner would resume on the live site.
The "Scheduled banner" section housed all upcoming banners not currently live on the site. These could be scheduled months in advance, helping the product team account for planned feature outages, statutory holidays, and other planned disruptions to service.
The final section was the "Activity log" that included information relating to previous banners. We opted to include:
The status of the banner (e.g. active, cancelled, expired, etc.)
The date that the banner was created
The user that created the banner
The banner's type
A description of the most recent activity related to the banner (e.g. banner was cancelled, banner expired, banner scheduled dates were updated).
High-fidelity modals design
Next, I designed the modals. There were a few interesting scenarios to capture. Some banners would feature a CTA button, prompting the user to visit a page on ATB's website. Others, based on our design system, would use a button to open a separate modal displaying additional information to the user. The banner modal needed to capture these use cases without becoming too complex.
The standard use case, or typical happy path, would only require copy for the banner to be written. With this in mind, I set the modal to have the following default fields:
Banner type. This would allow the user to change the banner setting to "Emergency (immediate and overrides already-live banners) or "Scheduled" which would not be immediately implemented and would be set based on the scheduled date.
Banner colour. This allowed the user change the "tone" of the banner (e.g. orange for errors or outages or blue for non-emergency updates, etc.)
Banner title (internal). This was a requirement for internal auditing purposes, allowing us to set naming criteria for easy searchability so that we would be able to pull previous banner history should we need to down the line.
Scheduled date (from) and Scheduled date (to): Allows the user to set the timeline for the banner
Hide on platform: Allows the user to select which platform they wish to have the banner appear on, whether mobile, web, or both.
Banner message: The freeform text field where the user could set the to-be-displayed banner text.
Everything that followed those standard fields was considered an edge case, but we still needed it to work well. The most difficult part of this design process was creating a design pattern that made semantic sense when it came to expanding the modal to accommodate additional information. For example: we needed to add a button, but the button might lead to one of two outcomes, with additional varying outcomes arising from the initial decision. Based on our internal design library, I felt that it made the most sense to use radio buttons to indicate this choice. I felt that users could easily switch between the two to better understand the options available to them with each choice.
Balancing the component use within the modal was also key. Tertiary buttons became central to "unlocking" additional options within the modal (i.e. "Add/Remove banner button" and "Add/Remove modal button." In retrospect, I think that the choice to user tertiary buttons rather than a simple accordion chevron made sense as it aligned with common patterns within our design library.
Though the modal grew to be quite large if the user selected every option available to them, early conversations with potential users helped me determine that a simple divider line between the standard fields and the "additional" fields helped the user parse the information more easily.
The Banner Tool was a fun challenge that allowed me to improve my ability to balance a variety of technical constraints with attempting to create a product where its userbase was the team that I worked with every day. It was also enjoyable to be in a position to provide a designer's perspective to two new team members who were only just beginning their careers in technology, and I learned a lot working with them.
The Banner Tool feature was launched after two months of ideation, design, and development work. As of January 2025 (1.5 years after deployment) the Banner Tool had been used to create 150+ banners for ATB Business, saving approximately 40-70 hours of developer time over that period.