It is obvious that mobile app development does not have clear, established rules. The background for success in mobile app development has not yet been ascertained. From the past to the present, however, successful brands and products have adopted the ‘the user is always right’ approach, derived from the ‘the customer is always right’ motto. As a UX design expert, I can confidently say that UX research, a specific area of research within the scope of UX design, aligns quite well with this motto.

Many ventures start with a simple statement: “I have an idea!” This idea could be derived from another idea, could be an all-out new one, or it could even be a localized version of another idea from another region.

What makes the difference is testing said idea on the basis of user experience. The biggest advantage of testing is getting rid of the insensitivity we develop towards our idea simply because we fall in love with it as it first occurs to us and prevents us from seeing its potential flaws. While this may seem like an emotionally uncomfortable choice to make, it ultimately enables an objective evaluation of the product.

UX research could be summarized as:

• Mapping a target audience,
• Running benchmarks,
• Determining personas based on our projected target audience,
• Testing the idea by interviewing and surveying our personas,
• Running prototype tests with mock-ups, which are the first step of productization.

Running through these steps allows us to test and improve our idea or even develop a new one, without falling in love with it and thus, growing insensitive towards its flaws.

Benchmark

The most crucial phase before the “I have a great idea, let’s implement it!” stage is the benchmark process. By running benchmarks you can determine if your idea or a similar one has ever been used before. If indeed it has been done, you can analyze how it was implemented, what solutions were devised and what the new value propositions are.

A benchmark is not to be confused with competitor analysis, of course. For that, you could also turn to cross-benchmarking. For example, if you are developing a classifieds platform, you could run a benchmark off a non-competitor e-commerce platform, find and add new value propositions to improve your idea. Benchmarking is far from being a one-and-done process. As other products keep improving and advancing, running benchmarks regularly will keep your data sets up-to-date.

Creating Personas and Interviewing Users

Once you set your target audience, you can create personas within said audience. Your persona categories should be representative of the diversity and variety of qualifications within your target audience. You can now turn every issue you have with your product, anything you have failed to experience with your product and any information you were unable to reach into specific question sets. Then you can plan every interview to take between 15-20 minutes on average. The longer the interview, the more distracted your volunteering user will get, therefore there is an optimal amount of time to conduct these interviews for maximum efficiency. It can also be said that the most efficient version of these interviews is a reward (micro) to the participants. Although there are no set rules to determine the interview lengths, you can improvise based on the questions and course of the interview.

Wireframe and User Tests

You can now create your main wireframes with information gained from user interviews. Your design drafts, benchmarks you have run and the requirements for the project collectively form the basis of your wireframe designs. Wireframes, being as the basic architecture of your product, also serve the purview of the design. This purview may also later serve as a source in writing test scenarios, forming the front-end and back-end software architecture or analyzing the project.

The main purpose of wireframe designs may appear to be to guide UI designs. However, by completing the information architecture and advancing the usability levels, wireframe designs may also be used in supporting prototypes aimed at gathering data and reuniting with users.

Especially for products and/or services that are being built from the ground-up, such wireframe prototypes at this stage may enable the product to mature in alignment with the experiences of users. This may also enable you to undertake minor or even major revisions, even before spending too much effort on UI design or software development. For example, you have created the information architecture for the listing page in an e-commerce software. You have arranged the design to be transferred onto the UI design. You can now conduct user interviews through a single-page design even, and confirm users’ expectations you’re your product’s listing pages.

Detailed User Research Tests

Moving on to UI design, you are now creating designs for software development. You can create one-to-one models based on your product and create prototypes. You can conduct last minute user tests with those prototypes. You can test every scenario thoroughly using your prototypes to remove any remaining seed of doubt about your product. Your prototype tests can also be designed in various versions.

Examples for these versions are:

Design selection test: Design processes sometimes lead to indecision. Relative approaches aside, the best way to choose a design for your product is to consult your users. It may also be a viable option to ask your designers why exactly they came up with that specific design, which leads to a gathering of verbal data about every piece of design.

Partial service test: Some services related to your products can be tested separately through micro prototypes. These tests enable quick reactions from test users, leading to better-informed decisions about doubted aspects of the product.

End-to-end product test: These are comprehensive tests. Once the design process is complete, end-to-end prototypes are created to gather last minute feedback from users. At this stage some results from tests may surprise product creators. The main reason for this is the insensitivity developers inevitably develop towards their product, on which they spend a considerable amount of time. Sometimes end-to-end product tests make apparent some very obvious errors that had been there from the very beginning, causing developers to ask themselves how they have never noticed said errors.

There is a great platform for the tests I have mentioned above: https://usabilityhub.com/

Alternative platforms are:

https://www.optimalworkshop.com/

https://www.uxtweak.com/

On the platform, you can find a variety of tests and methods of gathering and analyzing user data. You can make the time to check it out :)

MVP and Expectations From MVP

The culture of ascertaining the purview of an MVP, moving forward with an MVP or even developing MVP-oriented products is a subject on its very own, deserving of a dedicated blog post. I would like to therefore briefly touch upon it to remain within the bounds of our subject, UX-centric development.

An MVP, or a Minimum Viable Product, is a version of your product implemented with the absolute minimum effort and function set, in order to gather feedback from your target audience and determine whether your audience really needs your product.

With kick-off talks, benchmarking, design and development and user tests, your product now has a basic structure. The last crucial step is to determine the extent of the MVP.

The most important aspect of determining this extent is, when we focus on the user experience, is to unite with users through our MVP and chart a course for the future of our product with our users. This enables us to entrust our product to its real owners.

Determining the extent of an MVP is a multi-disciplinary issue and cannot be stripped down simply to a design process, or even a development process. MVPs directly or indirectly determine the road the product management, marketing and corporate communication departments are meant to take.

Lastly, if your product is being launched through an MVP, you should truly be prepared for agile development. Because an MVP is both a way to confirm your idea and set the channels for its future development. With this first version that you release, you can gather user feedback, run A/B tests and create or revise the fundamental architecture of your product. Therefore if you are launching an MVP, you should not be expecting an influx of users, simply because you may get disappointed.

As a result, we can think of MVPs as the last step of UX-centric product development.