'Track Payments'

Issue the business needed help with (i.e. main users’ pain points):

• The statuses of payments were unclear to customers
• This was leading to a large number of queries to the bank
  • with their associated costs
  • and reputational risk (customer satisfaction)

Issues with the product:

• The MVP version of the tracker had been developed but was lacking integration with the rest of the payment ecosystem.
• The tracker also needed to support more statuses (integration with other payment systems) and to enable users to track their payments end-to-end.
• The MVP product wasn’t integrated with the mobile solution at all.
• It also needed to be localised for various markets.

Issue

After I joined the project, the Technical Architect and dev team managed to integrate more payment data sources and API. This meant we could add many more statuses to the product.

Those statuses originated either from:

• a better (more granular) tracking of internal statuses bringing more visibility on what was happening to a payment before it was sent to its beneficiary.
• or from a more end-to-end tracking capability (SWIFT-GPI integration) allowing more visibility on what happened to a payment once it has left the bank.

They needed to be integrated into the product, but not “as-is”, as they were too technical for the end-users.

Action

• Identified and grouped low-level statuses that could be translated into the same “usable” status.
• Introduced a static 5-step timeline for the tracker (unified high-level milestones applicable to any payment)
• Worked closely with the PO, and copywriters to define the various statuses to serve to the customers and the associated details to be displayed with each of them. Many iterations with the Legal & Compliance team.
• Created a table matching every “canonical” status with the associated copy to be displayed to the customer.
• This table became the single source of truth for BA and the dev team.

Result

• Simplified the tracker (high-level milestones): allowed a better understanding of the payment process at glance, rather than displaying all steps in a dynamic timeline (ending with an unpredictable number of steps).
• Simplified and rationalised all detailed statuses
• Ensured we gave more clarity on the statuses while still complying with L&C guidance, i.e. not revealing too much (e.g. fraud or sanction screening), or being too optimistic about the payment processing that could lead to a reputational risk for the bank (e.g. if a payment ended in an edge case scenario - delay/cancellation - and didn’t match with the status displayed to the customer).

Kudos from the Global Head of Corporate and Institutional Digital:

“I wanted to update you on the fantastic achievements we have made through the Digital Transformation for Corporates (DTC) programme in the first half of this year [...] delivery continues to be impressive: [...]

• Move Money is almost fully deployed and being used by more than 130,000 clients in 53 countries. It is now branded HSBCnet Payments and Transfers.
• Track Payments is enabling more than 82,000 clients in 41 markets to check on the status of their payments – including when funds have reached a beneficiary outside our group - thanks to the integration of SWIFT gpi tracking. Congratulations to the team for more than doubling their end-Q2 client deployment targets. [...]”

The MVP could mostly track one type of payment “Priority Payments”.

To make the product more relevant, we started integrating more payment types, for instance:

• single payments going to multiple beneficiaries
• or variations of a given payment when addressing different markets (e.g. SEPA in the EU)
• or payments having been initiated through different channels (e.g. automated vs. manual)

Issue

New payment types didn’t align with the existing ones.

Action

• We adapted the existing tables of payments and aligned the associated filter/search capabilities to cater for those “batch” payments (with a single debit but multiple beneficiaries).
• Also adapted the payment details page to indicate further limitations of the tracker (originally TP couldn’t track individual payments within a batch)
• Integrated new types in the Mobile experience.
• Built a prototype and tested the understanding by end-users

Result

• Integrated new payment types, using a “template” approach - allowing for future types to be added in the future.
• Aligned even more the mobile to the desktop experience.
• Discovered some usability issues and status misunderstandings (copywriting) through research. Prioritised and fixed the issues.

Translation work (NLS)

The product was part of a global banking solution.

We worked with various teams to enable Native Language Support, i.e. translating our copy for various markets

• The nuances between the statuses could be delicate to understand for translators with limited knowledge of the industry. There were also all the L&C implications described earlier to take into account, so we supported them by providing context, and examples and answering their questions.
• I also reviewed and iterated on some of the translated copy for markets with a french speaking audience.

Overall localisation

Because we were working on a multilingual product, we collaborated with the global design and tech teams to ensure:

• our UI elements and layouts adapted well to various languages (responsive components with limited horizontal space, etc).
• we made sure the components that needed to be were correctly internationalised (amount, currencies, calendars, date pickers etc.)

Definition of the Right-To-Left version of our product

We defined the RTL version of the tracker following the bank design guidelines on that topic. In doing so, we encountered a few issues that weren’t covered by the guidelines. We solved them and shared our findings with the governance team so they could be added to the design system and benefit all.

At the time I moved to Track Payment (from another banking project with the same client), the overall design system of the bank started to be more mature: visual toolkits, integrating brand elements, copywriting guidelines, etc.

Issue

Unfortunately, the product we inherited wasn’t aligned with the rest of the ecosystem. There were various reasons:

• the previous designers were more in an exploration mindset
• the previous POs wanted to get buy-in from other stakeholders on this product. So they had pushed for visually appealing components rather than ones conforming with the existing toolkits.
• It had been designed and developed in total isolation from the rest of the teams

Action

• We worked very closely with the “Digital Design” leadership team to align our designs with the evolving ‘desktop’ patterns.
• We pushed for some TP components to integrate the Design System in the future (added in the components incubator).
• Mobile: as detailed in the Mobile section below, we produced concepts for our mobile tracker in a totally different work stream than the existing corporate banking mobile app. As a consequence, our components were more modern, accessible and in line with the recent ‘desktop’ design system.

Results

• A desktop experience fully aligned with the corporate banking Design System.
• Our components and feedback featured in the Design toolkit
• Many of our mobile components and patterns were reused as a baseline for a brand-new design toolkit for Mobile.

Issue

As the tracker we inherited was more of a concept, it was only partially connected to the rest of the banking platform.

Actions

We worked with the PO and other POs to make sure the experience was designed as an integrated workflow, for example:

• integration with the team owning the “Notifications” (what payment statuses should be surfaced to customers; how notifications should connect to our tracker, or propose next best actions, etc)
• integration with the team working on the overarching solution landing page: adding a “payment summary” module to the future dashboard.
• integration with various Payment teams, to ensure the users could:
  • navigate between the tracker and the payments,
  • perform repair actions on the payment itself or on related accounts, etc.
• mobile app integration: in large corporations, some senior employees need to approve certain payments (e.g. amounts above a threshold). These user types needed to be able to locate and act on payments from their mobile app.

Result

Doing so, our product got a lot more visible in the banking ecosystem. It also became an improved solution for our users (e.g. integrated into the flow: checking corporate accounts, making complex payments, tracking and managing my payments, providing reports to managers/suppliers/employees, etc.)

• Worked with a third-party company checking our tracker was WCAG level AA compliant, as required from all of the bank’s solutions. Reviewed the report, and requested clarifications when needed.
• Partnered with a developer specialising in accessibility to address the issues identified by the assessor (Aria descriptions, tab order, managing tables for keyboard users, etc).
• For any remaining issues, checked with the accessibility expert (employed by the bank) whether they needed rework.
• Attended ‘accessibility days’ organised by the bank: met and shared experiences with a panel of disabled users (motor, cognitive, auditory, visual impairments) to understand how proper solutions (design and implementation) made their life easier - by enabling a positive experience of various digital services.
• Worked with other designers on a template for UXers to embed more accessibility requirements in their specifications (e.g. shortcut definition, tab order for complex components, etc.)

Worked with the analytics team:

• Identified which UI elements were worth tracking via analytics (the bank was using Adobe solutions)
• Provided inputs for the Analytics Brief and Tag Specification docs

Working with User research consultants, my tasks included:

• Outlining the key research objectives
• Building an advanced Axure prototype of the payment tracker
  • The prototype included realistic data that could be filtered, searched, and navigated though
  • It was tailored for the user testing sessions and adjusted daily when required

• Reworking the discussion guide: scenarios and tasks to go through, potential prompts, etc.
• Attended most sessions (remote moderated testing). During those, I sent extra questions to the Researcher when needed.
• Reviewed and validated the report
• Prioritised the uncovered issues or topics to address with the PO, Researchers, and designers.
• Grouped them by product areas and proposed solutions

Because we had more budget at the time, we even had the “luxury” to perform some discovery work on related products or journeys (example of journey: creating many payments in one go through “File” upload).

We briefed the Research consultancy so they conducted interviews with existing users, understanding their tasks, behaviours and expectations regarding uploading a payment ‘file’ and how these users would expect or need to track such payments.

I helped the researchers with the following tasks:

• Recruitment brief: helped them define the right people to interview
• Outlining the key research questions
• Reviewing and iterating on the interview question list

We got some insight into how the users were working with the current solutions. As with any interview-only research, there were limitations. Further work was planned so a concept design covering the upload and tracking journeys could be reviewed with users.

Issue no 1: a false start with WeChat

Issue no 2: an outdated toolkit - mobile app

Action and result

Supported and led the work on related workstreams (automated payments tracker, authorisation flows, etc.)

• Designed early concepts and proposing general design direction
• Managed a team of remote designers (remote UX and VD in India) who produced detailed flows and specifications. I reviewed their work, provided feedback, ensued they followed the bank’s design process.

Integrated the new tracker in the overall solution – Desktop and mobile

First bank allowing end-to-end tracking

Foundation for a mobile design toolkit