For my projects, I mainly use the ReactJS library. For the matter of this article, it is not so important what tools you use, as provided information will be more abstract and general. Let’s begin with the basics.
Don’t ruin the first impression
When you see something for the first time, your mind constructs the famous “first impression.” It’s a cognitive process that decides whether you like something or not.
We can all agree that it’s tough to “fix” the first impression. Everywhere - even in our personal lives. It doesn’t matter whether we meet the new person or - open a new application we want to start using. In software development, especially in a startup-like environment, the first impression determines whether people will stay with your product longer, or leave it.
Making the great first impression of the product is mainly on our shoulders as UI/UX designers and developers.
Which aspects can destroy the first impression of the app?
We have described the importance of the first impression, now let’s see which aspects can destroy it the most.
Many factors can affect it, and these factors can vary for each person’s individual experience.
My classification would be:
Let’s describe each of those in more detail.
An example of low accessibility would be the page that asks you to enable notifications, even before it has shown you any content:
We have to remember that any application you build gives value to the users. They are using your digital product because it meets their needs. With this in mind, a better solution for requesting notifications would be showing the popup after satisfying customer needs, so after the page content has fully loaded. Another possible solution would be putting notifications management in the account interface. These are only a few examples of solving this issue.
Low accessibility also feels when we forget about the responsiveness of the page elements like buttons, form inputs, or text. Browsing the web on my smartphone, I often observe that those elements (e.g. date pickers) are too small or placed in wrong locations, that I can’t reach them with my right thumb. There are plenty of examples of low accessibility connected with the responsiveness of the application. To not write them all here, I’ll just sum-up this section with the illustration coming from the designer-websites blog. I think that this picture can describe the importance of this kind of issues:
The second aspect of my classification is poor performance. It’s hard to admit it, but I’m quite sure that this issue is mainly the responsibility of programmers. We often test our application in the development environment; on fast, modern devices, when we have a very stable network connection. So we start to forget about the users—those users who don’t necessarily have the most powerful smartphones and laptops and strong wifi or mobile internet connection.
Network problems can affect everyone - remember yourself in the tram tunnel, waiting for an application response.
The above chart shows the importance of a “mobile-first” approach in building web applications. We have to accept that more people nowadays browse the web using mobile devices. And generally, smartphones are about 4 times slower than PCs and laptops.
If you don't want to imagine anything, I can say that the network in your home can sometimes behave as in the picture below :).
The design itself is an art, and it’s hard to describe which exact design solutions can ruin the user experience. This section is supposed to be very short because instead of showing the concrete examples, I just wanted to redirect you to an interesting experiment. The author of this page showed how the worst case of user experience would look like. I encourage you to sit down with your design team and look again at the decisions you made a long time ago. There is probably something that needs improvement.
Making web applications more usable and user-friendly
Here comes the part where we list the things you can do as a developer to make the product better. Fortunately, we live in the days when the development tools give us many options.
The two popular ways of rendering web application content are Client Side Rendering (CSR), and Server Side Rendering (SSR). The client-side rendering, as the name suggests, happens on the client-side, so that the browser necessarily downloads the source code for an application to start, and then executes it. Server-Side Rendering, in turn, does the “first render” of the content on the server-side. There are a couple of benefits coming up from this approach. Those are:
- Performance boost. The first render of the application happens on the server, that in most cases, generates the page quicker than the user's device.
Progressive Web App (PWA) features
PWA is the type of web application that behaves almost like natively installed software on the device. Using the technology called Service Worker, we can let the application:
- work offline and be more performant - that levels up the accessibility;
- have background synchronization - it’s useful for complicated interfaces flows like chats or payments when an unstable network can break the user's operation
- have push notifications
- be added to the home screen on a mobile device (yay!)
Including some of the above features will make your app respond much faster. It may also reduce vulnerability to network failures while maintaining a high level of user experience.
There’s a lot of places on the Internet where you can learn more details about PWA. I recommend you start here - Progressive Web Apps.
Perceived performance, in computer engineering, refers to how quickly a software feature appears to perform its task. The concept applies mainly to user acceptance aspects.
Perceived performance is a relatively rigid definition. To understand it, we first have to find out how people perceive time.
People perceive time differently, depending on the situations that are currently happening in their lives. One of the most simple examples can be a situation of boiling water for coffee or tea. When you stare at the kettle until the water reaches 100 degrees Celsius, these few minutes feel much longer than when you use the same time for more exciting activities like a conversation with friends or watching a movie.
This mechanism applies to web applications when the request for data from the backend server takes a long time. For this article, let's say that the frontend request for results that we display in the table takes about 20 seconds. According to google studies, seconds decide whether the user will stay on the site or leave it, that's why the website loading speed is crucial.
Instead of showing the loading spinner for 20 seconds (which is annoying), we can first ask the server how many items we should expect. Since it's a much less expensive operation for the backend, we should get a quicker response. Then, based on the received number, display the placeholder for each item, and request each row's content. Look how youtube uses the same technique while loading videos for you.
Here’s another example from the treehouse blog on how to “mask” the loading time.
To increase the developer experience, the atomic design was created.
Atomic design is a popular system for writing and structuring components. It’s the development approach that gives you reusability of those “building blocks” and hence, better scalability. The system is based on function composition.
As we know that every component is a function. In brief, atomic design says that you should distinguish your components into atoms, molecules, organisms, templates, and pages.
Each of those has their “roles”:
Atoms - as the name suggests, the smallest building materials such as buttons, icons, inputs, but also typography components.
Molecules - components that are crafted from atoms, having a more specific role or functionality. It can be a simple tile on the page, showing book title, description, and a “read more” button. Remember that it has to be “open” for any behavior, so in our example of a tile, we need to have the ability to pass a custom behavior (function) that will be triggered after clicking the button.
Organisms - A more “compound” component, basically - the composition of molecules and atoms. Sticking with the example of a tile, organisms would be the list of a few more tiles, maybe with the input (as an atom) to filter the books by the name.
Templates and pages - Templates are components that decide where all organisms should be placed, creating the full content of a page. In turn, the page is an instance of a template, with all the actual data you want to pass to it. The time to fill out all your components with data, no matter what data, happens in pages.
I grouped the last two elements (templates and pages) in one, just because I think that atomic design shouldn’t be a rigid rule. Reality will show you that sometimes you need to bend the rules a bit, and the more you learn about the app you are working on, the more you'll see which level of “atomic part” you can leave. For example, your app can be small enough to leave the “pages”, it could be a mistake to introduce unnecessary division there.
Here you can learn more about atomic web design, straight from the author of this concept, Brad Frost.
When it comes to perceived performance and a scalable component's structure as atomic design, I like to compare them to listening, or even creating music. We can compare the atomic components to instruments, chord scales, vocal, and different effects because they all have their level of complexity. They mean a lot in the acceptance of the song, but they are not the full track yet. The mood, that particular song creates in your head, is also determined by the way we spread every "music element" in time. In web development, the way we manage users' time is significant, and you have already learned it in the previous section.
You’ve just read about some tools and techniques to build a better web application. However, it doesn’t mean you should apply them straight away. First of all, I encourage you to understand better the business model of your product you are creating. A conversation with your development team and the client will help you designate which functionalities are worth implementing and which are not.
You also have to remember who is the target group of your application. It can be people who browse your app only on smartphones, and you should provide them higher overall performance. Be wise and discuss with the team or even do research on - which functions do they really need? Are the push notifications necessary? When your app is only for desktop devices, behaving very performant, the only thing you should care about is the high accessibility of its features. It all depends on the project you are working on.