Developing An Android App With a UI-First Approach

Real-Life Experience

This article will be of interest to most developers who create UI in their applications. Here you'll find some approaches for creating UI with UI First in mind, and which can be applied to any platform in general.

A year and a half ago we finished the development of an MVP Android application. Our team managed to stay within the estimates and the scope drawn up at the start of the project. During the development, the number of UI bugs was insignificant and the review of our application by the design team was highly positive.

Based on the results of the work done, here are some things that allowed us to achieve a high quality of the final product.

How to Develop an Android App With UI First Approach

At the beginning of the development, we decided to use the UI First approach. The main idea of this approach is that when you start working on a new feature, you first create a UI for it, test the implementation on the test data, collect feedback from the team, designers, and, ideally, the customer, and only after this you get down to the implementation of the business logic for this feature.

This approach allows achieving the following results:

1. To detect various states of our screen, which are sometimes left out in the UI/UX development. This way, fewer bugs related to invalid states or unprocessed cases in UI go to test engineers, because the developer is able to detect them at the stages of implementation and dev testing.
   
2. To provide designers with a capability to assess their design on a real device, so they can understand how it looks and ‘feels’ and make some changes if needed. We all know that static mockups are one thing, while real design on a device gives a completely different feeling. This way, the feedback from your design team is not put off to the late stages of the project. This helps to receive and apply the designers’ feedback in small increments. These small chunks are easier to review for designers, while developers spend less time fixing comments after the review.
   
3. One of the most important things is that this approach allows the customer to assess the UI of a new functionality before any considerable amount of time is spent on it. Any changes at this stage will be a lot less costly than when the business logic and the tests for this screen are finished. If the customer decides to change the UI significantly, all the business logic also needs to be modified, which requires a lot of effort and time. To implement this approach effectively, we have created a Storybook for our application.

Storybook For Our Mobile App

To look through various states of the UI without rebuilding the project, we were in need of an appropriate tool.

This is where the Storybook came in handy. The Storybook is a list of all screens (modal windows, standalone views, if necessary).

A sample view of the Storybook in our application

After selecting one element, we can select the state of this screen that we are interested in and then see the screen itself in the state selected earlier.

Selecting a state for the Onboarding screen

The Onboarding screen with test data

This approach enables us to see various states of each screen without restarting the application. It also allows us to implement features faster, as opening a certain screen requires us to put the application into a certain state. This might be rather time-consuming as you need to do it after each change and build of the project.

Therefore, with the help of the Storybook, any screen can be reached in two clicks, without performing any other related actions.

The idea of creating a Storybook is not new. An example of its implementation for web development can be found at this link. We adapted it for mobile technologies to ensure the viability of this solution and to understand what advantage it can give us. 

The selected development method requires certain approaches to the architecture. We used Data-Driven UI, which enables giving real or test data to the screen. At the same time, our UI is absolutely unaware of which data it is showing. This approach ensures the correspondence of the design that we create within the Storybook with test data and design with real data.

Architecture Of The App

The aim of this article was to describe the overall approaches, without touching the specifics of the Android frameworks that we used.  

Here is a link to a GitHub project that is essentially a replica of all frameworks and approaches used in our real project. There you can also find detailed architecture documentation. The provided example project includes only one screen showing a list of all repositories of GitHub API.

Also published at https://sigma.software/about/media/benefits-using-ui-first-real-life-experience