You are a Frontend Developer. Your job is to implement design and requirements. But it should not be limited to that. You can bring your own expertise to the table and suggest ideas aiming to improve the user experience.
In order to do that, you need to understand the domain of the project (e.g. healthcare, education, logistics, etc.), the project itself (what problem it solves, why it is needed, how it is solving the problem), and then your end user. Try impersonating the user, forget the requirements (your users don’t have any idea about them) and see if the flows your team is building are making sense, or if there are better ways to do it. Try to make their life easier and provide an enjoyable experience.
If you have big ideas in mind, reach to your manager and UI/UX designer and let them know before implementing them, to avoid any friction. If they’re only small improvements (e.g. loading skeletons, interaction transitions, etc.), go ahead and surprise them (or don’t, you know better if they like surprises). In any case, tell them what and, more importantly, WHY you want to do it, frame it through the lens of the user's pain.
Identify what’s wrong and fix it. For example:
- the searchbar goes out of view when scrolling the results list? It might be a good idea to make it stick into view and make the results list scrollable;
- there's a layout shift when loading data? You might want to add a loading skeleton, even if the requirements or design don't mention it;
- the users might not understand why their call to action is disabled? Add more context to improve their understanding of the flow, maybe a tooltip is enough;
- the form has errors but they're out view? Then automatically focus the first field with an error, don't just leave it like that.
Let’s look at some of the examples listed above in more detail, so you’ll understand why they will be an issue for your users and how to mitigate them.
Avoiding layout shifts
Whatever your business is about, your platform should be fast and snappy. Users might be in a rush, everything is moving at high speed, and your application should consider this. Changing the layout of the page after the initial content loads is:
- affecting you web vitals score (CLS metric);
- affecting your end user’s experience;
- making your platform look sluggish.
Imagine a banking application, that your user uses often to make payments. They know the “Pay” button is in the same place every time they open the app, but in reality it’s being shifted by a promotional banner that appears after 2-3 seconds. They open the app, attempt to click the button, but the banner gets in the way just as they’re about to click the button, and they end up clicking the banner, opening a new page, which they have to close, open the banking app again, unlock it with the fingerprint again, etc. I’m talking about my bank’s app and it’s not a pleasant experience. So don’t do this.
You can see in the video below what I mean:
To mitigate this, you have several methods available:
Preload the information: if possible, determine the state of the UI before the initial load. You can do this using:
- server side rendering in frameworks like Next.js, Remix/React Router 7, TanStack Start, Nuxt, etc.;
- if your router library supports it, preload the information before rendering, client-side. TanStack Router supports this using `ensureQueryData`, in combination with TanStack Query and React Suspense.
Use a loading skeleton: if you know for sure something will be displayed, but the client needs to wait for a response from the server, use a loading skeleton to fill the layout until the data is available. You might need to use some fixed values for width and height for the skeleton to work as expected, so make sure your designer understands the implications.
Use absolute positioning: if you can’t preload the data or if it’s not a guarantee that you should display something (let’s say you implement a feature that might display a banner, but first you need to check some data coming from the CMS to determine if something will be displayed or not), find a design solution that can be displayed using absolute positioning. This way, the layout of the page won’t be changed after the data was loaded. Ideally, you’d give your user the option close the banner so it doesn’t get in their way.
Another thing that leads to layout shifts is fonts loading asynchronously. A small thing to greatly improve end user experience is preloading fonts. This way, the layout will be painted with the correct font from the start.
Building predictable UIs
Imagine you’re building nice, shiny, performant features for your users. But, because the business rule say so, they don’t have access to some of them. So you (or your PM, your designer, or anyone else involved in the project) decide to just hide them. If the user can’t use them, why would they see them, right?
Well, that’s not right, at least in my opinion. Your user interface should be predictable. You need to guide your users and build an enjoyable experience. You need to provide context to your users so they better understand your product and see what they’re missing. It could also drive sales up if we’re talking about paid features.
Sometimes it’s as easy as adding a tooltip to explain what a button does, or why it is disabled. Other times things could get more complicated, but it’s your job to find a solution.
For example, see the fragment of UI below:
Your users look at the buttons and ask themselves: “What do these mean? I can see that I can abort the current operation, but what do the other two mean?”.
The design does not include any tooltips, right? But that shouldn’t stop you from adding some. Don’t even blame your designer, as they need to make one extra screen only for the tooltip, and if they can trust your mastery, you’ll make their life easier.
In the example above, we’re using icons for buttons. Make sure they are really a button, which is labelled using aria-label, aria-labelledby or title to make it accessible to screenreaders. Please don’t use a callback on a div or on an svg. If your icon redirects the user to another page, use an a tag, but also add a label to it.
Let’s take another example. You’re building a marketplace, and, for building trust in your platform, you want your users to leave reviews to sellers. On the seller’s profile, the user can see a button for messaging the seller, but there’s no “Leave a review” button. Their best guess is that there’s no review system in the platform. Why would you sabotage your product like that?
A better option would be to display the button as disabled, add a tooltip which explains exactly why they can’t leave a review. Don’t just hide the button, don’t just disable it, explain the reason to your users.
Guiding the users
When building a form, keep in mind that it you need to validate the input. As you probably know, it is very important to validate the data on the server, which is the authority. Data validated on the client cannot be trusted, because someone with a little bit of knowledge can bypass that validation easily. Client-side validation is still important, because it guides your users through your rules before having to wait for a response from the server (and it also takes some pressure off the server). You should add visual indicators to the fields which have invalid input, like error messages and colors to let them know something is wrong.
Now, you might have some very long forms in your application. Your user might fill all the fields, thinking everything should be alright, but your business rules say otherwise. After submitting the form, they have no clue why nothing is happening, just because there is an invalid field at the top of the form, which is way out of view. To avoid such confusion, you should guide your user by scrolling to the first field with an error and automatically focusing it. By having a concise and plain error message and scrolling to the field, it is obvious for the user that something is wrong and they need to revise their input. Avoid validating the fields on blur from the start because it might be frustrating to the user to not get a chance to submit the form and be yelled at. You can validate on blur after they’ve first submitted it. Guiding the users is not only about form validation and submission, this is a mere example.
Again, make sure to use aria attributes so screenreaders understand something is wrong with the form fields.
Closing thoughts
This article is not exhaustive by any means. With what we’ve discussed in mind, try to identify aspects of your product which could be better explained and presented. Put yourself in your user’s boots, forget about the business rules, and see if you UI/UX can be improved. Be a master of your craft and take pride in your work. If you want to become a master, act like one, but stay down to earth and don't let arrogance grow into you. Frankly, it goes beyond user experience, you could expand this to any field, be it backend, devops, etc.
Keep in mind, there's lots of people that can implement a design, and in the age of AI you're also competing with machines, but your true value lays within your expertise and knowledge portfolio, how you apply them and how proactive you are. A valuable developer is one that could be easily be labelled as a creator, not someone who just follows instructions. LLMs also follow instructions, even if they do it incorrectly, while being confident in their answers, and you need to know what you expect from them, otherwise it will be a game of assuming.
