You are not the customer. And here’s why.
It is hard to imagine that what is convenient for us can be inconvenient for someone else. But it is true. Teams often decide on the UI/UX based on their own experience, which makes the result not always suitable for the target audience.
An excellent example of this self-deception is given by Gayle Laakmann McDowell and Jackie Bavaro in their book when they describe a PM interview. A question is “what would you change in the product,” and the candidate passionately describes her pain points and how to fix them. Another example by UX manager and speaker Eugenia Casabona describes how she proactively redesigned the app and lead the release, assuming she knew what the customers wanted, just to find out the customers hated the new version.

The rationale for the error
Designers often work lacking information about the industry, the market, competitive products, and users’ feedback. Sometimes they create interfaces based on data and guidance from stakeholders who do not represent an average user. Or stakeholders can request dozens of edits to the initial mockup, all based on their personal experience.
There may be not enough resources to recreate the design at each iteration. The first approved version is often used everywhere, and then comments with “minor updates” are made for the technical team. E.g. you don’t update the initial mockup when marketing asks developers to remove a few options from a screen. Product requirements too, leave some room for free interpretation. Thus part of the design decisions is always left to the implementation team.
A trend exists to improve communication between the company departments, and many of us work in multi-functional teams. But many continue to work in silos, and many people work in outsourcing or with outsourcing teams, contractors, freelancers, where it is more challenging to build a seamless communication.
Why you can not put yourself in the customer’s shoes
The product creators have much more information than a user. We know the architecture, we remember the requirements, we saw the evolution of the product, we know the vulnerabilities, we know the content of the database. We have different domain knowledge.
We have our criteria for “it’s too long” or “hard to see” or “buggy”. E.g., before launching his product, Jacob worked as QA for many years. His management criticized him every time someone else found a bug. He has a low tolerance for bugs in his product, and he is afraid if a customer finds a bug. His partner Gary came from the marketing side, and it doesn’t matter to Gary that the system has defects unless they are critical.
The phenomenon of self-referential design, or namely how to avoid it, is usually mentioned along with user personas. It means that we subconsciously design the products based on our experience.
Please keep in mind that your customers:
- don’t know roadmap and future features;
- have no idea how backend works;
- are not hackers;
- may not be frequent users with a lot of data in their account;
- are used to another UX patterns (e.g. never used Linux or laptop), another bandwidth, another screen resolution.
So remember that you are not creating the interface for yourself.
What to do:
1. Do not treat interface as a reflection of your data model (and the roadmap)
No need to structure the elements on the page same as they are arranged in the code. Having the same data hierarchy and the same grouping is only intuitive, as long as you know how your backend works.
To illustrate that: on a screen the users can either import a file, or import from cloud, or copypaste data. You have three main classes FileImport, CloudImport, and ManualImport and subclasses within each(csv, GoogleDrive, and PlainText correspondingly). Only one subclass in each class for now, but you’ve discussed the roadmap with the management and more subclasses could be added soon. You create the following UI:
But the customers don’t care about your data hierarchy and want to select the import source right away, and can’t do it because it is disabled. They expect this instead:
Make it simpler for them and focus on actions they want to take.
2. No need to have literal accuracy
As with the design, labels and hints are edited at different stages by different people, and teams tend to label things to reflect the logic literally. In some cases it doesn’t solve any problem, but rather pursues some consistency in the author’s mind.
Like here, the dropdown is labeled “3 latest notifications” because only three of them fit into it. To see the whole list one should click “View All”. Does the customer care how many notifications fit into the dropdown? They do not, so why overwhelming them with this info. The goal is to show them what happened to their data, so labeling the dropdown “Notifications” is enough.
Another example, the only way to print a report is to download it as a .pdf first. So a customer opens a report they want to print, selects “Print” in the menu, configures the layout, clicks “Next” and sees a “Download .pdf” button. They are confused because the action they are looking for is “Print”. Rename the button to “Print report” to solve the problem. A person is not confused that a .pdf is downloaded, they know how to print it.
Or think about this: should the “unsubscribe” button in an email unsubscribe you from the transactional emails as well? :) Or should a process be literally named in a UI notification?
Always keep in mind why a customer needs the element in questions when labeling it.
3. Don’t use “internal” terms
Some hidden terms are not visible to the end-users. You can hear them a lot in any business logic discussion that includes technical details. You may have an ActivePeriod defined somewhere in the Reports class. But when a user sees the button “download report for the active period”, they don’t get it because “active period” doesn’t mean anything particular to them. “Download report for the last week” makes more sense.
Or, like in this case, the values of the toggle(0 and 1) are internal terms and do not represent what the user gets. It’s an exhaust hood control panel, and an engineer grouped the toggles for light, fan speed, fan mode, and timer in the same way.
Make it easier:
The terminology should be understood without extra context. Can you explain the term without referring to the specification or code? Can your friend understand it without you explaining?
4. Aim for the accuracy your customer needs
The level of data accuracy you can provide to the customer may be different from what they need. In fact, we can spend many hours improving the accuracy of a calculation just because we know we can do better. The good thing is to ask yourself who’ll be happy if we improve it and why.
E.g., the app gives a customer a playlist, 100 tracks each. A progress bar shows how many percents of the playlist was played. One can listen to a track, skip it, or dislike it. Backend-wise these are three different cases that can be treated differently when calculating the progress bar. But the customer only needs a rough figure of the percentage of content listened vs. left, and they don’t care if a track was listened to or skipped or disliked — so no need to add extra logic to improve the accuracy.
Or you calculate the distance of complicated routes, and the output has a 200 meters error. Is it good enough for the end-user? Do they need an exact distance? Or do they want a rough figure, and even a 2km error would be acceptable?
Or if we think about date-time format, the users will look for a higher level of accuracy in a product that provides debugging info then in a social network.
5. Think about loopholes where it makes sense
We know our product flaws too well, and it seems to us that users can take advantage of some vulnerabilities or imperfections. So naturally, we want to protect our system. But many times, the protection will cost more than the benefit it brings and will result into overengineering.
Imagine a web radio where you can skip only 5 tracks per hour, unless you have a premium account. How many users will try to skip more tracks by pretending they are a new user and starting a new session with a new browser/device/VPN? Some will, but very few. The users typically don’t want to interrupt a session just to skip more tracks. And to prohibit this behavior you need few developers and months of work and testing. On top of that, it complicates the system dramatically, making it buggier and harder to support.
Especially it doesn’t make sense to overthink the vulnerabilities in MVPs. Let’s say there’s a tools comparison article, and the website visitors could upvote for any tool. It is not possible to upvote several times in a row, but if you change your IP or clear the cookies, you could do that. You know that your average visitor wouldn’t have a hacker background, and you are not sure you would have visitors willing to vote in the first place. Does it make sense to invest in eliminating all the possibilities to misuse the system?
Always weigh the risks of users’ finding a workaround for your limitations and the effort required to eliminate the workarounds.
6. Don’t let frequent users shout louder
There are cases when the internal team has been using the product for some time for their needs. E.g., it’s a marketing task management system used by the CEO, management, in-house marketers, and also by external customers. The internal team already has a lot of data in their accounts, and they request robust search, performance optimization, filters, sorting, and easy switching between the projects. At the same time, the newly signed up customers struggle to set up a project because they can’t figure out how to do that. The internal team doesn’t see the problems of the new customers because they learned how to set up the project long ago. Being the users themselves, they believe they know what the rest of the customers want. And, as Casey Winters rightfully mentions, this stunts the product growth.
Show your internal team how the new customers struggle with onboarding, to make the problem visible.
7. Stop solving your problems
Often someone from the team personally doesn’t like something in the products they use regularly, and they try to fix this behavior in the product they are developing. They are the users, and they have a specific pain, and they project this perception on their end-customers too.
As an example, the team implements filters that do not reset after page reload. They hated that filtering was lost on a page reload in many apps they used, so they decided this was a pain point for their users too, and they “fixed” it. But the customers were used to refreshing the page to reset everything they did before. Make sure your team doesn’t miss the decision-making moment and outline and weigh the implementation options.
Another example, when the developers decide that the js bundle takes too long to load, up to a minute, so they optimize it. At the same time, that performance was fine for the customers, and there were no problems with it. Non-existing problem solved and many hours wasted. It’s recommended not to optimize performance unless there are real-life cases when current performance causes problems.
Or the team designs a new screen with a lot of data and only you report many elements as unreadable and not fitting — a screen resolution issue. If very few customers have the same screen resolution, you’ll just waste time on optimizing the UI to look good on your screen. Optimize for the screen resolution your visitors have and not for the one your PM/CEO/QA has.
8. Add defaults wherever possible
For us, it’s obvious that certain entities must be created first to proceed with action because we designed it this way. The customers just want the end result and usually don’t care much about the intermediate steps, especially if they don’t know them. Like when you save a contact to your phone, you select its type(mobile, home, work), or when you add an issue in a project management tool, you choose the status (new, in progress, done). You need to choose type or status to save a contact or create an issue. And although you can add custom types and statuses if you want, there are already some default ones in the system.
9. Do not group the inputs just to process them easier
Some interfaces are designed making it easier to process the entered data rather than to input it. Remember the last time you entered the same info twice on step 1 and step 3 or had to choose something from a list of ambiguous options? Customers don’t care if you have to store two same values in two different tables or if the API you are integrated with provides you overlapping time slots, neither should your UI.
10. Make your data trustworthy
Does your product offer recommendations, suggestions, or calculate sophisticated metrics, like the number of sales one will have next month or how many times they need to show ads on Facebook? You’ll repeatedly hear “How is this calculated?” from the customers. As the author of the software, you know the algorithms and trust them, but for the user, the numbers are pure magic, and they can abandon the product because they do not trust them. Many teams go into optimizing the algorithm accuracy or performance without solving the problem of the data not being trusted. Add explanations of how you calculate the figures, e.g., in the tooltip or add a link “How it works”.
This is logical!
When discussing designs and prototypes, almost every time there is someone who disagrees by commenting: “this is not logical,” followed by purely subjective opinion. If you ask them why they think so, there are no real arguments, but rather: “I’m used so”, “this is comfortable for me”, “these are best practices” (without specifying), and so on. Be careful with such feedback because at that moment, the speaker is not thinking about the customer; they think about themselves.
Rules of thumb
To avoid the decisions in favor of the decision-maker rather than the target audience, do the following:
- ask why they want this implementation until the real reason is clear;
- remind about the purpose of the feature, the primary use case;
- find and show customer feedback or session recording relevant to the problem you are solving;
- find and show relevant statistics, for example, the most popular screen resolution or Internet speed of your target audience;
- show the probability to meet a corner case, for example, how many people open the page or do the action in question;
- if working with outsourcing agencies, continually communicate them your goals, what problem you solve for the target audience and who is it;
- show your team examples of failed decisions to prevent them from making a mistake.