Wrong mindset. Wrong decisions.
For a long time I wanted to write an article about how people make wrong decisions based on their mind set, whether it's related to UI/UX, design, development, or even life.
Finally, I decided to do this.
I haven't posted in quite a while because I realized I had taken on too many tasks at once. So, I decided to focus on one project for a few months.
I collaborated with an Armenian teacher to create an Armenian language course, which may not interest everyone. However, once it's finished, I'll share the UI decisions I made, which could be quite interesting
Nevertheless, I highly committed to my main project of the year: usability recipes. I'm confident that I'll be able to make it, so I encourage you to subscribe.
In this article, I will touch on many areas of our lives, mainly UI/UX, but also other areas. I'll break down each incorrect decision and why it was made. Here we go.
Some people, usually developers, CEOs, and managers, try to fit as much information as possible onto a single screen I encountered a similar situation in my own project.
We had a page or modal with a table that had many columns, and some of them simply didn't fit on the screen. The headings began taking up two lines, the columns were too narrow, and it looked pretty bad.
What was the suggested solution?
Let's decrease the font size, they said. Usually, the base font size is 16px, but if we decrease it to 14px, we can partly solve the issue. However, what if that's not enough? People keep decreasing it further, making it 12px. I've even seen font sizes as small as 10px or 9px. As a result, the information fits on the screen, but it becomes very difficult to read.
In Tailwind, the minimum font size is 12px, called `text-xs. I received a suggestion to create another class, text-xxs, with a font size of 10px.
Why it is a wrong decision?
As a result, we end up with:
- Barely readable text. I had to zoom in to read it properly.
- Not scalable solution. We cannot add more columns or data without making the font size unacceptably small.
What I want to highlight is the problematic mindset. Many people don't try to find alternative solutions; they are stuck in a "mind-box" and can't think of anything else.
What should they think about instead?
- Do users actually need to see all the columns displayed? In most cases, they don't. Rarely do users need to see more than 10 columns at the same time.
- How else can we group the information to maintain a readable font size without sacrificing functionality? Perhaps we can combine some columns, such as combining "First Name" and "Last Name" into "Name."
- What if we have a column with multiple buttons, such as "delete," "edit," "hide," and others? Could we use a three-dot dropdown menu instead?
- Instead of tables, could we use cards or other design elements and restructure the layout entirely?
- If the table is displayed in a modal, could we create a dedicated page for it to have more space?
- And so on.
And the main question we should constantly ask ourselves: what users actually need?
Don't treat the symptom, treat the cause.
This is similar to the issue I described earlier. With tables, it's impossible to avoid a vertical scroll if there are many items to display.
However, with general elements such as labels, forms, text, and pictures, people try to make them small to avoid the need for vertical scrolling.
My question is: Which is easier, zooming in to read the information or scrolling the content below?. Isn't it really such an uncommon practice to scroll down a site?
What's wrong with having a size that is sufficient for the elements to be usable and allowing the page to scroll?
Don't treat the symptom, treat the cause.
If you have a high density of information, it's perfectly acceptable to break it down into categories. Some people try to fit every setting, form, and piece of information onto the same page.
Have you noticed that popular SaaS services even have dedicated forms for actions like changing your password or verifying your phone number?
For example, suppose you have a list of items, and some of them are archived, meaning they will rarely be used. Additionally, you have many filters for the list.
In this case, it may be best to have two pages: one for active items and another for archived items.
Usually you need to check active items, but if you need to, you can go to archived items in a click.
Don't be afraid to have multiple pages. Be afraid of putting everything on one page.
Remember, breaking down complex solutions into simple ones is always a good idea..
Miller's laws reads: The average person can only keep 7 (plus or minus 2) items in their working memory. It applies to everything I'm talking about. Tables, lists, pages, categories, filters and so on.
Group. Break. And Group again.
If I give you 50 lessons of English lessons without categories, you won't read them. If I break them into 10 categories by 5 lessons, chances will be higher that you'll end the course.
Another hint that you're treating the symptom and not the cause is using abbreviations instead of full names. Sometimes it's okay, e.g. IP address is a common abbreviation.
But if you try to use them to try to fit everything into one screen/table, then you are in the same trap.
Some things are more important than others.
Usually the content is primary, while filters, pagination, table headers, and so on are secondary. You should research and understand what is the most important of the page, and make it stand out. While other things should take less attention.
If you have a list of orders, probably they are more important than the date filter. Or at least equally important. But don't make the dates filter bigger than the list itself. (_Only if users are not CRM users that start their day by filtering orders or clients by date and its their primary action)
When you build your system, you operate with data. The data should be universal. I worked on a project where the backend returned data attributes that were called exactly as the table columns, even including table row numbers.
Not only it was redundant. The thing is, if I change the table view to list view, rename the table view, or do anything else on the frontend side, the backend keys should be changed as well.
Don't treat the symptom, treat the cause.
The data should be UI-agnostic. Flexible. Easy to use on desktop, mobile, TV screen, and my microwave. By trying to couple it with a monolith, you put significant constraints on the future development of the application.
To be honest, I'm not that concerned about "O-L-I-D" principles, since frameworks make it easier for us. But when you see that your controllers (or any other files) take 10 000 lines of code, it's a sign.
For some reason, people are afraid of having many files and many functions. However, if you go to the sources of Laravel (the framework that I use), you'll barely find a function that takes more than your screen.
That means that each function and each file are very "Solid Principle" complaints. Which is good.
Here I want to talk about the cost-effectiveness of a solution. Imagine we have a table with a live search and we need to make an MVP. The MVP should include a quick search across the whole table, but the search uses an AJAX request to the server. And we shouldn't have had the "Search button", so it should be an instant search.
Personally, for me, it was a challenge. The reasons are:
- We need to define, what is the optimal delay (when we use debounce technique) so that it's comfortable for users
- And we need to understand how to cancel requests if users type too slowly. In this case, there will be many asynchronous requests, and the table content will jump having different data depending on in which sequence the responses will come in.
I'm pretty sure the problem was that I didn't know how to handle that properly. But. Having the "Search" button unlikely will hurt, while it will increase the development of the feature drastically, and maybe even provide a better user experience. It needs further research, but it is possible.
Sticking blindly to one solution, which takes a lot of time due to different reasons (whether it's a developer incompetence, or any other problems that might occur) is worse than implementing almost exactly the same functionality with higher predictability, fewer bugs, and faster development speed.
This is not related to design or development. It's about our life.
This is my favorite cognitive bias.
Imagine you want to do something. Or you believe in something. Say, you believe that sugar is very dangerous for our health.
In order to prove it you google tons of articles that supports that point of view. And indeed, there are thousands of them. But here is the trick: you don't google the opposite point of view. There are, probably, thousands of articles that say that sugar is not that dangerous.
This is just an example. But that happens to us every day and every time.