Designing for UX: It is Not a Good Thing Always

UX

Yes it is true. Designing for UX is not a good thing always.

You must be thinking that I have gone completely insane. Everyone knows how important it is to give the best user experience to your user. After all, all that matters is the user, right?

But over the years of designing Enterprise level web applications, I have realized that designing for the best user experience is always not the optimal solution. And I will show you why shortly.

What I have seen is that instead of always concentrating on UX, it is better to concentrate on what is better for the user.

Isn’t this the same thing as what UX stands for?

Well, not quite.

What is better for the user in terms of functionality may not always deliver the best user experience.

Let me try to explain this with couple of real world experiences I had.

Designing for Optimal Functionality, Not User Experience

In one of the projects that I was involved in, we had to design a simple interface that was supposed to have just one single table with 4 columns.

Let us call these columns Column A, Column B, Column C and Column D.

Users were supposed to enter values in each of these 4 columns.

Now, we had to design another interface from which the user would input values for either Column A, Column B or Column C. Then depending on what values were provided, we were supposed to display the value from Column D on that interface.

Please note that I am generalizing the example so that everyone can easily follow. The actual design use-case was quite complex than this but the core idea was what I have explained above.

The customer wanted that the users should be able to enter values in each of the cell of that table as a single value or a comma separated list of values. Something like shown below:

Table with Multiple Values

Now, if the users entered just one value in each cell of the 4 columns then the logic to display the value of column D was very straightforward.

So, in the above example, if the user entered “Value 1” for Column A then we would display “Value 4”. And if the user entered either “Value 2” or “Value 3”, we would still display “Value 4” as the answer.

However, in the second row of that table, you can see that the customer wanted to enter “Value 5, Value 6 and Value 7” for Column A. Similarly for Column B, multiple values “Value 8 and Value 9” had to be entered.

Now the expectation was that if the user entered any of those value “Value 5, 6 or 7” for Column A, then we should display “Value 11” as the output. Similarly, if the user entered “Value 8 or 9” for Column B, then we should display “Value 11” as the output.

Further, the customer needed that if the user enters “Value 6” for Column A and “Value 8” for Column B then too we should display “Value 11”.

You can easily see that having multiple values in one cell was going to make things complex.

Practically we could write intelligent code to read values from each cell and then separate out each value because each of them are separated by a comma. But then we would be guessing that the user always separates the values with a comma. What if the user separates the values with a semi-colon, something like this: “Value 5; Value 6; Value 7”.

We could ask the customer to train their employees to always use a comma. But then too there are chances of human error. And also, if we were to sell that same web application to multiple customers, we would have to ask each customer to remember that they should separate the values with a comma.

The best solution was to ask the customer to strictly have just one value in each cell of the table. So the table would look something like this:

Table with Single Value

With this kind of an approach, there was no dependency on how the values got entered. We would treat value of each cell of the table as a single value in itself.

But this approach is fine for a small set of values. In our case, the customer wanted to keep around 15 values in a single cell of Column A, 20 values in Column B and 2 in Column C. So if we were to split these values in separate rows, the customer would have to create 600 rows for covering all the possible iterations (15 x 20 x 2).

Anyone with the slightest knowledge of UX would scream at us for suggesting this design.

But let us think from a future scalability perspective.

Today, the customer wanted a simple OR and AND condition between the columns. But if tomorrow they want to write complex arithmetic equations or logical functions on top of that table, having multiple values in a single cell would be problematic.

What if the customer wants to create intelligent reports on top of that table? Having multiple values in a single cell would make it harder to generate such reports.

Also, we need to take into account how often that table was going to get updated. In our case, that table was part of a setup activity and would get updated once in 3 or 4 months.

So, even if we could possibly give a better user experience to the user by allowing multiple values to be entered in each cell of the table, we did not do it. We mandated that the users enter only one value per cell.

Because that was the best thing for the user even if the user experience took a hit.

Designing for the best UX is always not the best thing for the user.

Let me be clear on one thing. In our case since the customer had to enter that large number of rows into the table, even if it was once in 3-4 months, we did provide a way to the users so that they can upload an Excel with each cell containing multiple values and we would read that Excel and create the necessary number of rows in the table. But then we mandated that the values in the Excel be always comma separated.

Obviously it still does not give the best possible experience to the user but it did remove the pain point of manually entering large number of rows.

But in no way did we compromise on the need of having a single value in each cell of the table.

How Amazon Scarifies UX

Sometime back I had written about how to design an interface for bulk upload of data.

In that, I had shown how Amazon allows it’s vendors to upload their product data in bulk. Basically, Amazon gives an Excel file that the vendors are supposed to fill up and upload to Amazon. That Excel file looks something like this:

Amazon Category Template

As you can see, the Excel is highly structured. If you mess with the columns, the entire upload would fail.

What it means is that the vendors have to now invest time to fill the data in proper columns.

Imagine that a vendor has 5-6 suppliers of his own who supply different products to him. He in turn sells them on Amazon.

Now say every supplier sends him his own list of product data that he supplies to the vendor. Our vendor then has to consolidate all the product data from all the suppliers and then fill it in Amazon’s Excel sheet. He can either do it manually or build a custom application to get this done for him.

But still, is this a good User Experience?

Absolutely not!

UX does not mean providing only the best User Interface and User Interaction within the application itself. UX starts even before the user has logged into your application. Like in Amazon’s case, User Experience starts with creating the Excel.

Unfortunately, many of us miss this point.

We restrict our vision of UX to only how the user would interact with our application and do not bother about what happens before and after the user has started using our application.

Now, even if the UX takes a hit, Amazon still does it. And the reason is that it’s the best solution even if it is at the expense of UX.

If Amazon allowed every vendor to upload any Excel file, then imagine the chaos Amazon would have to face in streamlining all the data.

Providing a scalable and robust solution is sometimes better than providing a better UX.


Your Turn

I know some of you will still be shaking you head, but when it comes to designing web applications, the same set of rules of website design do not apply.

People buy web applications to solve a problem or a need. They are more interested in what the web application can do for them instead of how it does it for them.

Please do not get me wrong. I am not saying that you should sacrifice UX at any time. UX is extremely important in web application design as well. But UX should not be given preference over a robust and scalable solution.

Atleast that is what I think.

What do you think?

I would love to hear your thoughts as well.

There are many such things that make designing for web applications different from website design. And specifically when you are designing those web applications for businesses.

About The Author

4 thoughts on “Designing for UX: It is Not a Good Thing Always”

  1. I don’t understand why “having multiple values in a single cell would be problematic” – the table is just a view of the data, the data model is a whole different story. I would use a nested array to the store the data, and recommended a document store to persist it (although there are extensions for RDBMS for JSON as well).

    1. Technically you can do that. But say if the users want to write expressions (in the UI) on top of the data displayed in the table, then it much easier for them to write something like ColumnA * ColumnB in the UI than writing a piece of code. You can provide a separate Expression Builder UI with certain Mathematical, Logical functions that they can use to build the expressions right in the UI. This will be specifically helpful for users without any programming knowledge.

      For example, if the table has two columns, Length and Breadth with values 10 and 12 respectively, then you can provide the users an Expression Builder UI where they can write Attribute1 = Length * Breadth, where Attribute1 is an attribute/field in the application.

      If you had just one column in the UI say LenBrd displaying both Length and Breadth in the format 10,12 then it becomes difficult for normal users to think of a way to build an expression for multiplying the values.

  2. This article certainly helped a lot to think of this scenario from diverse perspectives! 🙂

    I agree with the suggested approach envisioning scalability, as long as there are such values (across different columns) that need to be computed anytime later in future by varied degree of complexity.

    Otherwise, “inline multiple rows within actual row of record” will definitely improve the User experience while offering efficient way to key multi value inputs when its said to be just those values are cross referenced (to the rest of the data in that particular row) but no computation done on them to produce output on another column.

Leave a Reply to Abhijit Rawool Cancel Reply

Your email address will not be published. Required fields are marked *