Feature Philosophy

This manual is intended for volunteers of the TSF, but anyone else is free to take a look as well.

There's a million things you could do, and yet you can't do them all at once. Building a messenger, as anything else, is about making the right choices. This manual covers the factors we always keep in mind when considering new features. This text serves as a companion to our (internal) user suggestions board where you can find more detailed estimates on the likelihood for particular features to be added to Telegram.

Determining priority

The formula to determine which feature gets implemented first is pretty straightforward:

(relevance for the project + UX improvement) / (added complexity x speed impact x development time)

This formula is everything you really need, although I will describe the components in greater detail below.

1. Relevance

Telegram is a mass market messenger with a focus on speed and security. A good product needs to be consistent, so every feature we add must be relevant to these core aspects. And they are all equally important, we can't give too much preference to any one of them. We must keep all the aspects in harmony.

E.g. any security-related feature we introduce must allow us to stay comprehensible for the masses and just as fast. Same with mass market features, we must stay as secure as possible when introducing them.

2. UX improvement

While we love our users very much, we are not building our messenger to please individuals. This is a mass market messenger, and we cater to the masses. This automatically means two things:

  • Any new feature must be useful to at least 5% of the users (and 50% is better,)
  • Any new feature must be useful at least 5% of the time (and 50% is better)

So ask yourself: Will tens of millions of people around the world use this feature more than once a month?

Exotic features may look fancy and bring in good press, but they are wasteful. They don't contribute much to overall user experience (since they are used so rarely by so few users) — but they cost you time, developer resources and result in increasing complexity of the interfaces. Introducing a seemingly harmless exotic feature can sometimes result in damaging the UX instead:

3. Complexity

A good user interface is about minimizing choice and diversity. For example, 90% of Telegram is just 5 screens: list of chats, messages in a chat, profile screen, list of contacts, settings screen. The ultimate goal of a good UI is to rely on as few entities, options and settings as possible.

Yes, settings are evil because they fragment the user experience. Each new setting increases the complexity of your app and steepens the learning curve. You cannot escape choices by just offering settings and pushing the decisions you must make over to the user. The more settings you get, the more tuning your user will need to do to arrive at usability.

We don't have the luxury of the users' attention and nobody spends an afternoon setting up and studying how an app works. So everything we have must be instantly clear to anyone. Ideally. This may not be exactly the case even now, but the important thing is — we must not make it worse. Extra settings and options are a necessary evil sometimes, but generally we should find ways of avoiding them by providing the one true path out of the box.

4. Speed

As a mass market messenger Telegram must successfully compete with players that provide fewer encryption options, use weaker algorithms, or neutralize their own encryption for the sake of usability and speed. Thanks to certain breakthroughs in MTProto's design we are above our competition in terms of speed staying more secure at the same time. But we must always be on our guard and take care that the features we introduce do not slow us down too much.

5. Development resources

Telegram is a small band of very focused developers. We only have one specialist per app — and yet we usually try to update our apps at least once a month, ideally twice. In order to achieve this pace, we must choose wisely what we implement. Some of our plans are affected by the current Telegram infrastructure: certain things are easier to introduce, while other require massive changes in the server-side code, API or the MTProto protocol itself.

To sum up

On the whole, it is better to be rich and healthy than poor and sick. In an ideal universe this means only implementing things that are relevant to the project and to the masses, add zero complexity to the interface, have positive effect on app speed, while costing nothing in terms of time and developer effort.

In a more real world this means that we usually wouldn't do things that are irrelevant to the project, or highly exotic, or introduce too much complexity, or slow Telegram down too much, or require too much time and effort (when that same time and effort could be used to make several other things happen, possibly with a higher UX impact).

That said, every now and then we do the impossible or the unheard of. Being too rational all the time would be boring, right? Fracture holy chipmunks.

Feature Philosophy FAQ

Q: So who decides?

We monitor our users' reactions closely via our support channels, twitter and store reviews. But in order to maintain consistency in the product, the ultimate power of decision must lie in the hands of one person. In Telegram's case this person is Pavel Durov, his vision and experience got us this far — and will hopefully get us much further.

Q: Why not let the people decide?

User requests are an essential part of Telegram's development. But uncontrolled democratic processes in software development can be dangerous. Unfortunately, vocal minorities don't always properly represent silent majorities. And those silent majorities in turn only become vocal when changes in the system begin hurting them. All of this can result in erratic behavior: adding features just to remove them 6 months later, introducing conciliatory settings. This is usually followed by the slow and inevitable demise of the project.

So in Telegram we've opted for a well informed autocratic approach.

Q: X has this feature! Why don't we?

Many of our competitors have features that we don't have — or don't have yet. It is important to understand that they have those features for a reason. And this reason is not necessarily relevant for Telegram.

A good example of this is the 'delivered to device' status that some of the WhatsApp fans ask us to introduce. This status would be useless here, Telegram being a cross-platform cloud messenger. I'm logged in on my PC at home and on my phone. So what does it matter to you that my PC downloaded the message while I'm stuck on a mountain with no network coverage on my phone?

But whatever the situation may be right now, there is always a chance that things will change in the future. So never be radical and never burn your bridges. We're constantly looking for meaningful ways to improve Telegram. This means that any suggestion has a chance of becoming reality — at some point in the future, in some way.

More TSF manuals