ScotiaMóvil Beta 1
The first native mobile app for Scotiabank Mexico, built with a six-person team, 70% less budget than the system it replaced, and shipped in six months. The channel nobody used became the primary transaction channel.
In 2017, Scotiabank Mexico ranked fifth in the country's digital banking rankings. The web channel had 300k active users but had been stagnant for a year. Mobile barely reached 175k. The phone was the channel with the most growth potential and the worst experience.
The root of the problem was technological. LEAP, the centralized system in Toronto, fed both the web and mobile channels for all Scotiabank countries. A small update could take months — or even years — because any change had to go through the global prioritization process.
The existing app was a hybrid: essentially a web container on top of LEAP. What users saw on their phone was, at its core, an adapted web experience with all the limitations that implied.
The challenge had two dimensions: technological independence — building our own middleware that connected the backend to the apps without depending on Toronto's release cycle — and experience independence — the window that opened to design from scratch, not adapt what already existed.
The web channel had gone a year without growing. Improvement efforts were trapped in Toronto's global prioritization cycle.
The channel with the greatest growth potential in 2017, underused because of a hybrid experience built on top of the centralized system's constraints.
Scotiabank was competing with the best available in the Mexican market without having the digital product that matched its size.
Before designing any screen, the team worked with two existing information sources. The first was quantitative: LEAP usage metrics showing the percentage of activity by function. The second was qualitative: findings from user interviews that a research team had already conducted to map pain points with the existing experience.
The combined finding was clear — and uncomfortable for some stakeholders.
The remaining 10% split between transfers to own accounts (5%), transfers to other banks (4%), and bill payments (1%). Users opened the app for one thing. Everything else practically didn't exist for them. That data became the central argument for the MVP scope.
Users had at least two accounts at different banks. They weren't power users, but they were actively comparing experiences. Scotiabank was competing with the best available without necessarily having it.
LEAP's authentication process (select image + verify security word) was perceived as complicated and illogical. The perception of security was low precisely because the mechanism seemed arbitrary.
The 30-minute wait to add a new destination account and the 200,000 peso transfer limit were friction points mentioned repeatedly and explicitly compared against other banks' conditions.
The design process at ScotiaMóvil was inseparable from the conversations around it. Interface design work was secondary to scope negotiation and technical alignment.
The initial position was to replicate LEAP but faster. The response was direct: LEAP has extensive functionality and 90% of usage is in three actions. If we build those three well and validate they work, the rest can come later.
The pushback was predictable: "what if the user needs X?" The answer was always the same: the data shows X happens in less than 5% of sessions. First let's validate the core.
Scotiabank's new design system was just getting started. Adoption was uneven and there were no global components in code. The strategy was to start with a local implementation during the first sprints, staying aligned with what was being developed globally. That let the development team build familiarity with the system without the pressure of a top-down rollout. ScotiaMóvil became one of the first products to adopt Canvas correctly and a reference for other countries.
The scope wasn't defined from scratch — it was defined from what users already did. The 80/20: the actions that represented more than 90% of real usage, designed in a way that invited exploring the rest.
Login · Token generator (e-Llave) · Branch locator · Contact · Terms and conditions
My accounts · Transfer · Pay (bills and credits) · Tiempo Aire · Profile · Contact
PFM · Personalization · Financial intelligence — excluded by infrastructure, not by lack of interest
Every design decision in ScotiaMóvil started from the same question: what does the user want to do right now? Not which category each function belongs to. Not which hierarchy corresponds to each section. What action they want to execute.
LEAP organized navigation as a hierarchical menu: My account > Transfers > Select destination. That was the standard banking model of the era.
The proposal was to reorganize around the question users are actually asking. The bottom bar exposes four direct actions: My accounts, Transfer, Pay, and Tiempo Aire. They're verbs, not sections. Intentions, not categories.
That reduced the cognitive distance between what users need and how they find it. The result was measurable: the transfer flow dropped from 45 seconds to under 20, validated in two rounds of user testing.
The login screen concentrated everything users need before authenticating into a single surface: branch locator access, direct contact, username field with the design system component, and the e-Llave generator integrated as a natural part of the flow.
e-Llave stopped being an additional step that interrupted the process and became part of the same entry gesture. Each element has a specific, necessary function. Nothing competes with the main task.
The post-login home prioritizes immediate contextual information: username, date and time of last access, and account list with balance visible directly.
Showing the balance directly, without an extra tap to reveal it, was a bet on trust. Users open the app to know how much they have. If that answer requires extra steps, the app has already failed at its most basic task.
The bottom bar reinforces transactional actions at all times so that transacting is always the shortest path, not the longest.
The most important decision about the home isn't what it shows — it's what it invites you to do.
The payment screen uses a contextual hero that explains the section's purpose before asking users to make any decision.
The choice between "Bill payment" and "Credit payment" is made with visual cards, not a text menu. The distinction reduces decision time and eliminates ambiguity about which action corresponds to each need.
ScotiaMóvil was one of the first products to adopt Canvas, Scotiabank's global design system, as the foundation of its interface. That had two concrete implications.
The first was speed. Having a working component system — typography, iconography, color, buttons, and text fields already defined — meant design time could go into the experience architecture, not redefining every visual element from scratch every sprint.
The second was scale. The native iOS and Android component work produced during the project could be shared with other Scotiabank countries through CanvasOps. ScotiaMóvil didn't just use the system — it contributed to it.
ScotiaMóvil proved that a small team with clear data can redefine an entire channel. The results weren't gradual: mobile went from the worst-experience channel to the preferred one for operating, displacing web for the first time.
| Metric | Result | Context |
|---|---|---|
| Build cost | $300K | vs. $2.3M for the LEAP system it replaced — 70% savings |
| Delivery time | 6 months | 12 sprints, 6-person team, iOS and Android simultaneously |
| Active users | +30% | Months after launch, mobile as the primary channel |
| Transfer time | < 20s | vs. 45-second average in LEAP — validated in user testing |
| Canvas adoption | Reference | First product to correctly adopt Canvas in Mexico — set the path for other countries |
The three decisions that most impacted the product — the MVP scope, Canvas adoption, and the exclusion of financial intelligence features — weren't resolved in Figma. They were resolved in conversations where the argument had to be sharper than the resistance. Data against intuition. Cost of doing it now against cost of doing it later. Usage evidence against feature lists.
I spent more time in those conversations than in front of any screen. And the product was better for it.
I had internal clarity about why certain features stayed out of the MVP, but that reasoning never got formalized as a shared document. In later retrospectives, some of those decisions got questioned as if they'd never been debated.
An explicit record would have saved those conversations and made the reasoning more transferable to the rest of the team. It also would have started the PFM and personalization conversation with the data science teams in parallel with development.
The financial intelligence features that stayed out of the MVP — personalization and PFM — never reached the level the project imagined. The bank pivoted toward other priorities after launch.
ScotiaMóvil solved the technological independence from Toronto and that was real and valuable. But roadmap independence is a different problem. An app that can't incorporate new capabilities without a priority reorganization is still dependent, even if the middleware is yours. That's the conversation this project left open.