What Designers Need to Know About Server Side When Creating Mobile Apps
August 28, 2019
I have thousands of applications on my devices. I’m an active user of iPhone and Samsung at the same time. If smartphone addiction comes to your mind, you did not guess it right. I am a product owner. Every time I start working with a new market or on a new product, I install the applications of the key market players. This research helps me to understand what experience, functionality, and design are usual for the target audience. However, I face many issues while using the applications of market leaders. Sometimes I can’t even start using the app and pass the sign-up process. My experience and professional deformation come to the rescue. I have been worked in app development since 2016. I know how our applications work under the hood, what the processes are on the backend, and why we decide to develop an app that way. To overcome any issues with other applications, I assume how the application is supposed to work from the inside. Knowing the basics of software development helps me, for example, with the process of creation of authentication and authorization for an application. On the contrary, an ordinary client may simply close the application and uninstall it.
Why do such problems happen? After all, applications are developed for users. How does it turn out that the user can’t even pass the registration?
The tricky thing is that companies don’t even know about issues or do not pay attention to them. The usual workflow of design development is the same: wireframes => high fidelity design => prototype => approval => development. After passing this workflow, the product team knows how the application works so well that it seems to be obvious for everyone else. Such confidence may be overblown and become the root for a number of UX bugs. With further development, the number of issues multiplies by the technical implementation side. There are usually technical restrictions and requirements for the visual part of the application.
My goal for this article is to help designers improve their technical skills and explain why some technological nuances are important.
Why does the technical side matter in mobile development?
There are always many design constraints in the development process. Your brilliant design idea can be altered because of the technical imperfection of third-party services, API, and server side architecture. That is why, after the approval of the design, technical specialists should revise it. There are two levels of a check required — mobile developers and backend engineers. Let us deep into the development process a bit. Almost every mobile application is tightly connected to its server side.
Statuses in client<>server relationship of a mobile app
Single, in a relationship, married, divorced, or it is so-oo complicated… I’m kidding :) However, these statuses are not far from reality.
Usually, all the data is stored in the database. We need to have only one point of truth with consistent data. If your application needs to operate this information, it must use the Request-Response cycle. In other words, the mobile application ‘asks’ a server to GET, PUT, POST, or DELETE some data. When a mobile application sends a request, it is waiting for the response from the server side. This response contains a status code and the requested information. You may wonder why a designer should know about the cycle. As a designer, you need to create the UI for a user to understand what is going on under the hood of an application. Let us start with the status codes classification. All status codes are divided into five categories.
- Informational (starts from 1XX). Just a protocol level information. Such statuses are not essential for design in most cases. They do not influence the user experience, and there is no need to notify a user about them. This information is valuable for developers only.
- Successful (starts from 2XX). Usually, these statuses mean that some user actions have been successful (e.g., account have been created, phone number verified, money transferred).
- Redirection (starts from 3XX). This status means that the user request will be redirected. From the user side, this means to wait a bit longer for a response. In design, we need to show the user that the application is working. It may be a spinner or progress bar.
- Client error (starts from 4XX). This category of responses is really critical for the app design. The user has done something wrong. There may be various reasons. The user types incorrect information or tries to get unauthorized access for the forbidden part of the application. I’m pretty sure you know that for all web products you need to design page for the 404 error. That one with this type of a message — the page is not found. Dealing with the mobile design, you need to show the user that the performed action is invalid. The usual case is that for all 4XX statuses, a mobile device shows the standard error, like “Sorry, something went wrong.” The user doesn’t get why the request is invalid and continue trying to repeat the same action again and again. I had such an issue when I was registering in one digital bank. The app requested the photos of my docs. I received the error message “Sorry, something went wrong.” I was trying to upload the photos again and again. At the end of the day, I’ve discovered that the size of the photo is too big. There were no understandable requirements for photos in the app, which may help me as a user to upload the right-sized photo. And I spent half of the day playing with the photo upload — crazy digital banks.
- Server error (starts from 5XX). These are really bad statuses. They may mean that there are some issues with your server side. The backend may be down, or one of the services is currently unavailable. This may bring some panic to the user. So we need to tell the user that everything is OK and we are working on this issue. The user is expected to wait and retry again a bit later.
Basically, status codes are use cases or situations that might happen with a user.
You should also understand that there are synchronous and asynchronous requests. The synchronous requests should block the UI until getting the feedback from the server. For example, the login API. You need to receive the answer that the user with typed credentials exists and the user’s status is active from the server side. Alternatively, asynchronous requests can be sent one after another without finalizing the previous request.
One more thing you need to pay attention to is requests and responses. A server needs some time to process them. For some requests, you need to prevent the user from any actions until the app gets a response. For other requests, the user may continue working with the application.
From theory to the practice of mobile app development
The app collects data from the user (via input fields, user profile, and so on) and sends it in the form of a request to the server side. The data is processed there, and the mobile application receives the response — success or failure.
The simplified version may look like this:
The flow above is the easiest and most common one. One screen, one action, one response from the server side. As a designer, you need to visualize 3 cases: success, failure, and waiting for the response.
However, life is more complicated. Sometimes improvements of the UI (design) bring more problems to users. Here is a real-life case. We had a registration form that contains 12 input fields. It was looking overcomplicated on one screen. The client wanted to change the design without any change in the backend. Refer the result on the image below.
The data from all steps was collected on the mobile device and sent to the backend. In the response from the server side, we could receive that the user had failed at the second step. So the user had to redo actions for the second step. The change in the design would not be helpful for users. The new design had brought more frustration to them. The main users’ concern was “Why didn’t you tell me at once, at the step where I failed?”
That’s why after every change an app design goes through a technical review.
What does your app need to inform a user about?
The architecture and client-server relationships are totally your business. The user doesn’t give a duck about them. And the user is right.
Here is the list of things that are critical for the user to know:
- Requirements: First of all, as a user, I want to know the requirements for the information that the app demands from me. Otherwise, the user can get some 4XX errors without even understanding their reasons. Errors may repeat over and over again until the user gives up or manages just to guess the requirements.
- The application is working: When I am a user, I need to know that the app performs the way it should. If the UI is blocked, there is some activity under the hood. It is important for synchronous requests. If users don’t get the notification that the application is working, they may think that the application is stuck. They become nervous. They try to press all the buttons, reload the application, and do other crazy actions.
- Feedback: As a user, I need to know if my data is invalid and what must be changed. Otherwise, I need confirmation that everything is OK.
Examples of user hints when designing an application
If you read about requests, responses, and status codes for the first time, it can sound a little bit complicated for you. You may think that you are just a designer and this information is not important for you. But let me show you the cases where you can use it.
In one of my articles I wrote about the budgeting application, I would like to create. I’m still working on this idea. In this article, I would like to show you samples from my future application as examples.
Rule 1: Show the mobile app user where he was wrong
We can’t perform all data validation on the mobile device. In most cases, users’ data is checked and validated on the server side. A user should know the result, we need to show which information is exactly incorrect. Also, we need to provide the requirements for data. At this point, it is crucial to provide hints available for a user.
Rule 2: Do not allow app users to insert invalid data. Help a user to understand your app requirements
Why do we need to let a user make a mistake? Let me demonstrate this thought via an example with the birth date. Say, we have no special limits for the users’ age (unlike the limit of 18+ years for bank applications). But the date of birth must be earlier than today’s date. One more example is with the delivery date. It can not be in the past. So a developer may configure the picker which allows a user to choose the date from today and all future dates.
If we let a user insert incorrect data, his request will be blocked by the server side, and a user will need to repeat his actions for achieving the expected result.
Here is another example of this rule. For some applications, it is crucial to comply with a high level of security. They have special requirements for passwords. The user must enter the password with the different register, special characters, and numbers. If the user inputs an invalid password, he will get the error from the backend. Preventing this situation, you may show the hints with requirements on the UI.
Rule 3: Show that an application is working
Do you remember synchronous requests to the backend? Thus, when a user presses the button, the application sends a request to the server side. The process of sending and receiving the response can take some time. You need to show it to the user. Especially with synchronous requests, when you block the UI until an app gets the answer from the backend. Is this sequence clear for a user? No. We need to show a user that his/her request is in progress. You need to show the progress with a spinner (or a hud). It can occupy the entire screen or be located inside the button. It is up to you, what option to choose.
Rule 4: Show the success of users’ actions in the app
A user has done some actions in your application. For example, a user adds new expenses to a budgeting app. A user needs confirmation that this action was accomplished successfully. If a user is doing some decision-making actions (e.g., the creation of an account, adding a credit card to the application), you can add modal screens that are blocking the whole screen. But if it is just a change of the settings or adding another expense, the small notifying success message is enough.
Rule 5: Your app backend may be out of reach
Everybody tries to avoid this situation. The unavailability of the server side can be caused by bugs from the developers’ side. Another reason is an issue with your hosting provider. I’ve experienced a few times when Amazon Web Service (AWS) or Microsoft Azure laid down because of some issues. It caused issues with my application too. Backend issues may cause partial or full unavailability of your services.
Significance of tech skills for an app designer
As a conclusion, I want to emphasize the importance of technical knowledge for designers. Having such knowledge decreases the communication gap between designers and developers. One more advantage is that designers will understand all cases they need to cover from the start of the application design development. It helps to reduce the time for creating an application. We can really experience its outcome on our projects. Dashdevs, a software development company, is working hard to make better Hi-tech products. We are improving our processes and approaches continuously. We organize the tech talks and skill upgrading events for our team. Technical education for designers and client engagers brings us the best results at the moment.
P.S. Let me know if such topics for articles are useful for designers and I’ll write more.
Digital Product Manager at Dozens
Head of Client Engagement Department at Dashdevs LLС