Being pragmatic

User experience design sounds like a simple process. Ideas such as understanding a problem before trying to solve it may not sound very radical. However, the number of badly designed products we encounter every day shows that this process is not always well applied in practice.

There are many challenges when following the design process in the real world. You may be tempted to consider these to be political issues caused by someone else or the result of a general lack of design culture in society. However, that perspective is not going to help in practice. Applying a proper design process in a team requires the efforts of the team to understand the benefits. You are in charge of helping them to change their mindset for the process to work in practice.

Design is not about making things look nice

Design is a process of finding solutions, and it starts before the problem is clearly defined and understood. However, many people identify design only with the aesthetic aspect of an object. They expect designers to come at the end of the process to make an existing product look good with few cosmetic adjustments. Although aesthetics definitely contribute to the user experience, that is just one component, and it won't help to fix the big usability issues in your product if those already exist.

You need to make sure that you are involved in a project from the very beginning. Emphasize in your team the need to understand the problem well before jumping into a solution in cases where they are already considering a predefined path of action. If you arrived late in the process, it is still useful to present alternative solutions. This will illustrate how design can be more valuable at the beginning of the process the next time.

Users are not able to tell you what they need

As Henry Ford put it, "If I had asked people what they wanted, they would have said faster horses."

He was referring to the latent need for better transportation and the way people communicate those needs based on the solutions they already know, as opposed to potential solutions that do not exist yet, such as a car.

People are not good at describing their needs or predicting their future behavior. That does not mean you should be arrogant and ignore what people tell you. This means that you get feedback from them based on observing actual use, and make an effort to understand which are the underlying issues behind a user suggestion.

You (or your team) are not your users

People in your team, including yourself, may project their own needs or personal preferences onto the products. These opinions may not help solve the real needs of your users, and often lead to fruitless discussions among people with different preferences.

In these situations, it is important to change the perspective of the conversation--instead of discussing about what people in the team like, focus the conversation on what will work for your users. This encourages people to connect their feedback to the product goals and provide more context.

A complaint such as I don't like this drop-down menu is not very helpful. Framing it as I don't think this drop-down works since users are provided with too many options when making a quick decision brings more context and it is presented as an hypothesis that can be checked--you can ask for a situation in which such a problematic case would manifest, and recreate this when testing. This perspective change helps to focus on the user goals, and turns feedback into opportunities for learning more about your users. Making sure that the team regularly views real users using your products and prototypes will help with this shift of perspective.

User experience is not a list of features

Products are often described as a list of their features. However, that does not reflect the aggregated experience users have when using all those features combined in a product.

A great feature may be worthless if users cannot find it or they get confused when trying to use such a feature. Thinking only about adding more and more features often leads to ignoring how easy or hard is for users to use them.

Similarly, teams may be willing to cut corners of a product for an initial version or a Minimum Viable Product (MVP). A complete product with a small scope is preferred to an incomplete product with a wider scope. A small focused product is more useful than a bigger half-baked solution. Addressing many different needs poorly is not going to generate a very positive user experience. At the end of the day, a bike is much more useful than half a car.

Your goal is not to make your client or boss happy

As a designer, your goal is to find the best possible solution to a user problem. You are giving voice to the users of the product, who otherwise would have little room at the table.

While having a positive working relationship with clients and teammates is good, it is your responsibility to flag anything that negatively affects the users even if that leads to some serious conversations. Some of the user needs may conflict with the needs or interests of your organization. While it is part of your work to consider the different constraints such as production costs when solving a problem, you also need to make the organization understand that going against the user interests won't be good for the organization in the long run.

For example, an airline website that hides the option to opt-out from travel insurance to trick users into getting it will get some monetary benefit in the short term, but it will negatively affect the trust the users have with the brand in the long run. Tricks that make products hard to use on purpose are known as dark patterns, and you should never use them.