This article from day 17 of Merpay Tech Openness Month 2023 is brought to you by @kris from the Merpay iOS team.

The Power of UX in iOS App Development

An app’s user experience, or UX for short, simply refers to the experience a user has while interacting with an app. This is usually handled by an experienced designer or design team, but is tightly coupled with development and should also be considered by iOS developers as they work on an app.

When you download an iOS app for the first time you may be excited to try it out and to learn about all the useful features it has to offer. You might be looking for all the ways the app stands out and is different from others, or how it can solve a problem better than the competition. Maybe you really like the unique design of the app or simply just because of how smoothly it performs. There may be major differences between the new app you just downloaded and others you have used in the past, but for some reason you already know how to use it. You know that if you see a back button you can swipe back to navigate to a previous screen, or that you can delete an item in a list by swiping it from the right. You know how to perform these actions because they are all common features found in iOS apps, and you have come to rely on them in every app you download. In fact, we tend to rely on these features so much that when we attempt to do something and the result is not as we expected, it can often feel very unsettling and break our concentration from the app and its content. This is obviously not what we want to happen to our users, and that is why design standards exist: to help make the experience as positive and natural as possible.

Apple’s UX Guidelines

Reference：https://developer.apple.com/design/human-interface-guidelines/designing-for-ios

There is a general consensus that Apple has high standards and strict rules for app developers wanting to release an app in the App Store. This not only has to do with privacy, security, and safety standards, but with app design and user experience as well. Apple frequently releases documentation and videos related to managing your app’s user experience to make things more consistent and familiar between all apps, and maintains extensive Human Interface Guidelines for the entire Apple ecosystem. One video in particular about navigation design, titled “Explore navigation design for iOS”, is the inspiration for some changes we made recently to the Mercari iOS app.

In the video, which is helpful for both new and experienced developers alike, some very important app navigation best practices are discussed. Navigation in an app can have one of the biggest impacts on a user’s experience, being nearly unnoticed when things behave as expected but a big problem when they don’t. It’s best to consider how a certain flow in the app will effect a user, both positively or negatively, when designing navigation between screens.

For example, in the video it states that changing tabs in a tab bar can become a source of confusion when the user loses track of where they are in an app after performing some action. Let’s say the user is on the app’s home screen and taps a button to view a list of notifications. It could be considered bad UX to take the user to a settings tab first, for instance, instead of displaying the notifications directly from where they are. This concept is especially true when the change of tabs breaks an established flow within the app, such as a purchase flow, since it could lead to the loss of sales and an overall negative experience for the user.

Another important topic covered in the video is about when to display content in a modal style, meaning the new screen is pushed in from the bottom of the current screen and displayed on top. The alternative on iOS is normally to simply push a new screen into the navigation stack, displaying the familiar back button and allowing the user to swipe back to the previous screen. When content is displayed modally, it can reduce distractions and let the user focus on the task at hand and to let them know that it is a separate flow from where they just were. Apple recommends this method to be used when the task is self-contained, can be started and finished from within the modally presented screen, and doesn’t rely on other parts of the app to finish. This kind of task is usually optional with a close button at the top, and lets the user know that they should finish, or dismiss, the presented flow in order to continue using the app.

Real-World Implementation in the Mercari App

At Mercari we are constantly looking for ways to improve our app and service for our users, and this is especially true for Merpay as a financial services provider. A bad experience in any app can lead to frustration and discontent, but when money is involved it becomes even more crucial to provide the highest level of quality possible to secure the trust and loyalty of users.

Our credit card, known as Mercard, is a modern credit card which is fully integrated into our iOS app. Users can apply for, activate, and check the spending of their card all from within the app. In the checkout screen when a user is purchasing an item we had an option to apply for the Mercard. Upon applying, the user was taken to the Merpay payment tab where they were presented with the application screen. This change of tabs was implemented in this way on purpose since the application flow was originally developed to only be pushed from the navigation stack located at the Merpay payment tab, and all QA testing was done under that assumption as well. At the original time of development, there were no plans to display the screen from other locations in the app directly. Since it was not verified that the flow would work properly when displayed from multiple locations, and since it would be hard to verify that pushing to various navigation stacks throughout the app wouldn’t present any additional issues, the presentation was locked to the payment tab. This caused problems for our users, taking them away from their transaction and forcing them to move to a new location in the app was not ideal. Once they finished their Mercard application they were no longer on the checkout screen and needed to find their way back on their own.

Around the same time there was a renewed interest within the Merpay iOS team to analyze various flows throughout the app to try to improve the UX and to make them more flexible in terms of where they could be presented from. I saw this situation as an opportunity to do two things at once: to change the Mercard application flow into a more flexible, self-contained task that can be safely presented from anywhere in the app, and to improve the checkout experience by keeping the users in the checkout flow rather than moving them to the Merpay payment tab. Thus, the refactor of the Mercard application flow was born!

In order to improve the flow we focused on a few key points:

• Remove any points of friction for the user
• Refrain from forcing the user to change tabs and keep them in the same place they started
• Remove distractions by covering the current screen contents
• Make it obvious that the application process is an optional, self-contained task

Before (Push)	After (Modal)

The change itself went surprisingly well with few issues as we modified the navigation style to be modal. You might imagine that any screens that are reused from other parts of the app and are pushed to the flow could experience problems with a modified navigation style, but we were pleasantly surprised to see that most screens had no issue with the changes and we could proceed rather quickly with minimal adjustments.

Of course, there are risks in iOS when presenting a screen modally, such as when attempting to present from an already presenting view controller. Additionally, presenting a screen modally means that you do not have information about the location of the app where the screen will be presented from, which you would have when presenting from a predefined location each time. The changes were thoroughly tested by our QA team, and after some time the flow was approved and ready for use in the app.

It’s also important to note that not every flow in an app should be presented in a modal style, and that careful consideration should be made when deciding which style to use. By following Apple’s guidance, we were able to decide on changing the application flow to modal style, and continue to look for other flows in the app to refactor in the future as well.

Conclusion

No matter your role, whether you’re a developer, project manager, or designer, it is important to always consider the user’s experience when interacting with your app and how to ensure it remains positive and keeps bringing them back for more. Apple provides great resources for apps of any size to help improve their UX, and in turn it helps to keep iOS apps feeling consistent and easy to use. Refactoring the Mercard application flow increased the checkout completion rate by a statistically significant amount, and helped keep user satisfaction high by changing the app to fit their expectations and reduce friction. We will continue to search for quality of life improvements such as this in order to deliver the best possible experience to everyone using Mercari on iOS.

Tomorrow’s article will be by @champon. Please check it out!