How much does your partner know about ux?

If you want to make sure that your partner is the right one, you must ask yourself some key questions to discover if they know the importance of UX

When we see an Apple product we know without a doubt that there is a user experience (UX) work behind it. We know this because they are thought and designed to simplify their use and to accustom the common user to their daily use.
Let's imagine for a moment that Apple launched a new version of the iPhone with several buttons on the sides, complicated to use and with strange nomenclatures. That would undoubtedly lead to a huge cost of user learning and therefore a bad user experience. This happened several years ago when the Microsoft Office package modified its top menu for an iconographic one, forcing millions of people to get used to a new one. But that was precisely his intention, to modify the user experience.
There is no doubt that the importance of UX can make your product a success or a complete failure.

Some questions

Sometimes it is believed that attention should only be paid to the user experience when we talk about a superior product, when we think of Microsoft, Google, or Apple. And the truth is that yes and no.
All our ideas, all our products must bear in mind the user experience. And ultimately, we must treat it as if we were one of these commercial giants.
The truth is not interested in the type of product, the platform, or the language behind it, if there are users, then we must study and design the UX of our product.
And for this, it is essential that our partner, who develops this product, is the right one to do it. Because it is not enough simply that you know how to develop and do not have bugs, but that the product you develop is optimal for your users, and not for others. You must be able to develop something attractive, intuitive and useful.
So before choosing a partner, ask them the following questions to be sure.

Agile methodology

In the beginning, several decades ago, software development had a cascading methodology that consisted of different stages that occurred one after the other and assumed that each one was ending to start the next. In this way, for a user to be able to see a product and give feedback, it had to be in production first, but first, it had to be tested (the entire product), before developed, and even before each requirement was analyzed until it was fully specified. detail each point that the product would carry.
This implies that in order to have the feedback of a user and to be able to adjust the product to the real needs and comforts of the user, the user had to wait for the entire process of developing a product. Of course, this could take a whole year of work, for which a result would be obtained that may not serve the end-user, or in the best of cases it would be completely uncomfortable to assimilate.

Although today development continues to have these stages, the operation is quite different.
The agile mindset is based precisely on change, on meeting real needs and in constant movement, and not on anchoring in the original document that an analyst wrote.
For this, each stage of small steps is carried out, always evaluating that you are going on the right track. It is validated with the client that the requirements are really what they asked for, that exactly that is being implemented, even though we are just two steps away from the start. And we always try to validate with the end-user, taking measurements and understanding the use they give to the products we develop.
This causes that in the same year, where before a single version was released that was probably not useful, now dozens of versions are released where each one adds a new seasoning to the product, and where previous components are adjusted to make sure we obtain the best impact on our users.

So the question to ask yourself at this point is: is your software partner agile?

Testing

In a classic way, testing is commonly thought of as the stage where coding errors (bugs) are detected. But the truth is that this stage must carry out a more exhaustive search process, not just for bugs.
Of course it is necessary to test the functionalities from a technical point of view, make sure that everything works as specified and that no errors occur.
But the usability of the product must also be tested. You must ensure that it is simple to use, that users want to use the product. Let's think that when testing, a button can fail in two different ways. On the one hand the classic, when the button does not do what was specified, when it does not fulfill what our client wanted it to do. And on the other hand, it can fail because it doesn't do what the end user thinks it is going to do.
If our application says "share" and does not give the typical sharing options, then it is useless to do what was specified, because it will not comply with our user. And that ends up causing bad user experiences that can make our product fail.
That is why we insist on finding out what processes your partner has to test the usability of your product and how important they think these tests are. And of course there must be usability metrics that use tools to collect information about the places that users visit within our product, where they pass, how far they arrive and where they stagnate, etc.

Test their products

Exactly what we say. Don't be left alone with your partner's response. When looking at their portfolio review each application developed and ask yourself how intuitive it is. Become a user of these applications and examine them carefully.
Of course you must also inquire why certain design decisions were made and not others. And understand how much participation your partner had in the UX of these applications.
Ultimately, make sure they have enough real experience in the UX of the products they developed