Mobile app branding optimization

I want to share my experience in optimizing the branding of mobile applications. Branding refers to the creation of a copy (“clone”) of the main application with a modified design and content. The main application that we will brand is a recommendation service for finding and buying movie tickets.

The need for branding arose due to the new business model of the Customer, the essence of which is that the cinema network receives its own mobile application for free, and the Customer receives an additional ticket sales channel. Accordingly, the development task was to minimize the cost of developing branded versions.

Introductory


The main application is a native (not based on html), consisting of ~ 20 screens, on two platforms: iOS, Android. A branded application is made for cinema networks already existing in the main application, essentially “filtering” the main application to the size of a particular cinema network.
The branded version should differ from the main application as follows:
  • Have a corporate identity cinema
  • Satisfy one of the 3 possible types:
    - for one cinema
    - for a network of the same name cinemas
    - for a network of cinemas with different corporate identities
  • Maintain custom functionality.


Branding Cost Optimization


The first version of iOS for a single movie theater cost us quite a lot - the actual labor costs were 15 days. The solution to the task of reducing the development time of the next branded version was branding technology , that is, optimization of the main processes of creating the application - from the incoming request to the publication of the application.

We tried to optimize everything :
  1. Design
  2. Development
  3. Management
  4. Support


1. Design: in two clicks, please!


1.1 Layouts

Branding application design varies:
  • color scheme and application logo,
  • startup screens for content downloads
  • icons for additional webview with customer content.

For typical interface elements, we use the tools of the Sketch graphical editor, which allows you to automatically change the color of all elements at once, which speeds up the preparation of the design.

1.2 Slicing

When the design is agreed, it remains to "cut" the graphics for the developer. Here, the designer had slicing requirements and a slicing example from the main application. As a result, the Android developer could only substitute a folder with such a cut into the project, and the updated graphical interface of the application was obtained immediately, without additional gestures.
For iOS, it was even easier, because the icons were used in SVG format and they could be repainted programmatically. Therefore, for iOS, the main graphics were handed over to the developer in the form of the application color gamut:


All this made the preparation of graphics for both platforms quick, and the detailed formulation of the task allowed any designer freely to connect to this work.

2. Development and support


2.1 Code

On both platforms, the optimal organization of the code was seen in the general code module with the transfer of the parameters of the branded versions into a separate configurator. In iOS, the Viper architecture used allowed branding of the application by simply replacing the display modules and services.
They also laid the foundations of a modular structure for the future “designer” of possible custom features for a particular movie theater (in the form of an arbitrary element in a tabar).

2.2 Using automated development tools

Unit tests

Since the code base is common for the main and branded applications, the development of the main application made it extremely popular to use unit tests to verify the correct operation of the functionality of all versions of the application when changing the code in the kernel.
In particular, in the first place, tests were introduced to verify the correctness of data parsing, which worked immediately for all branded versions.

Build server

As the application versions became more and more, we set up a build server, which when changing the code in the project core automatically rebuilt the builds of all branded versions, and laid them out in a convenient form for testing (Fabric steers!). This reduced the time to prepare for testing and publication.

3. Management


With the third branded version, the question arose about their accounting and control in a convenient form. Without further ado, Google Sheet was selected with a table with technical and managerial information on key project milestones.



4. How we improved interaction with movie theaters


4.1 Instruction for movie theaters to get their own application

For the convenience of our partners, we have made step-by-step instructions explaining each step that a movie theater needs to take.

4.2 Adjustment of expectations

According to our business model, the cinema application is provided for free, and this imposes a number of restrictions on the application. Therefore, the problem of unjustified expectations of cinemas immediately surfaced. For example, we can not offer the cinemas “any” additional functionality, and therefore gave the cinema many refusals to their “Wishlist”. Of course, such refusals could have contributed negatively to our relations with cinemas, therefore, to adjust the expectations of cinemas, we supplemented our offer of cooperation with a description of the restrictions on the application provided regarding:
  • design (only logo and color scheme)
  • custom functionality (webview only)
  • application changes
  • application updates in the store


Custom functionality

An initial survey of movie theaters showed that the application should be a kind of designer, from which it was possible to assemble the necessary functionality for each movie theater. In particular, there was talk about a personal loyalty program, share promotion, restaurant reservations, purchase of popcorn and 3D points for the session. However, after working out the requirements for some “Wishlist”, in particular, for the integration of the savings card under the loyalty program, it turned out that the integration would be very expensive and would not be scaled to all cinemas, since many had individual loyalty programs. Thus, most of these “Wishlist” did not fit into our business model of a cheap branded application.
As a result of such a dropout, from the great and terrible requests “add me an erp-pen here, please”, there was only the opportunity to add to the cinema several elements in the menu that opened webview with links to the pages of the cinema website with the necessary content, such as News, Promotions, Restaurants .

Application development and updates on the App Store

The need to support multiple versions has led to the fact that the application should be updated in application stores when there is a critical accumulation of changes in the application core. Moreover, since all applications are template, then to minimize costs, the update will occur without notifying the cinema and without coordinating application changes. The same applies to the coordination of amendments. However, given that all changes are made to improve the application, no one has complained so far.
All this anticipated the birth of unjustified expectations among movie theaters regarding the application and did not lead to negative moments in communications with them.

4.3 Bottleneck - accounts to publish

After the creation of the 1st application, it turned out that the bottleneck in the chain was the provision by cinemas of their own accounts for publication on the App Store and Google Play. It was originally planned that the application would be published in the cinema’s own account, which in fact was a competitive advantage of the application.
However, in practice, it was extremely difficult for movie theaters to coordinate the setup and payment of Android accounts ($ 25 one-time), not to mention the App Store ($ 99 annually).

Therefore, it was decided to offer the possibility of publishing under our account. Let the name of the application developer in the line not be a movie theater, but our company, but in this way already 7 cinemas were able to get their applications!

results


All the described improvements in creating branding technology have borne fruit. From the initial 15 days for the first version, costs decreased, starting from the 4th branded version, up to ~ 4 hours for developing the code for the new version for iOS and up to ~ 6 hours for Android (on the chart, rounded up to 1 day of development).

Reduced development costs for each next branded application

The moral of this fable is such that consistent work on each process from coordinating the application to its publication leads to a saving of work time, and therefore to what customers love so much - to saving the budget.

Also popular now: