Some time ago I opened a similar question (I don’t think it’s a duplicate, but let the community judge): When and why to create a mobile app?
In the scope of my question, I was interested in understanding the motivation to create a mobile application. In your case, I will consider that this motivation is already well defined.
From the point of view of the experience of mobile application users, the question that seems fundamental to me is the size of the device. Mobility requires the device to be small and light enough, but its small dimensions make it difficult to "translate" applications as we are hearing. Any text presented needs to be shorter in order to have a larger font and thus be readable while it fits on the screen. Hence the use of icons like stock representations is even more interesting. When images are not good enough alternatives, the text needs to be presented gradually and user-controlled (easy paging or scrolling of the screen).
Interaction is also hampered by reduced size. Touch screens are naturally intuitive, but in prolonged interactions a finger on the screen simply obstructs the source of information (this is exactly the case for games, for example, that draw a joystick on the screen to be controlled by the thumb). So alternatives like using voice command or sensors like the accelerometer can be interesting. Also, as with the entire screen (in fact, the entire device) is touch sensitive, it is important to differentiate in its application the visual elements (from the GUI) that are in fact related to actions of those who are not. Buttons that "don’t have button face" are a problem in any application, but in a desktop environment they can be inferred as buttons by the position they are in (center, always below, etc.) and mainly by the relationship they have with other elements. On mobile devices this relationship is more difficult to notice, because buttons can have dimensions very close to other visual elements. So, in order for the user to understand how to interact with the application and not be frustrated in using it, it is important to differentiate well what is "touchable" from what is not, and to maintain a standard on all screens.
Another important feature for mobile interaction is access to data. There is not always an Internet connection available, and this interruption tends to be more common than in non-mobile environments (in tunnels, within shopping malls, etc.). It’s terrible for the experience that a user doesn’t have access to information when he needs it most. Consider an app for acquiring movie tickets that lets you view the ticket on your phone. The user will certainly try to use the app when entering the cinema. A miscommunication at this point can cause the film’s initial moments to be lost, making it impossible for the user to enter the theater. Instead of having the application connect and search for information at the requested time, it might be interesting to use services like push so that the server would automatically send the data to the device as soon as possible after the purchase. The device would then store the data offline, to ensure the experience. Note how this problem does not have a direct relationship with a graphic interface (GUI) problem, but rather with the higher-level interaction between application and user and the resulting user experience ("impression").
Additionally, keying applications on mobile devices is not as simple as in desktop applications. Essentially because the information that there are other running applications (which on your Windows or Ubuntu are tabs at the top or buttons at the bottom) take up space. Mobile operating systems usually hide this information, which is unclear to most users without the proper training in the form of use. Thus, it is even more important to allow the user to give up long operations (see my answer in this another question here from the site), and/or may continue to do so at another time.
Certainly there are other heuristics that can be listed, in the sense of being "best known practices". All are quite debatable and dependent on the domain of the application, even the ones I put above (which are the main ones, in my view, according to my experience as a designer and also as a user).
Something that is certainly a more general consensus is that whatever your product, you should build prototypes and evaluate the experience with interacting with participants representative of your users, in addition to constantly collecting feedback from users after the application is in production.
I could answer something half-hearted, but I don’t think anyone here could answer better than Luiz Vieira.
– Maniero
Then it would be a @Luiz Vieira reply, it’s not even @bigown?!
– Duds
The question is good, but I don’t know how easy it is to answer without "raining in the wet". Itself description of the tag ux already has enough details about the definition. About the use, well, the questions that already exist under this tag also help.
– Luiz Vieira
Duds, take a look at this content I’ve indicated. If you have any more specific questions, you can edit this question (or create a new one). How about that? (and, thanks for the Summoning, @mustache :))
– Luiz Vieira
OK @Luizvieira, I’m reading the content you went through. It can be yes, I’ll rephrase my question.
– Duds
Okay, for now I’m going to vote to close (just because it’s redundant with the tag definition). I think you know that doesn’t mean anything terrible (even closed, if changed is easy to vote to reopen). []s P.S.: A suggested edit is to focus on the issue of ux para mobile.
– Luiz Vieira
I am voting to close this question as out of scope because the content of a possible answer has a lot of intersection with the definition of the ux tag.
– Luiz Vieira
I just edited the question @Luizvieira.
– Duds
Okay, I withdrew the vote (and I’ll try to answer). :)
– Luiz Vieira
Thank you @Luizvieira :)
– Duds