Ushering a 120 year-old bank into its digital future
Overall design leadership
Experience strategy
User experience
Research
Design system
DesignOps
💡 Key takeaway #1
Using frameworks for practicality, scale, and impact
Don’t reinvent the wheel — we won’t have time for that.
(And, more cynically: the client isn’t paying us for that.)
That is the case for many client engagements with a fixed scope, where we are bound by assumptions in the initial scope of work, and by the short runway of time we will have to deliver it.
Within these constraints, here are some examples of how I led the maintenance of cohesion, structure, and consistency across the multi-year program.
Setting up design documents and checklists
My love affair with Notion continues as we used this as our source of truth, with decision captures.
Equally important, to scale up best practices and the right design culture within a team, we established these guard rails to ensure quality of the shipped products.
↑ Above: A snapshot of how we organized our shared brain, allowing for ease of reference and transparency across the teams
I took my learnings from projects past, about documentation and ensuring that they are communicated to the cross-functional team to heart. This documentation also make sure that:
Consensus is captured around the experience we're delivering
Knowledge is scaled across the entire team
Organizational memory is kept for these actions and decisions
The power of intra-team communications absolutely cannot be understated in a massive program, and it took some experimentation to figure out the right cadence, volume, and tone.
Every factor of a heuristic evaluation analysis, systemized
With 13 different BPI sites and 80+ journeys across both desktop and mobile devices to assess in 3 weeks, we were in for a wild ride.
The setup started with identifying the metrics for the framework, which spans across four different categories.
These would add trackable and quantifiable rigour through the design process, and give a comparative view across both internal and external lenses.
(Time travel to the present: we did the same assessment to track the improvements after the site was launched!)
↓ Below: Spreadsheets and components galore!
In order to quickly scale up to the rest of the team involved in this exercise, I set up Excel sheets with formula that would help to calculate scores and give an aggregated numerical output for each section of the categories, making it a breeze (or at least not so much of a chore) for the team members who are doing the auditing.
Finally, when it came to communicating our findings, components were set up in Figma to allow for easy editing and updating of findings across the different sites.
Anchoring experience principles to archetypes and journeys
I implemented the frame for standardized journey phases through the anchor of experience principles and what they mean for archetypes.
This allowed us to identify distinct moments that matter and opportunities, but still around a sense of familiarity and scalability so that the client team could also easily distribute it to the rest of their business.
↓ Below: A glimpse of how we systemized the journeys for three of the archetypes, and identifying the customer lifetime value that can be unlocked along their entire relationships with the bank
Design system: curation vs. creation
Building a design system from scratch was going to take us weeks upon weeks.
But what if our starting point was curation and adaptation, from the accelerator we’d built in anticipation for such a scenario?
The time and effort savings are so monumental, and we bought the time to explore more on the visual language, testing the concepts with the clients across the main and sub-brands, and allocated some of our team members to support in other activities like IA testing.
You can see more about how we’ve set up the Xcelerator in its own case study.
↓ Below: A look at the engine of the design system, from foundations to how they translate into coded fragments, and guidelines to allow for better onboarding of the design process for anyone in the team
Communicating purpose through systemizing covers
As the chosen tool to communicate our designs not just with clients but internally with our cross-functional teams, we needed a way to quickly see at a glance which Figma file was the right one.
This was also a time before Dev Mode, and we needed a separate file for developers to pick up our design and documentations, along with the design system annotations.
↑ Above: Figma covers, with multiple boards for external reviews, internal connects, cross-functional working boards, and archive boards capturing the changes over time
💡 Key takeaway #2
Connection: The key to leadership in times of turbulence
This was a challenging engagement, and not just because of the delivery aspects.
Sure, there were the usual teething pains: Trying to figure out workflows with the cross-functional team; having to evangelize experience and design, and the perennial problem of timelines that squeezed the team relentlessly.
The superpower of intra-team cohesion
Our weapon lies in our routines and rituals. With two-week long sprints and design being ahead by a sprint, we had some coordinating to do.
Daily stand-ups
At the start of each day, to align priorities and address roadblocks
Design reviews
Synchronous meetings for designers and researchers to review experience-specific areas (e.g. user flows, design options)
Design x Tech sessions
Synchronous meetings for in-depth discussions, validation, and sharing design's progress for what is coming up in their next sprint
Office hours
I set aside an hour each day for anything urgent that needed faster decision making than our synchronous meetings allowed
One-on-ones
I organized them with design, and my counterparts in product, engineering and program to make sure we bring issues up often and quickly
↑ Above: Blue for cross-functional meetings; green for design-specific rituals, and red for client sessions
We also fully embraced asynchronous feedback, using Figma and Teams as our medium, especially for smaller questions and quicker clarifications.
This goes multiple ways — from designers to developers, from content strategists to designers, and from developers to product, for example.
Adapting leadership and team styles
When half our team was let go mid-project, we had to quickly reassess and redistribute workloads.
In this new player-coach role, I found myself stretching on work, leading the team through design management and ops to ensure the quality of work, to doing the actual deliverables for both design and research.
Maintaining lines of communications was my priority — I was effectively the most senior member of the team as my own manager had been affected.
I stepped up as the director, seeking clarity from leadership about why the organization restructure had to happen (and at this time!), and putting in feedback loops for the team to make them feel safe and comfortable sharing their concerns (there were a lot), without negative consequences.
Maintaining morale and motivation
Celebrating milestones and resiliency
As the project closed, we made sure our gratitude and appreciation for the team members who were leaving was felt.
Managing expectations
With members of our cross-functional team who sat in other locations and weren't affected by the locus of the layoffs, and with clients. This is done through contingency planning and risk mitigation, while maintaining some level of productivity that would still allow us to deliver the quality we are known for.
Ramping up team check points
I had tighter sessions of one-on-ones to unpack the impact, both mentally and to the workload from the team departing and the people who are staying.
Some reflections:
At the end of the day — I am the one thing in life I can control.
Beyond applying empathy and patience in these situations, the management and leadership lessons I’ve learned can’t be distilled down to platitudes.
These were hard lessons: of motivation, depression, injustice, and the need to still lead what was left of the team through the turbulence.
I also had to reach back to my leadership principles at moments, to really guide me to the decisions I made — should I weigh the delivery priority more and maintain quality, or allow the team to take off more time than management expected? How do I embody persistence in these trying times, and not sink into my own pessimism?
This chapter in our team’s story is marked with both tears and triumph, and something that will always remind me of our resilience and compassion.