Almost everything in our life - whether it is health, property or a trip to the country - can be insured. More than a hundred insurance products with individual processes for filling out insurance claims and recovering losses, as well as several IT systems. This is exactly what we saw when we started working on the project of the service mobile application Alfa Insurance Mobile. The essence of the application was reduced to the non-trivial task of combining all insurance products and processes of Alfa Insurance - to make for a mobile user a single channel of communication with the insurance company for all occasions.

We accept as an axiom that customers need mobile access to insurance services. Theoretically, there are two options further: to have several separate applications for each type of insurance, or still make a single application for managing all policies. The first option is simpler from a development point of view, the second is much more complicated, but much more convenient for the user. We went the second way.

From Facebook post to project

The history of our interaction with AlfaStrakhovanie was non-standard. First, we met at a conference, talked, sent a proposal - there was no project, but the layout remained. Here it must be said that we love to publish photos of the workflow on social networks and somehow posted a photo on Facebook. On the monitor of our art director, in general, by chance there was a capital letter “α” .

And suddenly they reacted to Alfa Insurance - a cool photo! What do you draw? - and after that everything started spinning. Thank you, Facebook :)

Alexander Prokopchuk, Director of the Department of Electronic Commerce at AlfaStrakhovanie
“First of all, it was fundamentally important for us to thoroughly understand: why do the insurance company and its customers need a mobile application. We seriously approached the study of this issue, conducted research and focus groups, as a result of which it turned out that customers first of all expect from the application not to be able to conveniently buy a policy (although it, of course, too), but see in it a tool that helps to cope with emergency situations and generally facilitates work with all insurance products. Our goal is to be a leading insurance company in terms of service, and the mobile application is one of the most important tools in achieving this goal. "

Custom scripting from scratch

At the time of the start of the project, we had experience in creating an insurance application for people traveling abroad. In fact, there was only one scenario, and it was already not easy, but there were much more scenarios.


Arthur Sakharov ( mc_murphy ), Technical Director of Redmadrobot “If you are planning to create a
banking application today, you will see that customers designate their requirements this way:“ Make us like Tinkoff Bank, Otkrytie or Sberbank. ” If you need to write an application for renting a car, you can study foreign experience. Alas, there were no such benchmarks in the Russian market in insurance, and the Western experience turned out to be irrelevant due to differences in the legislative framework. ”

Therefore, all business cases were developed by us independently from scratch. We have compiled Feature List - we have compiled the most comprehensive list of functionality with an eye to the goals of business and users. But since we did not want to make a “hodgepodge” from the application, each feature candidate for implementation went through a serious selection. Each time we asked ourselves whether the introduction of a particular function can solve business problems or whether its presence will really make the application more useful for the user. As a result, we got a much shorter list with which we began to work.




Tatyana Anisimova, Redmadrobot Business Analyst
“At the start, we had several tasks. The most important of them: give the user access to all insurance products in a single profile, simplify the registration of the insured event and make the loss settlement process transparent. The application received a well-thought-out Q&A, a detailed checklist for each insured event and a wide range of electronic services that can be obtained directly through mobile. This is an opportunity to make an appointment with a doctor or call him at home, apply for an insured event and activate insurance products directly through the application. ”

Application functionality:
• Emergency communication with the insurance company via the SOS button (call to the operator; order a call back; IP-telephony when calling from abroad);
• Remote loss settlement under CASCO and passenger insurance policy;
• Record in medical clinics and call a doctor at home;
• Offices of the insurance company on the map and list;
• Activation of boxed products;
• Detailed instructions with a plan of action in the event of an insured event;
• List of existing policies;
• Purchase and extension of policies.

Of the electronic services that appeared thanks to the application, I especially want to note the most popular: CASCO loss settlement.

AlfaStrakhovaniy client can file a claim for damages directly from the application, take a picture of the accident scene, damage (to exclude the risk of fraud when the pictures are taken at the wrong time and in the wrong place where the accident occurred, only shooting directly from the application is allowed, just photographs cannot be taken and downloaded), certificates from the traffic police and immediately sent for consideration to the insurance company. The application will be generated in electronic form, and Alfa Insurance will immediately begin the settlement process.



The universal scenario for all insurance products in the application is as follows:
• An insured event occurs;
• The user presses the SOS button;
• Selects the type of policy and the target action (call to the operator, call back, viewing instructions; drawing up an application for an insured event directly through the application);
• Receive alerts about the progress of the case and further actions through PUSH notifications.


Call or call back

The options after clicking the SOS button differ depending on the type of insurance product. Initially, we planned to “hardcode” different scenarios for different policies, but in the end we did differently - we added a variable parameter to the specification, and now from middleware we get a set of “SOS activities”, which is calculated depending on the user's active policies. If you add other scenarios in the future (for example, if it becomes possible to arrange an insurance case through the application for new types of policies), you will not need to make any changes to the code structure to display their functions on the global changes screen. Just for new insurance products an additional parameter will come in the method with middleware.

Architecture: different backends and a universal integration model

We developed Middleware for the integration of various IT systems in which Alfa Insurance products live. It was necessary to think over what systems to take from, some data was duplicated, and we had to decide what would be the source for us. Due to limitations - in internal systems (for example, it was discovered that we cannot make a request synchronously to the server, since the information is updated once a day, and the server simply will not give us the latest data); in legislation and other areas, some scenarios had to be redone several times, starting with requirements and ending with implementation.


Egor Taflanidi ( BepTep ), architect of Redmadrobot
“Usually we write the API specification ourselves, following which the fronts will then interact with the middleware server or customer systems. Following the REST ideology, we have standardized this kind of documentation and use it from project to project. The direction of server development in our company is still young, but our backend developers have already created for themselves their own framework, which they use to develop an intermediate layer, and in the future integration will be very, very fast. "



Also during the design process, we had to take into account a number of restrictions:

1. The logic of even similar insurance products is quite different (for example, the design of accidents according to hull and compulsory motor liability insurance). As a result, it was impossible to simply take and bring into one general essence many small ones, often it was necessary to implement similar, but slightly different elements in different insurance products.

2. It was necessary to achieve a minimum battery consumption due to the minimum use of an antenna for data transfer - in a critical situation of an insured event, the user least expects the insurance application to “kill” his smartphone.

3. Asymmetry of GSM traffic: the speed of sending and receiving data in mobile networks varies greatly. Mobile devices quickly receive data and return it for a very long time. Therefore, when the user sees the progress bar, then most of the waiting time is spent sending data to the server.

Egor Taflanidi, architect of Redmadrobot
“While working on the architecture of the application, we thought that users might find themselves in a situation of limited access to the Internet, for example, in roaming. At the first start, the entire amount of data is loaded. As a result, part of the application’s functionality is available without the Internet at all, and the user, in principle, does not see download indicators. If necessary, information is updated in the background.

When designing Alfa Insurance Mobile, we proceeded from best practices. If the policy contains a field for service centers, then usually applications make two requests - loading the policy itself and a list of centers with identifiers. We went the other way, providing a kind of "offline mode" of work - the application downloads a maximum of data that may be useful in the future, which allows you to use it even without connecting to a network. All requests are fired at startup in the optimal order. "

Swift, ReactiveCocoa and adaptation for Android 6

During the project, we tried some innovations, for example, the ReactiveCocoa library, which many developers use in the fashionable paradigm of functional reactive programming, and we were also interested.


Roman Churkin ( firmach ), Redmadrobot ’s lead iOS developer
“It was decided to use a bundle from the MVVM pattern and the ReactiveCocoa library. The fact is that when using the MVVM pattern, you have to solve the problem of binding the View Model data and the reaction to the change of this data to its display on the View. It was to implement such bundles that ReactiveCocoa was used. This avoided the bloated KVO syntax. We tried, made certain conclusions, and for now we will use Reactive Cocoa carefully so that at least it depends on such a bulky library. It is possible that in the future we will abandon it in favor of alternative solutions. ”

Also on this project, we began to introduce the use of Swift. Part of the project has already been written on it, this practice will be developed, we plan to use Swift more widely. Although Apple released Swift a year ago, we were in no hurry to switch to it. In fact, we started writing on Swift version 1.2, already knowing the expected release date of version 2.0, in order to release the application immediately on the new version - this was a task that we solved well, judging by the zero number of user caches.

We also actively used the practice of code reuse - this allowed us to reduce development time and increase reliability. Among the reused modules, for example, was authorization via Touch ID.

In addition, during the development, we paid great attention to compliance with best practices and safety standards. The security measures in Alfa Insurance Mobile are based on the approaches that we use in banking applications, and this is a pretty high standard: starting with the banal SSL-pinning and ending with protection against connecting the debugger. The application will maximize resistance to launch on jailbreak- and root-devices.

Alfa Insurance Mobile is not a cross-platform solution, but two separate native developments for iOS and Android. With similar functional requirements in iOS and Android, different UX patterns and patterns.
We had to dance a little with tambourines in order to adapt the application for Android 6 and integrate a new Google permission model into it.


Maxim Efimov ( MaximEfimov ), leader of the Android development group Redmadrobot
“Unlike Android 5, with the release of Android 6, the application does not ask for anything by default, but only asks for access when it needs it. The user can go into the settings and turn off the resolution that he gave earlier. This is good from the point of view of UX in terms of working with the smartphone as a whole, but from the point of view of ease of support for programmers it is very inconvenient. A couple of weeks after the update, the entire GitHub was literally packed with Android Permission libraries. We also made our own library, which is integrated into our own framework. ”

Design and engineering of navigation

The first prototype of the application we made back under iOS7 - since then, the Apple mobile operating system has survived two major updates. Here's what the screen map looked like in the first version:




Andrey Lisitsyn, art director of Redmadrobot
“What ultimately came to life in a real application is seriously different from this prototype, although some generic features have been preserved. One of them is a large SOS button with animation that opens to the full screen, filling everything around with red. When loading the geolocation for the user search indicator, we came up with a satellite image and a set of funny icons, some of them were drawn literally from nature :) "



In the client’s profile there was an idea to place additional useful information like a blood type, and also add an alert to the user's relatives after an emergency call. The prototype was prepared not only for iOS, but also for Android and Windows Phone. For the Microsoft mobile platform, we even made a dark version, because historically WinPhone had the opportunity to change the color palette of the entire axis, and indeed it looked pretty brutal, robotic.





Now about what happened in the end. Starting to design the navigation, we planned to use the tab bar, as recommended by Apple in our guidelines, but at the wireframes level we realized that the main screen is too overloaded, and the main interface element, the SOS button, is lost against this background.



The SOS button is always available, even in unauthorized mode. During the registration process or before it starts, you can already call the insurance company. Since the center element of the interface - the large SOS button - did not fit into the standard tabbar, we saved important blocks of functionality on the main screen (SOS button, statuses and notifications for insured events, viewing policies with expiration dates and buying new policies), and transferred the rest in the menu (user profile, offices, application information).




Sergey Galtsev, Lead Designer, Redmadrobot
“At the end of the first presentation of the design to the customer, we inserted a video with paratroopers who jumped from a cliff and threw in the thesis that we will experience usability of the application in free fall so that the paratrooper can go through the help request script before the parachute opens. And we really did it. ”


The initial customer requests for design have undergone a number of significant changes in the process of discussion and work on the project. For example, in terms of content delivery and navigation: we rejected the idea of ​​providing information with a drop-down list - a common approach from the world of enterprise software. This works fine in a web environment, but not in a mobile application, it requires separate screens with a well-thought-out navigation system.



There are a number of animations in the application, during the creation of which we tested the Pixate prototyping tool, you can read about this in one of our recent articles . And more about how the design of the application was created - in the case on Behance.

Some statistics

88679 lines of code are written ;
Drawn 850+ screens and 100+ icons;
2 versions of iOS managed to be released during the preparation of the project;
From 4000 meters 2 parachutists jumped who tested the application;
In the course of work, no developer or designer was hurt.

Results and plans

In the first four months, the Alpha Insurance Mobile iOS application has more than 28 thousand installations, the Android version has more than 33 thousand. Statistics show that this is a very stable application - the number of crashes on iOS does not exceed 0.5%. By the amount of source code, this is our largest project. Alfa Insurance Mobile equals one and a half My Beeline applications , two Opening Banks and five Safe Trip (Renaissance insurance) applications .

So we did Alfa Insurance Mobile. We hope that for colleagues the application can serve as the very example that we ourselves lacked at the start of the project. Now the application is available on the AppStore and Google Play, works on smartphones under iOS 8+ and Android 4.4+. Of course, we have an impressive backlog of tasks for improvement and a large number of hypotheses on how to implement these improvements. We work on the Agile system, and releases with enrichment of the application with interface solutions and functionality go every two weeks. And, of course, we are open to criticism and suggestions - they can be shared in the comments. That's all, thanks for watching!

Thank you for your help in preparing the material by Alexander Lashkov and Stanislav Makarov .