Imagine an older adult trying to book an appointment through an online public service. They complete the form, reach identity verification and then struggle to understand what to do with the code sent to their phone. After several unsuccessful attempts, they ask a family member for help.
The design team suggests larger text and buttons. Customer support recommends making telephone assistance more prominent.
But is button size really the problem? Or have we designed a service that takes control away from users precisely when they need clarity and confidence?
This hypothetical situation leads to the eighth question in our series of 1,000 Product Manager interview questions:
“How do you help seniors complete a digital service without the help of others?”
What is the interviewer actually assessing?
This is a product sense and user experience design question. It tests far more than a candidate's knowledge of accessible interfaces.
The interviewer wants to understand whether you can identify the real user problem, distinguish between groups with different needs, evaluate possible solutions and propose a testable intervention.
A strong answer should demonstrate evidence-based prioritisation, awareness of meaningful trade-offs and a clear definition of success.
A weaker candidate might immediately suggest larger fonts, bigger buttons, voice guidance and a simplified interface for older users.
Those ideas could be useful, but they are solutions in search of a properly defined problem.
A stronger candidate starts with a different question:
What is the user trying to accomplish, where do they become dependent on someone else, and why?
Define what independent completion means
Before designing anything, we need to define the outcome.
Independence is not merely reaching the final screen without assistance. A user should be able to understand the task, enter accurate information, recognise whether it has succeeded and complete it safely without unwanted reliance on another person.
Consider someone who can book an appointment in two minutes with their daughter's help but cannot complete the same task alone.
The service might report a successful transaction, yet the underlying accessibility and usability problem remains unresolved.
Equally, independent completion should not mean removing support. Some people need assistance, while others prefer it. A well-designed service makes independent completion easier without taking away appropriate alternatives.
The goal is to reduce unwanted dependence, not to make asking for help unacceptable.
Older adults are not a single user segment
One of the most common mistakes in this question is assuming that age directly determines digital ability.
Someone aged 75 might use online banking and mobile applications every day. Another person aged 65 might have very limited experience of digital services.
Even users with similar digital skills may encounter entirely different barriers.
These barriers can be grouped into several categories.
Visual and motor barriers include low-contrast text, small controls, insufficient spacing and interactions requiring precise movement.
Cognitive and language barriers include unfamiliar terminology, long forms, unexpected steps, excessive information to remember and unclear error messages.
Trust and security barriers include uncertainty about payment, privacy concerns, fear of fraud and doubts about whether a transaction has succeeded.
Access and experience barriers include unreliable connectivity, unfamiliar browsers, difficulties using verification messages and older devices.
The W3C's guidance on older users explains that many age-related accessibility needs overlap with the requirements addressed by established web accessibility standards.
The implication for product management is straightforward: we should segment users by their needs, context and task barriers, rather than treating age as a sufficient explanation.
Discover the problem before choosing a solution
As the Product Manager, I would begin by selecting one specific, important digital service.
If the product offers several services, I would prioritise a journey where older users experience substantial drop-off, repeated errors or frequent requests for assistance.
I would combine three types of evidence.
Observe real users completing the task
Conduct usability sessions with people who have different levels of digital experience, using their usual devices wherever practical.
Ask participants to complete a realistic task and observe where they hesitate, misunderstand instructions, make mistakes or request help.
For an independent-completion study, the facilitator's intervention rules must be defined in advance. If a researcher guides someone through a difficult step, that session cannot be counted as entirely independent success.
Examine product analytics
Investigate the journey from entry to successful completion.
Which stages have the highest abandonment? Where do validation errors cluster? How often do users repeat a step? Does identity verification produce disproportionate drop-off? What happens immediately before a support request?
Analytics can identify potential problem areas, but they do not always explain why those problems occur.
Review support conversations and user feedback
Look for recurring patterns in customer support contacts.
Perhaps users understand the form perfectly but cannot recognise whether their appointment has been confirmed.
If that is the principal problem, redesigning the entire form would probably be the wrong first investment.
Recruitment matters as well. Research involving only digitally confident older volunteers could systematically overlook the people most affected by the problem.
Compare the available approaches
There are three credible product directions to consider.
Option one: Build a dedicated simplified mode
A dedicated experience could use larger controls, fewer choices and more detailed instructions.
This might help some users, but it introduces trade-offs.
Not all older adults need a simplified interface. Maintaining two experiences increases design, engineering and testing costs. Simplification can also remove functionality that users genuinely need.
I would consider this option if research revealed a distinct, persistent requirement that the main experience could not reasonably accommodate.
Age alone would not justify it.
Option two: Improve the primary experience for everyone
This would be my initial preference, subject to evidence.
Rather than creating a separate product, remove unnecessary barriers from the existing journey.
Use understandable language, predictable navigation, accessible controls, clear feedback and error recovery that does not require users to remember or guess information.
These improvements may benefit inexperienced users of any age, people under time pressure and those using a service in difficult circumstances.
However, simplifying a journey must not mean removing essential information or security checks.
Option three: Expand human assistance
Telephone guidance, webchat or in-person support may be essential for some users.
But if every older user is simply redirected to customer support, the dependency has not been solved. It has been relocated.
Assisted digital support should therefore remain a safe and accessible alternative, rather than becoming a substitute for improving the service itself.
The UK Government's Service Manual takes a similar approach: users who cannot complete online tasks must not be excluded from accessing a service.
What would an improved experience look like?
Once the primary barriers are understood, I would focus the design on several practical principles.
Make every step understandable
Users should know where they are, what information is required and what will happen next.
For complex forms, presenting one clear question or decision at a time can improve focus.
The GOV.UK Design System recommends starting with one question per page, while also explaining the importance of clear labels, navigation and avoiding requests for repeated information.
Nevertheless, breaking a form into too many pages may increase effort. The approach should be tested against the actual task rather than adopted mechanically.
Make interaction accessible
Ensure readable contrast, support for text enlargement, clearly identifiable controls, appropriate spacing and compatibility with assistive technologies.
WCAG 2.2 includes a Level AA target-size requirement of at least 24 by 24 CSS pixels, subject to defined exceptions.
That is a technical minimum, not an assertion that the same dimensions are ideal for every user.
Help users recover from errors
An error message saying "Invalid information" provides little useful guidance.
A more effective experience identifies the problematic field, explains what needs correcting and preserves previously entered information wherever appropriate.
The user should not have to restart an entire journey because of one recoverable mistake.
Reduce the cognitive burden of authentication
Authentication should not become a memory test.
Requiring someone to memorise a password or manually transcribe a verification code can introduce unnecessary barriers.
WCAG 2.2's Accessible Authentication guidance addresses these concerns. Supporting password managers, copy and paste, and suitable alternative authentication methods can reduce the burden.
Accessibility improvements must still respect security requirements, including protection against account takeover and fraudulent access.
Make successful completion unmistakable
After submitting a request, users should receive clear confirmation, relevant reference information and a straightforward way to review or correct the outcome.
In some cases, this reassurance could matter more than changing the visual appearance of the preceding screens.
Hypothetical software product example
Imagine a municipal appointment-booking platform discovering that some older users depend on relatives to complete bookings.
The team identifies three competing hypotheses.
First, people may struggle to find the correct service.
Secondly, authentication may interrupt the journey.
Thirdly, appointments may be submitted successfully, but the confirmation screen may fail to communicate that clearly.
At this stage, building a complete older-person mode would be premature.
The product researcher and designer test three focused prototypes with representative users: clearer service selection, easier authentication and an improved confirmation experience.
Engineering assesses feasibility. Customer support contributes recurring issues. Security colleagues evaluate whether the proposed changes introduce opportunities for misuse.
Suppose the research indicates that verification is the principal barrier.
The team could then test a narrower intervention: allowing verification codes to be pasted, supporting automatic code completion on compatible devices, improving error explanations and offering secure code resending.
The next question is whether users can complete the whole journey independently afterwards.
If they simply encounter a different obstacle at the following step, the problem has not been fully resolved.
And if the evidence points to a different cause altogether, the priority should change.
Good product management is not about defending the first proposed solution. It is about finding a change that removes the real obstacle.
How should success be measured?
My primary measure would be the independent successful completion rate.
In a usability study, this means the number of eligible participants who finish a defined task correctly and safely without guidance, divided by the number of eligible participants who start that task.
This is different from a conventional analytics completion rate.
An event-tracking system usually cannot tell us whether someone completed the journey alone or with a family member's assistance.
I would also monitor three categories of supporting measures.
Diagnostic metrics: time on task, input errors, repeated steps, requests for help and users' understanding of the outcome.
Operational metrics: journey abandonment, stage-specific support demand and completion through alternative support channels.
Guardrail metrics: consequential mistakes, incorrect submissions, security and privacy incidents, and unintended deterioration in other users' experiences.
Small qualitative studies can reveal serious usability problems, but they do not establish statistically reliable improvements by themselves.
A limited pilot should therefore have a predefined observation period, decision criteria and stopping conditions.
For example, the team might compare the revised and existing journeys over several weeks, while examining both completion and protective measures.
The aim is to learn whether the intervention works, not to manufacture an impressive improvement figure.
Who owns which decisions?
The Product Manager is responsible for defining the customer problem, deciding where to invest and aligning the work with measurable product outcomes.
Product designers shape and test the interactions. Engineers assess implementation feasibility and quality. Security, operations and support teams help identify operational constraints and risks.
A Project Manager, where that role exists, focuses on delivery coordination, schedules, dependencies and agreed constraints.
In a Scrum environment, the Product Owner is accountable for maximising product value and effective Product Backlog management under the Scrum Guide. That accountability should not automatically be treated as interchangeable with the job titles Product Manager or Project Manager.
Clarifying these responsibilities helps the team make decisions without confusing product outcomes with delivery activities.
A natural interview answer
A candidate could respond along these lines:
"I'd start by clarifying which digital service we're discussing and identifying where older users actually need assistance.
"I wouldn't treat everyone above a certain age as having the same requirements. I'd look at their digital experience, the task they're trying to complete and the barriers they encounter.
"Then I'd combine usability research with product analytics and customer support feedback to determine whether the main issue is readability, navigation, authentication, trust or something else.
"Unless the evidence points towards a separate experience, I'd prefer to improve the main journey first. If the verification step is the barrier, for example, I'd make that step easier to understand and complete without weakening security.
"I'd measure whether people can finish the whole task accurately and independently, rather than relying only on conventional completion metrics.
"I'd also preserve accessible support routes for users who still need them. If testing showed that my original diagnosis was wrong, I'd change the solution instead of trying to justify it."
This response demonstrates a decision process, its assumptions and the conditions under which the candidate would reconsider the recommendation.
Interview follow-up questions
What would you do if you only had two weeks?
This is one of the two follow-up questions provided in the original interview-question reference.
Two weeks would not be sufficient to solve every accessibility issue in a complex service, but it could be enough to identify and test an important barrier.
I would begin by reviewing existing analytics and support contacts, then conduct focused usability sessions with representative users.
From those findings, I would select one frequent, consequential problem, develop a small prototype and test it.
The final output would not be a claim that the entire service had been fixed. It would be a clearly evidenced diagnosis, test results, risks and a recommendation for the next iteration.
What evidence would make you reject your proposed solution?
This is the second follow-up from the original source.
If improving authentication did not increase independent task completion, I would reconsider the original hypothesis.
I would also reject or revise an intervention if it reduced completion time but increased serious mistakes, privacy risks or security incidents.
Research might reveal that the real barrier is not the interface at all. It could involve distrust of the provider, lack of internet access or unnecessarily complicated administrative requirements.
In that case, the scope of the solution might need to expand beyond interface design into service or process redesign.
Common weak answers and why they fail
"I'd make all the buttons bigger."
This proposes a feature without diagnosing the underlying problem. Larger buttons cannot, by themselves, resolve confusing authentication or a lack of trust.
"I'd create a simplified version for every older user."
This assumes uniform needs and may create a costly, incomplete parallel experience.
"If completion increases, the redesign is successful."
Completion alone tells us neither whether the user acted independently nor whether they made a consequential mistake.
"I'd eliminate the need for family assistance."
The intention is reasonable, but the wording risks turning independence into an obligation. Users should retain the choice to seek help.
"We'll follow accessibility standards, so the problem will be solved."
Technical compliance is necessary, but it does not guarantee that a particular service is usable in practice.
The W3C recommends combining standards-based evaluation with testing involving real users, as some usability barriers emerge only through actual interaction.
Conclusion
Helping older adults complete digital services independently begins with identifying the specific barrier preventing successful task completion, not with making assumptions based on age.
My initial recommendation would be to improve the main experience, remove unnecessary complexity, provide accessible interactions and retain safe routes to assistance. That recommendation should change if research shows that the underlying barrier requires a different approach.
A genuinely inclusive digital product allows people with different abilities and levels of experience to complete meaningful tasks safely, confidently and with control over their decisions.
The most important evidence of success is not how simple the interface looks, but whether users can achieve their intended outcome without unwanted dependence.
Sources
- W3C — Older Users and Web Accessibility
https://www.w3.org/WAI/older-users/ 2. W3C — How to Meet WCAG 2.2
https://www.w3.org/WAI/WCAG22/quickref/ 3. W3C — Understanding Accessible Authentication (Minimum)
https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum 4. W3C — Involving Users in Evaluating Web Accessibility
https://www.w3.org/WAI/test-evaluate/involving-users/ 5. GOV.UK Design System — Question Pages
https://design-system.service.gov.uk/patterns/question-pages/ 6. GOV.UK Service Manual — Designing Assisted Digital Support
https://www.gov.uk/service-manual/helping-people-to-use-your-service/designing-assisted-digital
