21.08.26

Designing for digital resilience in the age of AI

The question I want to explore is simple: when technology makes building easier, how do we decide what should actually exist?

There’s an old idea in ethics. The word comes from the Greek ēthos, which means character, your way of being. And the classic definition says that ethics isn’t about what we can do, it’s about what we choose to do. AI just made that the most practical question in product work.

I’m Ale, a product designer at Proton. I work on privacy-first products, currently Proton Meet and Proton Wallet. What follows isn’t a polished argument. It’s a series of thoughts I want to explore with you.

The pause I didn’t plan

This year I was invited to speak at Web Summer Camp in Opatija. I knew what I wanted to talk about: the changes that have been happening in my life and in my workflow, how the world is changing, and how the way we build things is changing with it.

I had a rough idea. But when everything happens this fast, you never have time to digest it, to really think about it.

Then my flight got canceled. Long hours at the airport, very little internet. And suddenly I had something that’s becoming rare: uninterrupted time to think.

I came back with the core thoughts I want to share here.

Everything feels more reachable

The first thought is about technology, and the world we’re living in right now.

In the last six months, I feel my role has changed a lot. Honestly, even my life has changed in many ways. I’ve developed new patterns, new habits, new ways of working. And I think this will keep changing.

Things that not long ago felt impossible, slow, or extremely complex suddenly feel much more reachable.

For example, I recently built my own website in a few hours. Two years ago, that would have taken me much more time: more technical details, many manual explorations, a lot of energy translating what was in my head into something real.

I see the same thing in product work. Exploring flows, testing concepts, writing specs, comparing design directions, or making prototypes can happen much faster now.

Our minds move faster than our hands.

Someone could say: yes, with AI you can move faster, but maybe the result becomes more generic. I understand that concern, but I don’t fully agree.

What I experienced wasn’t AI making the idea generic. It helped me materialize something that was already in my mind.

We all have infinite thoughts. But we only have two hands. Our mind is faster than our ability to build. Exploring an idea manually takes time. Building variants takes time. Comparing directions takes time.

What AI changes is that it helps us materialize thoughts much faster. So now I can explore faster. I can compare faster. I can decide faster. And then I can build faster.

The Bottleneck has moved

This is where I think the real shift is happening.

Before, the bottleneck was often execution. Can we build it? Do we have enough time? Do we have enough people? Is the technology ready?

A quick story of what that era looked like. When we redesigned Proton Pass, we had three months from concept to beta. The whole game back then was execution: a small team, few dependencies, daily check-ins, designers and developers working at the same time. The only question that mattered was: can we make it in time?

Today, with AI, that kind of bottleneck is shrinking. So the questions change. Should this exist? Who does it serve? What does it change? What does it take away?

In my work this is very real. On products like Proton Wallet or Proton Meet, we can imagine many features. More automation. More data. More integrations. More shortcuts. More growth loops. But the question isn’t only whether we can build them. It’s whether they serve the kind of product we want to create.

Infinite possibility needs direction

There’s something interesting here. Having infinite possibilities doesn’t automatically make us faster. In some ways, it can make us slower.

If we can generate endless options, how do we know when to stop?

As execution becomes easier, direction becomes more important. So the hard question is no longer only: can we build this? The harder question is: should we?

In a world flooded with possibilities, how do we decide what should exist and what shouldn’t?

Constraints create clarity

This is where I think principles and constraints become very important.

In my work, I build privacy-first products. So in my context, privacy is one of the strongest constraints. And I don’t see that as something that blocks progress. I see it as something that creates clarity.

At Proton, privacy isn’t a feature we add at the end. It’s the starting point, and everything else is built on top of it. You can say the same about ethics: it’s not a special category of design, it’s simply how design should be done.

In Wallet, we only support Bitcoin. Other crypto apps add many coins and many features, and they end up confusing. We said no: one coin, a few core actions, an interface that feels like email. From the outside it looks like we’re missing features. In reality, that limit is exactly what made the product simple. The constraint did the design work for us.

Wallet’s goal in one line: Bitcoin should stay in the hands of normal people, not big companies or investment funds. The app is free, open source, encrypted end to end, and only the user holds their money. When someone asks “why don’t you add trading?”, that one line already answers the question.

Constraints can also be written down. For Pass, before designing anything, we wrote three principles: people should feel in control of their data, people should understand the app at first sight, and it should feel nice to use. Every design decision was tested against those three sentences.

One warning about empty words: today everyone says “ethical” and “private”. If everything is ethical, nothing is. The real test of a principle is what you do when saying no costs you something, like a launch date or a growth number.

The constraint isn’t there to slow us down. It’s there to help us decide.

Designing for digital resilience

For my work, that constraint is privacy. But other teams have other principles, other beliefs, other responsibilities. So the bigger question is: what kind of lens can we use to decide what we’re building?

This is where I think the idea of digital resilience becomes useful.

When I say digital resilience, I don’t mean that people should become stronger so they can tolerate bad technology. I mean the opposite.

Digital resilience is about designing products that help people stay in control inside systems that are becoming more automated, complex, and opaque.

It’s connected to privacy, but it’s bigger than privacy. It’s also about trust. Agency. Clarity. Control. Recovery. And reducing unhealthy dependency.

Why does this matter? Remember the LastPass leak. A password manager, the exact tool people trusted to keep them safe, exposed their data. When a system fails, resilience is what protects the people who depend on it.

What makes a product resilient?

For me, a digitally resilient product helps people remain informed, autonomous, protected, capable, and able to recover when something goes wrong.

Informed

People always see what’s really happening. Wallet shows the value in your normal currency first, not in Bitcoin units. BTC and sats are hard to grasp: my cousin once sent money with another app, and the network fee was shown in bitcoin. The fee ate half of what she sent, and she couldn’t see it happening. If the fee had been in her own currency, she would have stopped. We made Bitcoin simpler, but we never pretend it’s simple. Sending money is a serious action, and the user always sees that.

Autonomous

People stay in charge of their own choices. In Mail, you can see all your newsletters in one place and unsubscribe in one click. You decide what reaches you. In Pass, the item page shows the main actions first and puts the advanced options one level deeper. Less clutter, but you never lose the map.

Protected

People don’t have to expose themselves to use the product. In Pass, you can create an alias: an email address that forwards to your real one. You give the alias to shops and websites, and your real address stays private. If the alias starts getting spam, you delete it and make a new one. And in Meet, you can join a call without creating an account. A product can’t leak data it never collected.

Capable

People can do hard things in an easy way. Sending Bitcoin normally means asking the other person for a 62-character address and copying it without a single mistake. In Wallet, you just type their email address, like sending a normal email. Same action, but with a mental model everyone already has. Normal people, including beginners, can now do something that used to be only for experts.

Able to recover

When something goes wrong, people can get back in. In classic Bitcoin wallets, your money is protected by a seed phrase: a list of secret words on paper. Lose the paper, lose the money, forever. Many beginners lose it. In Wallet, your keys are backed up encrypted inside your Proton account, so a beginner can’t lose everything by losing a piece of paper. Advanced users can still add a passphrase for full manual control. Good recovery is designed before the accident, not after.

So if I had to ask myself one question before deciding what to build, it would be: does this make people more capable, or more dependent?

That question opens three more. I’ll leave you with them.

Does this product give people more agency, or make them more dependent?

This can be hard to see, because dependency often comes disguised as convenience.

A product can feel magical. It can reduce friction. It can remove steps. It can make the user do less. But sometimes, when the product does too much, the user understands less. They depend more on the system. They lose the ability to question, adjust, recover, or make informed decisions.

A concrete case from Wallet: we removed the seed phrase step and we name new wallets automatically, so beginners don’t give up during setup. But we kept the passphrase option for people who want full manual control. The default helps you; it doesn’t replace you.

So, where do you see products that genuinely increase people’s agency? And where do you see products that make people more dependent, even if they’re very convenient?

What should we deliberately not build?

In product work, we often talk about what we ship. But I think the things we decide not to ship say just as much about our values.

There may be features that would be easy to build, useful for growth, or attractive from a business point of view, but they create the wrong trade-off. Maybe they require too much data. Maybe they reduce user control. Maybe they make the product more addictive. Maybe they optimize for short-term engagement but create long-term dependency.

In Wallet, we said no to adding more coins and trading features, even though competitors have them and users ask for them. They didn’t fit what the product is for.

Some things we refuse by default: dark patterns, fake urgency, and consent screens designed to confuse. Simple should never mean dishonest.

And leadership means being ready to delay a launch, redo work, or push back on a direction when privacy, safety, or trust is at risk. That’s the moment values become real.

So, what are examples of things teams should deliberately not build? And how do we make those decisions without sounding like we’re against innovation?

Where does convenience become loss of control?

I’m not against convenience. I love good automation. I love when products remove unnecessary friction.

But I think we need to be more precise about the kind of friction we remove.

Some friction is bad. It’s just noise. It makes the product harder than it needs to be. But some friction is meaningful. It gives the user a moment to understand, confirm, choose, or recover.

In Wallet, sending money takes a few visible steps, on purpose. We could make it one tap. But when you move money, you deserve one moment to check before you confirm. Good friction protects you.

Our onboarding rule was: ask only what’s needed, at the moment it’s needed. We removed the useless friction, like confirming your recovery phrase or naming your wallet, and kept the meaningful friction, like reviewing your transaction before sending.

Simplicity is only honest when the user still understands what’s happening.

So, as products become more automated: what should the system do for the user? And what should the user still be able to see, understand, change, or undo?

When building gets easier, deciding matters more

I want to close with this thought.

AI gives us more speed, more options, and more ways to materialize what we imagine. But speed alone doesn’t tell us what should exist. For that, we need principles. We need constraints. We need better questions.

And maybe digital resilience can be one useful lens. Not as a perfect answer, but as a way to ask: are we helping people stay informed, autonomous, protected, capable, and able to recover? Are we building products that increase agency, or products that create dependency?

Every product shapes behavior. Products shape what people notice, what they trust, what they delegate, and what they slowly forget how to do. So when we build products, especially now, we’re not only solving tasks. We’re shaping habits, expectations, and dependencies.

So I’d love to leave you with one final question.

What is one principle you want your product decisions to protect?