Personalized interface. Part 1. Pros and cons of the concept

Hello! I want to share my experience of one experimental development, behind which there is a big, in my opinion, idea: a personalized interface that is configured based on the needs of the client. Imagine that two people are looking at the same program, have the same access rights, but see different functions on the screen of their monitor.

In this article I will talk about the preparatory part: about the difficulties and advantages that had to be weighed before you fit into this harlot this story.

About problem

I am a product manager at Wrike and am involved in mobile development. It was the mobile specificity that first made me look at the product in a new way. Our service is quite large, and our clients are decently demanding and want to have access to Wrike while being away from their workplace. Wrike is growing rapidly, which means the mobile application is replenished with new features. But the format of a mobile phone does not imply the presence of complex interfaces and a variety of controls. Frankly, it would be nice for any service to be as simple and clear as possible, regardless of the device on which it is accessed. Usually the user has a limited set of actions, and they don’t need the rest of the function park. Just because of the specifics of Wrike, this set of actions is very different for everyone (what kind of sets will be discussed in the second part of the article). Therefore, the question arose of how to make a universal application for everyone.

Reflections on the topic

Everything I know in this world develops according to very specific rules. If something is capable of survival, whether it be an idea or a living organism, it inevitably gains mass. As the mass of an object grows, so does the space it occupies. This new space has its own contexts that affect the object, which means that in order to survive, it (the object) must adapt. Let me give you an analogy with a start-up IT company. At first, two people in it do everything, somehow sharing responsibilities. The company’s turnover is increasing, and with it new tasks arise, which, for example, are related to security, analytics, legislation of different countries, etc. The area of ​​responsibility of the company is growing. And to cope well with her, you need to hire new people. And so, after a while, a large number of departments appear in the company that specialize in one specific area or problem.

These rules perfectly fit our product: Wrike began with a simple task management service and grew to a work management system for tens of thousands of people. You need to understand that each company has its own processes, software, traditions and rules that the new software must comply with. To make users feel good, we had to do a lot. For the user, this “very much” is expressed in the number of functions and configurations of the workflow. Along with such flexibility, we could not help but notice how our interfaces became more complex. We understood that diversity makes choice difficult, increases the likelihood of error, and the time to complete a specific action. The product seems complicated to users, and this always negatively affects the conversion.


Imagine world a product in which the interface contains only those features that a specific user needs. There is no unnecessary information, there is no onboarding into unnecessary features (unnecessary is determined by the needs of the user), there is nothing useless at all, only the essence of what makes sense and is necessary for you to work. I swung at this – personalized interfaces for each user. The first thought that crossed my mind is that it’s obvious that the whole world is striving for unification and personalization at the same time. In other words, increasingly simple user interfaces and increasingly sophisticated backstage mechanisms. But since this is so obvious, what has nobody else done? And they didn’t, because it’s not so easy.

Having thoroughly thought over my brain, I made a list of difficulties that a dreamer might encounter on his way to utopia. So let’s go!

What tasks to solve

User Role in Company

Different buttons must be hidden from different users, because managers need planning, stakeholders need reports, end users need tasks to complete, and guys in the fields need Requests (sorry, but I’m afraid no one will understand me if I write “Requests”). The product must know what function a person performs in a company. You can understand this by interviewing users within the product, but who fills them … And yes, we can’t demand this: people paid for the service, and not for the polls we needed. So the person’s function will have to be recreated through all available open sources: social networks, blogs, disk bases from commuter trains. Our product is a project management platform, so the roles are such, however, you can try to adapt this example to your specifics.


Suppose we know the position of a person and based on this we can assume how he works with the system. Now we need to solve a number of UX-questions: “How and where will we hide the function that the user does not need?” or “How will the user find the desired function if it is hidden?” It is important to understand that the flexibility of interfaces must be prohibitive, and the principles and rules of their development should be iron. Defining these principles may require a review of the entire design system.


When questions from designers end, the task turns into a four-dimensional Rubik’s cube. After the development is connected to the game. Usually, if the product is large, then the development team is rather big. To apply the rules that the designers have formulated, all developers should use common UI components for the entire platform (UI Kit), and not create new interfaces at every possible opportunity. Using such a system may not be so difficult, but for a start it would be nice to have one.

Introducing the Product (Trial)

Even if we assemble all the interface elements into logical groups, the following question arises: “Which of all possible product configurations should be shown to trial users?” We don’t have historical data on their work, we don’t know their processes, and our average indicators for the industry (relevant, as it seems to us, for this person) are more like a tangle of use-cases.

Knowledge Exchange

If we talk about existing users, then let’s look at this case: it happens that customers share their experiences, and this is expressed in such dialogs: “Yesterday I found such a button, I did everything in one click!”, And the other answers him: “And show me where! ” It turns out that one user has this button, and the other has a void in the same place. Bug? Feature? Access Settings? Full moon?


Rather mature projects require special attention, because in many places the devil will break his leg. Before showing the flexibility and beauty of interfaces to the user, you need to properly refactor the code.

Yes, there is a lot of obscurity. But let’s turn to what we can get if we try to implement a similar approach.

What will win the product and business


As a developer in the past, I cannot but mention the advantages in terms of code. As soon as the engineers are told that now there is a flag that determines the visibility of a particular element, and you need to respond to it, the code immediately becomes less connected, more abstractions appear, the development speed increases, the number of satisfied developers grows. These are not my fantasies, but an experienced stage. With due attention to the approach, you really can optimize your development.


By organizing the knowledge about your users, you can determine the patterns of product use depending on the size and type of audience, country, taste preferences, time of day, and indeed in general. After a while, you will conduct a manual analysis, accumulate enough data and share it with ML. There is a good chance of getting interesting patterns. For example, clients similar in processes may not be familiar with some functionality. This will be an impetus to introduce them to her. Or it turns out that customers from different industries have similar processes, etc. However, there is a limitation: if there is a huge variability of actions in the product, then, starting from a certain size of a company or account, patterns are more difficult to find. Therefore, it is worth creating atomic workspaces according to the functions of people in them, in order to at least somehow scale up to large clients more or less efficiently.

A couple of examples:

  • scrum-team whose work tasks / projects / pictures / documents are stored in one place in the system;
  • development department, organized on the same principle.


Interfaces in the product will also become more thoughtful. A clear separation of the functional and its grouping will appear. The entire movement of the product will be aimed at the unification and systematization of interfaces and user experience.


As I said, there are a huge number of use-cases, and what suits one is not an option for others. Such a need for process flexibility arises when a product is deployed within the real conditions of a company and when processes must be built with a large number of introductory restrictions. If you know the industry, then you can make assumptions about what functions users of a certain type may need. This knowledge can be used when onboarding into a product in order to convey the value to the user as soon as possible and affect its conversion.

User experience

If you look at specific software (for example, for a factory), there will be an explicit division into operators who control the flow of data through complex interfaces and artists who work only with the final tasks, designed in a minimalistic interface shell. In general products such as Wrike, it’s difficult to break down an interface into specific functions. But still, you can try to find general patterns of work and try to present them as a lightweight interface. The simplicity of working with such a system will leave a pleasant impression on the user and affect his return to the product. In the second part of the article I will show how this can play profitably for you.


Any growing entity in this world will inevitably divide, so as not to gain a critical mass that will slow its movement. Suffice it to recall the products Atlassian or Sales Force ten years ago.

This happens, in my opinion, for the following reasons:

  • The product becomes popular and appears on the markets of related industries. To stay in these markets, the product must meet customer needs well. Therefore, you need to develop new functionality. Moreover, part of the existing functionality is useless. A decision is made to make a separate product in which there will be no extra opportunities.
  • Current industries do not stand still – this is how emails, chats, document management and accounting systems came together and formed the industry of joint work management (although this was not exactly the case, but I hope you understood the analogy). As a result, the existing market has transformed or even divided into two, and the product has already appeared in several markets. Along with this, the needs of customers have grown.

Speaking from a technical point of view, a significant part of the server logic can be used several times. For example, notification delivery systems, authorization, encryption, etc. already exist. And all this can work for us. From the development side, only the correct configuration and some expansion of functionality are required.

Now let’s imagine the situation that we are entering a new market: a lot of new development, MVP, investors are pushing forward and stuff like that. The code base is growing like mushrooms after rain, and after several such expansions it becomes very difficult to maintain it. A decision is made to divide the product into two, three or more. Probably, such a decision will raise the hair on the head of every person in the company. In this article I will not touch upon marketing, legal aspects, etc. and while I’m talking about the product and engineering part. The cost of splitting the code base will be colossal. Thousands of man-hours of refactoring, testing, and millions of dollars. And this is just engineering. A component redesign will also be required from the UX side. But a pleasant surprise awaits you: the separation will not be so painful if you wrote loosely coupled code and UI from the very beginning. And this is exactly what the code base and appearance will be in the development of dynamic interfaces. I know this sounds a little utopian, but think about it a bit, talk to your developers. I assure you, that makes sense. Moreover, this flexibility will allow you to quickly enter new markets and create vertical solutions that specifically cover the needs of users.


It turned out to be a good balanced concept, in which there are enough pluses and minuses. Good because not the price of development, but your strategy determines whether it is worth implementing it or not. But this article is more about reflection: a kind of introductory set for those who decide to try to implement such a concept. You can approach the development of this idea from completely different angles and the final results are very variable. In the second part of the article I will tell you how we started this path and at what point we are now.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *