5 reasons why you should think of UX while developing your product

João Monteiro
Published in
4 min readSep 12, 2018

--

The user experience (UX) of a product is how that product interacts with its users and how they respond to it. No matter how perfect or ingenious your solution is, if people cannot understand how it works or think it’s too cumbersome to use, they may not even bother with it.

Even so, many developers only start thinking about their product’s UX after everything else is done, and often after it’s released to the public; it’s an afterthought that has the lowest possible priority. Here are 5 reasons why I believe that’s the wrong mindset to have.

1) First impressions matter

“A delayed game is eventually good, but a rushed game is forever bad.” — Shigeru Miyamoto

If the product you release has absolutely horrendous UX, no matter how you improve it afterwards, you’ll already have scared away potential customers that won’t return to check it at a later date. Miyamoto’s quote, which judging by the undeniable quality of his games is something he truly lives by, sums it up beautifully. Applying it to UX, this means that doing all the tests and improvements pre-release is the only way to go if you want to cause a good first impression and build the very best product you possibly can. The customers’ opinion of your product will be high from the get-go, and your company’s prestige will increase for having released a polished product.

2) UX is part of a whole

When you think about your product’s UX, you’re not just deciding where a button should go and other “trivial” things. You’re also thinking about how the product is structured, how each interaction leads to the next, and what the users will want to do at each phase of their experience. This means that developing a good UX may require restructuring the entire solution and moving features around to make them work better together.

If the discussion of a product’s UX can lead to such drastic changes, it should be done as early as possible while prototyping, in order to facilitate further iterations before each feature is completed. UX cannot be done in a vacuum. If you decide to do all of those major changes after you have a finished product, the costs of doing so will be immensely higher than if you had just planned them correctly in the first place. And that may have permanent consequences for the product: if the developers didn’t originally pay attention to the UX, and now it’s too expensive to significantly improve it, then they will keep providing a subpar UX.

3) Habits are difficult to break

“Workflow”, by xkcd

People are used to doing things in a certain way. If you change the old way of doing something, users will be thrown off by it. Their muscle memory will betray them, their workflow may break, and they will have to learn and adapt to the new way of doing whatever it is you changed.

So even good changes can have negative consequences for some users. Minimising those changes, and making sure that the experience is as good as possible from the moment a product is released, is paramount to limiting user dissatisfaction and avoiding user exodus.

4) Haters gonna hate

It’s absolutely certain that some people will hate any changes to the product, regardless of their merits or if the changes affect them specifically. You could be transforming the ugliest pebble into a shining diamond; some users will still find it insulting and outrageous that you dared to change anything at all. And this vocal minority will make sure that you know that.

So again, it’s important to try and minimise the changes that we do to already established products. Change is inevitable if the product has a somewhat long lifespan (social media redesigns come to mind), but that doesn’t mean we shouldn’t try to change as few elements as possible. Hence, it’s better to start off with a stellar UX instead of having to later on doing changes that were completely avoidable and may end up alienating part of your user base.

5) UX doesn’t need to be grandiose and expensive

UX is a somewhat vast discipline. You could spend months analysing every single aspect of a product with varied test groups in order to be extremely certain that you’re taking the absolute best decisions. But realistically, most small projects don’t need a whole lot of UX analysis. If your small start-up is building a weather app, there’s probably not much going on that there hasn’t been previously done by other apps. Now, I’m not saying that other apps do everything right and we should repeat their mistakes, I’m just saying that there are some areas in which using the established standards is perfectly fine (and, for familiarity purposes, it may even be recommended to do so).

You don’t need to reinvent the wheel in every single project. Innovating and doing user tests to confirm hypotheses can be awesome, but may not be necessary if the project is familiar enough. So committing to developing a good UX doesn’t have to mean spending a lot of time or money; it may just mean having someone pay attention to what they’re doing and question some preconceptions that the product may have fallen in. That’s all it takes to guarantee a good user experience.

--

--