Streamline Web UI

This article offers valuable advice on enhancing user experience, specifically focusing on aspects related to time management, reducing waiting periods, and avoiding mistakes in creating the user interface of web applications.

Instant Feedback to User Action

In modern applications, interface feedback to user actions should be immediate, even if providing a complete response takes some time. Immediate feedback helps users understand that the application is working. For example, highlight a menu item immediately after clicking on it and start loading the content, or instantly open a dropdown menu or modal window and display their data once it’s loaded.

Separate Loading and Moving Content

If some content on the page is heavy or takes time to calculate it, gather or load from the server, make a separate request to show lighter queries first and heavier ones later. This approach prevents delays in displaying easy data and allows parallel loading. For example, load the main menu, header, and service section’s name and description first, then continue loading other data such as lists of items and their details.

But be mindful of interactive content that can change its position after loading. The biggest problem users may encounter here is misclicks. Misclicks happen if elements move just as users are about to interact with them. For instance, a user may find the correct line and intend to click on it, but just before clicking, new data loads, shifting the content, and causing the user to click on the wrong line. This technique is often used with slipping banners that replace the main button, leading to user frustration.

You can safely display content at any time if it has fixed dimensions and won’t change position after loading other content. Display content from left to right and top to bottom without altering its position. Content that can shift significantly after loading other blocks should only be displayed when all other content, which can change the size and affect this block, has fully loaded or after an error occurs in loading these blocks. Avoid showing such content or blocking interaction with it until loading is finished.

Cache the data

Another effective way to quickly show data is by using the cache if the user has visited your application before. You can display cached data initially, send requests, and update the data upon receiving a response. This method also helps optimize application performance by avoiding excessive server requests. 

However, using cached data can lead to content shifts and misclicks. Of course the easiest way to avoid this problem is not to use cached data, especially if it may be outdated by the time the page is viewed. Just always show the newest data.

But again, if you use cache  — you need to determine the average time at which data becomes outdated and adjust the application accordingly. 

There are two ways to work with cached data, based on how frequently the data might become outdated:

  1. Frequently Updated Data: If data often becomes outdated during a page view, do not use the cache. Wait for the server’s response and always show the latest data.
  2. Infrequently Updated Data: For data that remains the same across different page views but occasionally becomes outdated, use the cache. Simultaneously send a request to the server to validate the data’s freshness, and do this periodically.

Once we recognize that the data is old, carefully replace it to avoid misclicks. For example, display a message saying, “The data is out of date and needs to be updated,” prompting the user to click the “Update” button and wait for the new data. During the update, hide or block old data and show a loader.

Spinners loaders and skeletons

Spinners, loaders, and skeletons are common UI elements that indicate an application is working while content is being fetched or processed. Of course you know and use it often. Most likely — too often.

You can’t use skeletons or spinners if the page loads quickly!

If the page loads in less than 1 second, skeleton screens, loaders or spinners are not needed, as they will not positively affect the user experience. If the delay of appearing new data is less than one second and you have given the user immediate feedback on his action, the user does not notice a delay of application response. And using loaders in these situations can be frustrating, as a fast-flickering page can make users feel like they can’t keep up with the fast changing content. It creates a feeling of strange behavior and slow performance of the application.

But what if we cannot know whether the page will take a long time to load or not? 

Of course, we can’t know everything in advance, but we can not show loaders or skeletons for the first time.If unsure about load times, use a short delay (500-1000 milliseconds) before showing loaders or skeletons. Incorporate a fade animation for these elements. This way, if the page loads quickly, the delay will be almost imperceptible to the user. 

An attentive reader may notice if the page takes slightly longer than 500 milliseconds to load, users still might see a flickering loader.

Even though this won’t eliminate flickering entirely, it will significantly reduce occurrences. If you have data on average page load times, adjust the delay to further minimize this effect.

Thanks for reading! If you agree with these statements, share them on your social networks or channels!

Design system

Below are my slightly edited, supplemented and translated into English answers to Sasha Efremov’s questions for his articles on Medium and vc.ru about design systems.


I have been working in Kontur for more than 10 years. For the last 5 years I have been working on the Kontur.Guides — the design system for 50+ product teams, used by 100+ designers and 200+ front-end developers, and serving 3 different platforms.

I must say firstly — all the texts of the guides, components and libraries are the result of a long and thorough work of many Kontur’s designers, UX-researchers, analysts and developers. Guides and libraries are maintained by a separate team. I was the leader of this team for a long time, now I combine the roles of analyst, writer, interface designer, tester and product manager.

What is a design system?

A design system is a complex organism that has a single source of truth in design tokens.

In my understanding, a design system is a tool that helps to create and maintain an unified user experience on interacting through different company products, as well as optimize the company’s costs for creating these products.

A design system is a synchronized library of components for designers and front-end developers with a detailed specification, documentation, a set of examples, and a list of best practices. It is an organism that has a single source of truth in design tokens. It is a culture of interaction with him and a dedicated team to support him.

Why does anyone make his own design system if there are already plenty of them?

It is easier to influence your own design system and as a result it becomes cheaper over time

It all depends on the context: on the product, the project, its age and its ambitions.

If the project is just started and you need to make an MVP, you can make it based on any third-party free or paid library or UI kit. At start, a third-party library may seem overabundant, but over time it can become insufficient.

With the product developing, there will appear new requirements for components which will be difficult, long or expensive to implement using a third-party library. You will have to make your own components instead and gradually move to them.

It is easier to influence to your own system and as a result it becomes cheaper over time. Most likely, you will not be able to influence the development of a third-side design system, for example, from Google without being inside the company. Or it will be very difficult.

How to start creating a design system?

One option is to start a survey.

As always, you need to start with research. Most likely, the company already has some elements of the design system, and you need to understand how they are used in the company.

A design system is a product, you need to approach its development as the development of a product: find out from users what difficulties they have, what “hurts” designers, what front-end developers have, what difficulties there are in communication between them and in the implementation of the designers’ plans .

As one of the options for what to do, you can throw a survey on each of the roles and think about how to solve their problems. It may turn out that a design system is not needed at this stage. It will be enough to draw a general UI or formulate Design Language.

Or, for example, you have a common UI, but at the same time components are too simple for front-end developers, there is no consistency in their use and you need to provide more complex, but strictly unified components.

What is the most important value of a good design system?

A good system is quite flexible and responsive

If the change you need to make to the system and roll out to all products takes a week or two, then it’s a responsive system. In bad scenarios, changes can take years to roll out. Bureaucracy and sluggishness are the main drawback of any system.

Everything here will depend on how well you establish a relationship with the community and users of the system (designers, front-end developers and other roles), and how much they will be interested in intervening, influencing the system and helping in its development. Any system is a collective product, and it cannot be created by an isolated team.

The second feature is ease of use. If a designer or front-end developer understands how to use the system without reading long instructions, then most likely it is convenient, which means it is slender and not contradictory. Despite this, the design system will still needs a detailed specification and documentation.

How complex the components of a design system can be?

We make sample pages to help designers see the big picture.

You can go until the component becomes so complex and big that it will be used only as an example of a template that must be detached (if we talk about components library in Figma). At the same time, the detached component is still assembled and consists of smaller components — elements of our design system.

For example: When we work with modals or some dropdown menus, designers detach and modify them. As a result, the modal no longer works as a component, but goes into the template format, but consists of such components as a header, a buttons panel and so on and so forth.

We also produce screen templates to help designers keep everything consistent and build on these templates to create new products and understand the principles embedded in the design system.

Such patterns can no longer be called components of the design system, but they are still its constituent parts and the continuation of the application of uniform principles on a larger scale.

What are design tokens?

Be prepared you will not be able to build a sufficiently flexible and harmonious system at the first or, even, second time

Design tokens are one of the “sources of truth” for a design system, along with the specification of components and rules for their use. The token system helps reduce the time to make changes, increases flexibility and reduces development costs. And tokens also help the designer and developer to understand each other and communicate in the same language.

Right now, our design system still lacks a simple and coherent token system which could be a single source of truth. There is a fairly large set of tokens, but it is still difficult to understand and it does not have a specification and a unified naming system.

Be prepared that the first time you will not be able to build a flexible and coherent system, and at some time you will have to rewrite everything, maybe even more than once.

How to make changes in components and not to break them in products?

We divide releases into major and minor and release version with breaking change about once a year

In front-end libraries, we adhere to the standard semantic versioning convention, so we try to postpone critical, breaking updates for major releases, and as part of minor updates, we maintain backward compatibility, support all current components, carefully add new features and fix bugs.

Components, we are going to remove, will be deprecated In the major release, and we will remove them only in next one. That is, designers and developers have a whole year to replace obsolete components to new ones and rewrite the code for the new API.

A little earlier than for the frontend, we release a new library in Figma and also try to support it without making breaking changes. For stability, all changes in the components are tested by screenshot tests, including those in Figma.


At the moment I’m not looking for a job, but I’m open to offers from companies with development offices in the EU countries. If you need a lead designer — write to me in telegram: @dzekh.