
Role: Senior UX Designer (Lead)
Team: Product Manager, UX Researcher, Telecom Engineers, Network Engineers, Developers
Timeline: 2018–2019
Platform: iOS & Android
Company: A1 Telecommunication, Bulgaria
When Mtel, Bulgaria’s first and largest telecom rebranded to A1, the name change alone wasn’t enough. Years of being perceived as a company that didn’t care about its customers had left a trust deficit that marketing couldn’t fix on its own. The mandate was clear: create products that demonstrate genuine social value. Not campaigns. Products.
This was the brief I was handed. Not “design an app.” Design something that earns trust back.
My team set out to find a social problem where a telecom was uniquely positioned to help where our infrastructure, our reach, and our relationship with subscribers gave us an actual advantage over anyone else trying to solve it.
We didn’t start with a solution. We started by looking for a problem worth solving.
I worked closely with our researcher to monitor media coverage and identify issues affecting Bulgarian society that were generating both public urgency and police attention. Telephone fraud targeting elderly people kept surfacing in the news daily, in police statements, in public awareness campaigns that weren’t working. One in four Bulgarians knew someone who had been a victim or a target.
The fraud followed a consistent emotional script: a caller pretending to be a doctor, telling an elderly person their child had been in a car accident and needed money for emergency surgery – right now, no time to verify. The scenario changed constantly to stay ahead of awareness campaigns. That adaptability made it nearly impossible to defeat with information alone.
We recruited 7 people for in-depth interviews: fraud victims, family members of victims, and adult children who feared for their elderly parents. What we heard clarified the problem in ways the statistics couldn’t.
The key insight: The elderly weren’t failing to protect themselves because they lacked information. They were failing because they were emotionally targeted at a moment of manufactured panic, and because the real decision-makers – their adult children – were physically absent and had no tools to intervene.
This reframed everything. The problem wasn’t awareness. It was proximity and control.
When Mtel, Bulgaria’s first and largest telecom rebranded to A1, the name change alone wasn’t enough. Years of being perceived as a company that didn’t care about its customers had left a trust deficit that marketing couldn’t fix on its own. The mandate was clear: create products that demonstrate genuine social value. Not campaigns. Products.
This was the brief I was handed. Not “design an app.” Design something that earns trust back.
My team set out to find a social problem where a telecom was uniquely positioned to help where our infrastructure, our reach, and our relationship with subscribers gave us an actual advantage over anyone else trying to solve it.
We didn’t start with a solution. We started by looking for a problem worth solving.
I worked closely with our researcher to monitor media coverage and identify issues affecting Bulgarian society that were generating both public urgency and police attention. Telephone fraud targeting elderly people kept surfacing in the news daily, in police statements, in public awareness campaigns that weren’t working. One in four Bulgarians knew someone who had been a victim or a target.
The fraud followed a consistent emotional script: a caller pretending to be a doctor, telling an elderly person their child had been in a car accident and needed money for emergency surgery – right now, no time to verify. The scenario changed constantly to stay ahead of awareness campaigns. That adaptability made it nearly impossible to defeat with information alone.
We recruited 7 people for in-depth interviews: fraud victims, family members of victims, and adult children who feared for their elderly parents. What we heard clarified the problem in ways the statistics couldn’t.
The key insight: The elderly weren’t failing to protect themselves because they lacked information. They were failing because they were emotionally targeted at a moment of manufactured panic, and because the real decision-makers – their adult children – were physically absent and had no tools to intervene.
This reframed everything. The problem wasn’t awareness. It was proximity and control.
Existing call-blocking apps weren’t the answer. I audited the competitive landscape and found that every solution on the market shared the same fundamental flaw: they required the person being protected to manage the app themselves.
For our primary vulnerable user – an elderly person, with limited digital literacy, possibly on a feature phone this was a non-starter. The tools that existed assumed a technically capable, motivated user managing their own security. Our users were neither.
We needed something structurally different.
One in four knows a victim of a telephone fraud attempt.
In the last 2 years there are 2794 telephone frauds.
The potential victims are mostly our parents.
Before committing to any design direction, I led five structured working sessions with a cross-functional group: our PM, researcher, telecom engineers, network engineers, and developers. The goal was to understand what was architecturally possible within A1’s infrastructure.
These sessions were essential. Telecom infrastructure has constraints that don’t appear in any design brief – how calls are routed, what can be intercepted at the network level versus the app level, what’s technically feasible for feature phones versus smartphones. Building a shared understanding of those constraints early meant we didn’t design something we couldn’t build.
From those sessions, a concept emerged that no competitor had attempted: a dual-user model, where a technically capable family member (the Admin) manages protection on behalf of a vulnerable relative (the Protected User) – without requiring the protected person to engage with any technology at all.
This wasn’t a feature decision. It was an architectural decision that flipped the entire product model.
The Admin/Protected User model solved several problems simultaneously:
It matched the actual decision-making dynamic. In reality, worried adult children were already trying to protect their parents – calling them, warning them, asking them not to answer unknown numbers. A1 Guard gave that protective instinct a real tool.
It removed the technology barrier for the most vulnerable users. The Protected User doesn’t need to understand the app, configure settings, or make decisions under pressure. The Admin has already handled all of that.
It used the telecom’s unique infrastructure advantage. Because A1 operates at the network level, call filtering doesn’t require the protected person’s phone to run any software. This made the solution viable for feature phones — critical for the elderly demographic we were designing for.
It created a permission layer that built trust. The Protected User must consent to being protected within 48 hours of an Admin’s request. This wasn’t just a legal safeguard – it was a dignity safeguard. The person being protected retains agency over whether they want to participate.
Jonathan, 31, Sofia
Brand Manager
“I have told my grandparents many times, not to trust strangers.
I would like to be able to verify the unknown numbers that call them.”
Motivation:
Jonathan loves his grandparents and wants to protect them.
Frustration:
He worries that he is far from his grandparents.
Brooke, 70, Mezdra,
Retiree
“Unfortunately, I`ve to admit that I`m already too old and can easily fall victim to scams.
I need of protection.”
Motivation:
Brooke doesn`t want to lose her savings.
Frustration:
With the model defined, design decisions followed from a clear north star: the Admin needs confidence; the Protected User needs to feel safe, not managed.
Onboarding for two different users with two different needs. The registration flow branches at the entry point – Admin or Protected User – because the mental models, technical comfort levels, and goals of each are fundamentally different. Forcing them through the same flow would have failed both.
Whitelist over blacklist. We designed around a whitelist of trusted numbers rather than a blacklist of known fraudsters. Blacklists are reactive and always incomplete. Fraudsters constantly use new numbers. A whitelist inverts the logic: only approved numbers get through. Everyone else is held pending Admin review. This was a strategic choice with significant UX implications: it meant the Admin experience needed to be fast, low-friction, and available via SMS notification as well as the app.
Notification design as a core UX surface. When an unknown call comes in for a Protected User, the Admin receives a real-time alert and can choose to allow, redirect, or block. This meant the notification wasn’t a peripheral feature, it was the critical moment the entire product was built around. We treated it with the same design rigor as any primary screen.
Simplicity as accessibility. Every screen was designed for clarity over feature density. The Protected User interface in particular was stripped to the minimum: status, approved contacts, and a way to reach their Admin. Nothing else.
Colors
Typography
Icons![]()
Simple & Secure Login
Choose to continue as a Patron or as Protected user. The login is simple – using the username / email, Facebook, or Google.
Registration
User can login using the username / email, Facebook, or Google.
Settings
The admin enters white list and makes settings for incoming calls and notifications
The admin can create a white list with phone contacts who are free to call.
The admin can choose to receive notifications through the app or via SMS.
For other incoming calls the admin can choose:
– to resolve them
– to redirect them
– to block them
The protected user must agree to be administered within 48 h.
One admin can protect up to 5 users. All settings and statistics can be accessed from the profile of the protected user.
The admin can choose to receive notifications through the app or via SMS.
The admin can choose to receive notifications through the app or via SMS.
Protected user
One admin can protect up to 5 users. All settings and statistics can be accessed from the profile of the protected user.
Admine profile
A1 Guard launched as a free app available on Google Play and the App Store – free not just for A1 subscribers, but for customers of any carrier in Bulgaria. That decision was deliberate: making it A1-exclusive would have undermined the social mission and limited impact. It was a statement about what A1 was choosing to be.
The app was available to any Bulgarian resident. One Admin could protect up to five people. The timing of launch coincided with the early months of Covid-19, when phone fraud rates were rising sharply and elderly isolation was increasing, giving the product immediate, urgent relevance.
The campaign supporting the launch was developed by Saatchi & Saatchi and featured on Ads of the World. But the product itself – the architecture, the dual-user model, the experience – came from two years of research, cross-functional collaboration, and a commitment to solving the problem structurally rather than symptomatically.
A1 Guard is the project where I most clearly understood what it means to lead design at a strategic level. The hardest and most important work happened before any screen was designed: defining the right problem, understanding the structural constraints of what could be built, and facilitating the cross-functional sessions that produced an idea no one person could have arrived at alone.
The dual-user model wasn’t an interface pattern. It was a product concept and it came from asking the right questions across the right disciplines before touching a single wireframe.
If I were doing this project today, I’d push for more formal usability testing with elderly users on the Protected User flows specifically. That was the part of the experience where assumptions were hardest to validate, and where the stakes were highest.
App available on Google Play and the App Store under A1 Bulgaria.
