Imagine someone opening their banking app after a month away. They want to check their balance and pay a bill, but instead find a crowded home screen filled with financial charts, loan offers, promotional messages and services they rarely use.
Should we simplify the home screen for this customer? Or could removing information and features actually make their experience worse?
This is precisely the kind of judgement a Product Manager needs to make through an understanding of user behaviour, evidence and business constraints.
What Is the Interviewer Really Assessing?
The interview question is:
How would you design the home page of a banking app for a user who only logs in once a month?
This is a Product Design and User Experience question, but the interviewer is not simply asking for an attractive interface or a list of potential features.
A strong response should demonstrate that you can:
- Identify the underlying user problem rather than jumping straight into a design.
- Investigate infrequent usage without assuming that it represents dissatisfaction.
- Balance simplicity, efficient access, security and commercial objectives.
- Compare feasible design approaches and explain your choice.
- Measure success through meaningful user outcomes.
- Explain what evidence would make you reconsider your initial recommendation.
The central skill being tested is product judgement rather than interface design alone.
Step One: Understand Why the User Logs In Only Once a Month
One of the easiest mistakes is to treat login frequency as a direct measure of customer satisfaction.
Yet monthly usage is not necessarily a problem.
A customer might open their banking app only when their salary arrives, when they need to pay a bill or when they want to review their transactions. For that person, a monthly visit may represent perfectly successful product usage.
Another customer might visit infrequently because the interface is confusing, they struggle to remember where services are located, or they have previously encountered an unsuccessful transaction.
These users exhibit similar behaviour, but their underlying needs are very different.
Before proposing a design, I would investigate several questions:
- What are monthly users primarily trying to accomplish?
- Can they complete those tasks successfully?
- Is their limited usage intentional, or does it reflect friction in the experience?
- Which services are essential to them, and which merely add complexity?
- Are their difficulties related to navigation, understanding account information or concerns about security?
We can investigate these questions through behavioural analytics, navigation paths, error patterns, customer support enquiries and short user interviews.
The important principle is not to assume that infrequent usage needs fixing before understanding what causes it.
Step Two: Choose a Specific User Segment
Designing a single home screen for everyone who logs in once a month would be an imprecise starting point.
We could identify at least three distinct groups:
- Customers who mainly check balances and recent transactions.
- Customers who make periodic payments, such as bills, loan repayments or bank transfers.
- Customers who use digital banking less often because they find it difficult or worry about making mistakes.
For each group, I would examine the importance and frequency of their tasks, the friction they encounter and the alternatives currently available to them.
Suppose the initial research suggests that customers making monthly payments have a particularly clear and testable problem.
We could then frame the design challenge as follows:
How might we help customers who make monthly payments complete their primary banking tasks quickly, without unnecessary searching or an increased risk of mistakes?
This is more actionable than simply deciding to create a cleaner interface.
It identifies the user, the desired behavioural outcome and the constraints that matter.
Step Three: What Should the Home Screen Help the User Understand?
For somebody returning after several weeks, an effective home screen should address three needs.
1. What Is the Current State of My Account?
The customer may want to know what has happened since their previous visit without navigating through several screens.
Useful information might include the available balance, recent transactions and significant changes since the last login.
However, this information must be presented responsibly:
- Show when account information was last updated.
- Never present outdated information as though it were current.
- Allow users to conceal balances and other sensitive details.
- Clearly distinguish important account messages from promotional content.
A summary of changes since the previous visit could be valuable, provided the underlying information is accurate and sufficiently complete.
2. How Do I Complete the Task I Came Here to Do?
Frequent users may remember the steps required to reach a particular service.
Someone who visits only once a month may need to rediscover that navigation path every time.
This connects to the usability principle of recognition rather than recall.
Nielsen Norman Group explains that recognising available options generally requires less mental effort than retrieving them from memory without contextual cues.
For a monthly banking customer, the home screen should therefore make important actions easy to recognise through clear, descriptive labels.
Depending on user research, these might include:
- Transfer money
- Pay a bill
- View transactions
- Make a loan repayment
The precise actions and their priority should be determined by evidence, not assumptions about what banking customers usually do.
Importantly, making a transaction easier to find should not mean bypassing the checks necessary to complete it securely.
3. Is There Anything Important I Need to Know?
Someone who has been away for a month may have missed significant updates concerning their account or banking services.
A genuinely relevant notification could provide considerably more value than another promotional offer.
For example, a forthcoming loan repayment or an important change to the status of an application might deserve prominent placement.
Nevertheless, such messages must be accurate, timely and actionable.
An outdated notification or an ambiguous financial warning could create anxiety or prompt an inappropriate decision.
Step Four: Compare the Design Options
There are three credible approaches to consider.
Option One: A Standard Home Screen for Everyone
All customers see the same arrangement of banking information and services.
This is relatively straightforward to develop, predictable to use and easier to maintain.
However, monthly customers may still need to search through numerous irrelevant functions to accomplish their primary task.
Option Two: A Fully Personalised Home Screen
The application dynamically changes its content and layout according to each customer's transaction history, usage patterns and predicted needs.
When reliable data and sufficient technical capability are available, this could be valuable.
However, it also introduces complexity and risk.
A customer who logs in monthly may generate too little behavioural information for accurate predictions.
Furthermore, if navigation elements continually move, the customer may encounter what feels like an unfamiliar interface on every visit.
Personalisation can therefore undermine the very predictability that an infrequent user needs.
Option Three: A Stable Layout With Contextual Assistance
This would be my preferred starting point.
The home screen retains a consistent structure. Account information, primary actions and access to other services remain in predictable locations.
Alongside this stable foundation, a small, carefully controlled section can display information relevant to the customer's monthly visit.
For example, it might show important changes since their previous login or provide a shortcut to a recurring payment they have made before.
The distinction is that relevant information can change without constantly rearranging the interface itself.
Compared with full personalisation, this approach is easier to test, limits the need for customers to relearn navigation and allows the value of contextual features to be assessed independently.
An Essential Constraint: Simplicity Must Not Compromise Security
In banking, fewer taps do not always mean a better experience.
Allowing a customer to reach a money-transfer screen directly may be useful. Removing necessary identity verification, payment confirmation or other security controls is an entirely different matter.
Likewise, displaying sensitive financial information on the home screen requires careful consideration of privacy.
Accessibility also matters.
Readable text, meaningful labels, sufficiently large touch targets and compatibility with different visual or motor abilities should all be evaluated.
The W3C's WCAG 2.2 provides an established reference for accessible digital interfaces, although its application to native mobile applications needs to be interpreted according to the technology and relevant requirements.
Commercial objectives introduce another potential conflict.
A bank may want to promote financial products, but the home screen should not prioritise sales so aggressively that essential customer tasks become harder.
For example, the UK Financial Conduct Authority's Consumer Duty framework emphasises understandable communications, effective customer support and the avoidance of foreseeable harm.
This is a UK regulatory framework rather than a universal banking requirement, but it offers a useful perspective on balancing customer outcomes with commercial interests.
Practical Example: Redesigning a Digital Banking Home Screen
Hypothetical scenario
Imagine a digital bank whose product team notices that a segment of customers returns at roughly monthly intervals.
Initial analytics indicate that some of these customers move between several sections before reaching bill payments or transaction history.
However, that behaviour alone does not establish that navigation is problematic. Customers might simply be exploring the available services.
The Product Manager works with a data analyst, UX researcher and customer support team to investigate the circumstances surrounding these navigation patterns.
They look for evidence of errors, abandoned tasks or support enquiries associated with the journeys.
Two potential solutions emerge:
Option A: Introduce clearly labelled shortcuts to frequently used banking services.
Option B: Retain those shortcuts while adding a concise summary of important account changes since the previous visit.
Rather than immediately implementing both, the team first evaluates prototypes through usability testing.
If customers successfully complete their tasks using a stable home screen with clearer shortcuts, building an additional account-summary feature might be unnecessary.
If the evidence instead suggests that customers struggle to understand what has happened between visits, the summary could deliver greater value.
The UX designer is responsible for making the interface understandable. Engineering assesses implementation feasibility, while security specialists review sensitive interactions.
The Product Manager brings this evidence together to decide which opportunity deserves investment and what outcome the team should pursue.
In organisations using Scrum, the Product Owner is accountable for maximising product value and ensuring effective Product Backlog management. That accountability is not automatically identical to the job title Product Manager. Where a Project Manager role exists, its focus is more closely associated with coordinating delivery and managing execution constraints.
These responsibilities may overlap in practice, but distinguishing them helps prevent confusion over who owns the product decision.
How Would We Measure Success?
A tempting but potentially misleading metric is login frequency.
If somebody needs to use their bank once a month, encouraging daily visits does not necessarily create additional customer value.
A better measurement approach focuses on whether customers achieve their intended outcomes.
1. Primary Task Completion Rate
Measure the proportion of customers who successfully complete a clearly defined task, such as paying a bill or obtaining a statement, during their monthly visit.
The denominator matters.
We should measure success among customers with that specific intention or identified task, rather than treating every login as a payment attempt.
In usability research, the task can be established beforehand. In product analytics, identifiable transaction or service journeys can be evaluated separately.
2. Time to Complete the Task
Measure the time between entering the relevant journey and successfully completing the action.
For example, how long does it take somebody to complete a bill payment?
This helps establish whether the experience has genuinely improved rather than simply moving buttons to different positions.
3. Error and Abandonment Rates
Monitor observable errors, failed attempts and journeys abandoned before completion.
These should be analysed by task type so that problems in bill payments are not obscured by performance elsewhere.
4. Guardrail Metrics
The redesign must not produce unacceptable increases in mistaken or failed transactions, security and authentication problems, related support enquiries or customer complaints.
The team should agree on the relevant guardrails and acceptable thresholds before the experiment begins.
Because the target customers return approximately monthly, a meaningful production evaluation should ideally cover several natural usage cycles.
A few days of encouraging results would not provide sufficient evidence of sustained improvement for this particular segment.
Financial data collection must also remain proportionate: sensitive account details should not be unnecessarily recorded in analytics merely to measure interface performance.
A Natural Interview Answer
Here is how I would bring that reasoning together in an interview:
"First, I'd want to understand why the customer only logs in once a month. That might not be a problem at all. They could simply use the app for monthly payments or checking their balance.
"I'd look at their behaviour and speak to a few customers to understand what they're trying to accomplish and where they encounter difficulties.
"If their main need is to complete a small number of regular banking tasks, I'd favour a stable, predictable home screen where balances, transfers, bill payments and transaction history are easy to find.
"If research shows that customers struggle to understand what has changed since their previous visit, I'd also test a simple account summary.
"I'd measure success through task completion, time to completion and errors rather than trying to increase login frequency. Security and privacy would remain non-negotiable constraints.
"And if the evidence suggests the real problem is authentication or payment confirmation rather than navigation, I'd change the priority and address that instead."
This response offers a decision-making process rather than merely listing attractive interface features.
It also explains the conditions under which the recommendation should change.
Likely Interview Follow-Up Questions
Question One: What Would You Do If You Had Only Two Weeks?
Two weeks would not be enough to confidently measure the long-term effect of a redesign on customers who return monthly.
However, it would be enough to reduce uncertainty and determine whether further investment is justified.
I would focus on:
- Identifying important monthly customer journeys from existing analytics.
- Interviewing a small, relevant sample to understand their tasks and difficulties.
- Working with a designer to prepare one or two inexpensive prototypes.
- Conducting usability tests to identify observable task-completion problems.
- Using those findings to decide whether a limited production experiment is warranted.
The objective would not be to claim improved retention or sustained behavioural change after two weeks.
It would be to answer the most important unanswered questions at a reasonable cost.
Question Two: What Evidence Would Make You Reject Your Proposed Solution?
If research showed that monthly customers already completed their tasks without meaningful difficulty, I would lower the priority of a home-screen redesign.
If testing revealed that new shortcuts increased mistakes, confusion or difficulty accessing essential services, I would revise or remove them.
The evidence might also show that the biggest problem occurs before customers reach the home screen, perhaps during password recovery, authentication or transaction confirmation.
In that situation, continuing to redesign the home screen would be addressing the wrong problem.
A competent Product Manager should be able to defend a decision while remaining willing to abandon it when better evidence emerges.
Common Mistakes and Weak Answers
"They don't use the app very often, so I'd remove all the unnecessary features."
This assumes that infrequent usage automatically calls for fewer features. A rarely used service may still be essential to a particular customer.
Without understanding the relevant tasks, removing functionality is not a defensible decision.
"I'd use AI to personalise the entire home screen."
This jumps to a technically ambitious solution before establishing whether the bank has sufficient data, whether predictions would be reliable or whether customers would benefit.
Poorly designed personalisation could make an already unfamiliar interface even harder to navigate.
"I'd redesign the app to make customers log in every day."
This confuses increased engagement with customer value.
More sessions are not necessarily a desirable outcome for somebody whose banking needs are already being met through one monthly visit.
"I'd remove transaction confirmation steps to make everything faster."
Simplification in a financial product must account for fraud, payment errors, privacy and security requirements.
Reducing friction does not justify removing essential safeguards.
Conclusion
Designing a banking app home screen for somebody who logs in once a month should begin with understanding why they return and what they need to accomplish.
If the evidence points to difficulty finding and completing recurring tasks, a stable layout, clearly labelled primary actions and a small amount of relevant contextual information provide a sensible starting point. This approach is easier to evaluate than extensive personalisation and reduces the risk of making navigation unpredictable.
But it remains a testable recommendation, not a universal answer. If research indicates that the real difficulty lies in authentication, understanding financial information, security or another part of the journey, the product priorities should change accordingly.
The Product Manager's job is not to maximise the time customers spend inside a banking app. It is to help them achieve their intended outcomes confidently, with minimal unnecessary effort and without compromising security.
Sources
- Reforge — Product Manager Interview Questions — Guidance on assessing product judgement in interviews; not official verification of this exact banking scenario.
- Nielsen Norman Group — Memory Recognition and Recall in User Interfaces — Research-informed guidance on recognition and recall in interface design.
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2 — Accessibility requirements and recommendations for digital interfaces.
- Financial Conduct Authority — About the Consumer Duty — UK regulatory expectations concerning customer understanding, support and consumer outcomes.
