Overconfidence vs. User Testing

David Linke
The Startup
Published in
5 min readFeb 24, 2021


As designers we may sometimes fall in the engineering mindset of solving multiple issues with the least elements possible. This is actually not a bad practice. You take into account all of the requirements, come up with a UI that satisfies the acceptance criteria, you even take into account the time that it's gonna take to fruition and try you best to satisfy the customers expectations.

If it sounds complicated, well, it's because it is. Trying to balance all of these factors is not easy breezy at all.

On this article we are going to talk about having to compromise for the sake of efficiency to later have your judge (the user) say the last word.

Standardization and normalization

The case in question is about a page with a large dataset displayed in tabular fashion. When we first encountered this page, we detected several flaws in the responsive implementation of it. The data filters were located in the headings of the table, and of course, when switching to mobile, the filters had to be presented in modals, as there were no more headings to attach those to. The UI was not executed brilliantly, so it caused more confusion than it helped.

This triggered an exercise to create a system that could adapt to these situations, which ended getting rid of table-heading filtering to implement a modal based filtering flow that you find frequently nowadays. By doing this, both desktop and mobile artifacts would work the same way.

The modal filtering implementation.

We anticipated that this could represent an initial learning curve for some users, but there was the certainty that they could go through it without much hassle.

That one product manager.

We started executing the task of changing all the filters within the product, and one day during this process, a product manager requested to implement table-header filtering in a new feature. We of course explained all of the issues that this represented backed with the evaluation we made, product benchmarks and a list of benefits derived by the modal approach. He fiercely insisted that table header filtering was the proper way of doing this because he better knew the ways of the customers and all of those things I'm sure you all have heard at some point.

This of course has got to be handled the best possible way for the sake of having a good work environment. Since this is a common occurrence in product teams, we had set ways to solve such conflicts in the past, and it is by going directly to the customers and conducting user testing for the artifacts in question.

We created actual software prototypes of both implementations, one with the modal filtering and one with the table header filtering.

A screenshot of the heading filtering implementation.

We also fixed the flaws we encountered in the implementation that triggered all of the changes so that the header filters were prepared to satisfy all the requirements. Everybody was on board with the prototypes and we narrowed the focus to desktop only, as it was tacit that both mobile implementations had to use the modal variation.

A day in court with a jury of your own users.

This is a very humbling moment, especially if you get to see how the users are conducting themselves through a piece of UI you have come up with.

There were around 10 users that took the time to do this. All within our target audience, construction professionals 40 years to 55 years old.

They were presented with the modal artifact first, and despite having some friction with it, they managed to execute the filtering (as we expected when we changed it the first time). Then they were presented with the header treatment and oh boy they liked it. It was incredible to see that they were magnetically drawn to the table headers to click on them and filter in less than one second.

At the end of the interview they were asked for their preference and of course they all answered that the heading treatment was preferred. Many said that both were good, but since their day to day software experience revolved around Microsoft Excel, they felt it was more natural filtering through headings.

You can have a glimpse of one of the interviews. It’s in spanish, but captions are provided in english.

Lessons learned

Well, not much to say, we gathered the information of the test, and streamlined the heading treatment for filtering to be able to achieve all that we wanted our customers to do, and again, after all the years of experience I carry, nothing beats user testing to be able to determine if what you are doing is the correct way to move forward.

A final iteration of the header filtering with added functionalities.

Although the header filtering was more time consuming to develop than the modal one the company had to decide if it was worth the time and money to build it, and after watching the videos, it was pretty evident that it was.

Last but not least, being humble is essential to be a great UX professional. Our profession has an intrinsic level of arrogance, after all we signed up to define how people should behave around stuff we create, that alone requires high self esteem. However it also requires you to open up to the ways others use the things you come up with, this by no means goes against what you have learned in the past, it only represents a lesson for what you'll create in the future.



David Linke
The Startup

UX Professional, User Advocate and Product Developer.