Before starting a new project, we make sure that a mobile app is the correct strategy: is it the most suitable support? What should it offer? How does it compare to other channels?
Take an example: a client manages several gyms. To promote them, there already are a website that shows the rates, venues and schedules, the gym equipment and collective classes information.
The gym manager would like to offer an additional service to members: a personalized sport training program.
In the design phase, keep in mind we are producing a product for a specific user – the gym members in this example – and we should not force our designer choices on them. We should rather listen to the end-clients and adapt our mobile app so that it perfectly meets their needs; otherwise the app will simply not be used.
To know his or her user, one must rely on one of the three following methods:
- Get a field expert’s vision = the client; in this case, the gym manager
- Observe users in their natural environment; go to one of the gyms and take note of gym members’ habits and behaviors
- Interview users; exchange with the members in a dialogue / question form to collect their opinions and expectations
By gathering this information, we can list needs to satisfy, identify the value proposition and define one or more issues that the mobile app should respond to.
Here is an example of an issue:
“ How can we help gym members to reach their objectives? (Muscle gain, weight loss, etc.)
There are multiple possible answers to this question, which should be sorted and prioritized according to feasibility (is this functionality technically easy to implement? Do we have the resources?) and desirability (is this functionality really necessary in the mobile app? How does it help the user? What if it does not exist?).
After this step, we are able to sort each feature in specific categories. Thus main sections of our app emerge. For instance, the feature « check weekly exercises » could belong to a section called « my program » .
This step is followed by the functional specifications, that we will detail it in the upcoming article 2 of our investigation story: « Article 2: Specify » (link to the article).
At this -early- stage, clients are often eager to see how their mobile app will look like and try to rush the process. However, while being an understandable behavior, there are still a few steps to take before drawing the screens. We now write the main user journeys to visualize the different steps the users go through to reach his or her objectives. To do so, we complete this sentence « I am _ _ _ and I wish _ _ _« .
Here is an example of a user’s objective:
“ I am a gym member and I would like to create a personal training program.
Let’s see an illustration of a user journey fulfilling the objective:
The arborescence completes user journeys and structures the main sections of mobile app; it’s a sort of navigation flowchart illustrates the links between the different sections.
And then it’s time to work on interfaces. We start drawing on paper the « quick and dirty » wireframes to quickly validate the navigation choices and check we have not forgotten anything. It is fast and easy to prototype on mobile. Apps like Pop or Marvel allow to mock screens from hand-drawings to smartphones by uploading pictures, determine clickable areas, and link them with the various screens of destination. We can browse our app without writing a line of code!
It is now time to give life to all those screens by opening a design software (Sketch or Figma). It is key to respect the client’s visual identity, while using numerous native components served by iOS (Apple’s platform) or Android (Google’s platform).
We can now head to the gym to perform some user-tests. We iterate by taking into account users’ feedback to offer them a suitable product that perfectly meets their needs.
Some restrictions and unique opportunities
Designing a mobile app requires to face particular restrictions which can be turned into opportunities. The screen is small but easy to carry. The connectivity is of variable reliability, but is available almost everywhere. And there is so much to say about multitouch interactions… In mobile design, conditions of use are crucial: little to no network, mobility, lying on a sofa, with company, alone, when we have time, when we only have a minute … To forget them means ignoring users’ constraints and may lead to an unusable product.
Therefore, it is important to know the extensive possibilities offered by smartphones, starting with a quantity of sensors to use without moderation: for instance the accelerometer, gyrometer and magnetometer provide jogging data. The flash and the camera can also be turned in a heart rate monitor! One can also connect the application to many external sensors (smartwatch, Bluetooth-specific sensors). Let’s not forget the camera, a classic of course, but not to be undermined as it allows to visualize in augmented reality accurate postures to adopt on a gym training equipment.
Designing for mobile also means following guidelines (GUI) – some best practices – offered by the different operating systems. For an iOS application for example, our designers and developers use UIKit components, a framework that defines common interface elements. This framework allows applications to be homogeneous even though they are developed by different teams and adaptable to each device (on an iPhone 5S, as well as on an iPhone X). Thankfully, it also offers a high level of customization (colors, typography, iconography, visual identity of the customer …)! Otherwise all mobile apps would look like system applications such as phone settings.
In short, deviating from guidelines is to deviate from what users are used to, their reflexes and habits. One must find the right balance between a known environment, simple to apprehend, and some sort of originality.
Navigation and animations
Furthermore, a mobile screen is very small compared to a computer.
For instance, who has never cursed a mobile app because it was unreadable when sprinting to catch a bus? The big difference between web and mobile also lies in navigation and animations. One could rightly say that the web has changed and is no longer like that. But if the web looks more and more like mobile apps, it is also because it is increasingly accessed via mobile devices which successful mechanisms have been proven. An an example, one can notice that a mobile app elements come from the right, respecting the reading direction, while also coming and leaving by the bottom of the screen. So are popups. All of this means something. This visual navigation guides the user in letting him or her know that he or she is moving forward in a process, or that the mobile app requires a few minutes for information filling before processing to another step.
On mobile, such mechanisms must be used -without abuse- since they give clear indications without overloading the interface. There isn’t so much available space, so it should be only used for relevant information. It also increases readability for what’s important.
There are multiple tools to help design a mobile app accessible to all. For instance on iOS, the UIKit framework offers solutions for users who have a visual-deficiency, a hearing loss or other issues. Some of those solutions are text enlarging (with the Dynamic Font), a readable audio-description of the screen elements or user-actions (with VoiceOver)…
Accessibility does not only concern deficiencies, but forces us to design interfaces which are easy to use and read. To help us, for instance while working on mock-up design, tools like those proposed by WebAIM allow us to test color contrast.
One must develop such reflexes, since afterwards a mobile app can easily be designed to be accessible and used by all.
If the topic interest you, you can (re)read iOS applications accessibility.
Choosing the technology
Should one go for native, hybrid or web? To this unavoidable question, one claiming to hold the ultimate answer lies. One must always go back to his or her objectives and users.
Web is accessible both on desktop and mobile, however it is hard to optimize it for mobiles. Native is more reactive than hybrid but requires two dedicated developments. Native also simplifies the usage of OS components but needs app downloading. Therefore, the following questions should be asked: must the service be punctually accessible or at all times? On which frequency? What are the reactivity constraints, off-line behavior, captors usage? What are the target platforms? Are the users on mobile, desktop or both? Are their behavior similar on both channels?
For a video-streaming mobile app which can be used without service, native wins. For a showcase app, hybrid will assure you a unique development. Everything is based on your needs!
Do you an have an app project?
Let’s discuss it!
Are you interested by this story? Subscribe to our newsletter to receive weekly articles.Subscribe to our newsletter