Practically everything in our life - be it health, property, or a tour - can be insured. More than a hundred insurance products with individual processes for processing insurance claims and indemnification, as well as several IT systems. This is exactly what we saw when we started working on the project of the AlfaStrakhovanie Mobile service application. The essence of the application was reduced to a nontrivial task to combine all insurance products and processes. “AlfaStrakhovanie” - 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. Further, theoretically, there are two options: to have several separate applications for each type of insurance, or still make a single application to manage all policies. The first option is simpler from the development point of view, the second is much more complicated, but much more convenient for the user. We went the second way.

From the post on Facebook to the project

The history of our interaction with AlfaStrakhovanie turned out to be non-standard. At first we met at the conference, talked, sent a proposal - there was no project, but the layout remained. Here I must say that we love to publish photos of the workflow in social networks and somehow posted a photo on Facebook. On the monitor of our art director, in general, accidentally turned out to be a big letter “α” .
')
And suddenly, AlfaStrakhovanie responded - great photo! What are you drawing? - and after that everything began to turn out. Thank you, Facebook :)

Alexander Prokopchuk, director of e-commerce department at AlfaStrakhovanie
“First of all, it was fundamentally important for us to thoroughly understand: why in general 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 are primarily waiting for the application to not be able to conveniently buy a policy (although it, of course, also), 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 a mobile application is one of the most important tools in achieving this goal. ”

Develop custom scripts from scratch

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


Arthur Sakharov ( mc_murphy ), technical director of Redmadrobot
"If today you are thinking of doing a banking application, you will see that customers signify their requirements like this:" Make us like Tinkoff Bank, Discovery or Sberbank. " If you need to write an application for renting a car, you can explore foreign experience. Alas, in the insurance of such benchmarks in the Russian market was not, and the Western experience was irrelevant due to differences in the legislative framework. "

Therefore, all business cases were developed by us independently from scratch. We have compiled the Feature List - we have compiled the most comprehensive list of functionality with an eye on business and user goals. But since we did not want to make a “hodgepodge” out of the application, each candidate candidate for implementation was seriously selected. Every time we asked ourselves whether the implementation of a function could solve business problems or whether its presence would really make the application more useful for the user. As a result, we got a much shorter list with which we started working.




Tatyana Anisimova, Business Analyst, Redmadrobot
“At the start, we faced several tasks. The most important of them are: to give the user access to all insurance products in a single profile, simplify the processing of the insured event and make the loss settlement process transparent. The application received a detailed Q & A, a detailed checklist for each insurance case and a wide range of electronic services that can be obtained directly via mobile. This is an opportunity to sign up for a doctor or call him at home, issue a claim 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 the operator; order a callback; IP telephony when calling from abroad);
• Remote settlement of losses under the hull insurance and passenger insurance policy;
• Writing to medical clinics and calling a doctor at home;
• Insurance company offices on the map and list;
• Activation of boxed products;
• Detailed instructions with an action plan in case of an insured event;
• List of active policies;
• Purchase and renewal of policies.

Of the e-services that have emerged due to the application, I would especially like to mention the most popular one: loss settlement on hull insurance.

Directly from the application, the AlfaStrakhovaniye client can apply for damages, take a picture of the accident site, damage (to eliminate the risk of fraud, when photos are taken at the wrong time and in the place where the accident occurred, only shooting directly from the application is allowed, just you cannot take and upload photos), certificates from the traffic police and immediately send for consideration to the insurance company. The application will be generated electronically, and AlfaStrakhovanie will immediately begin the settlement procedure.



The universal scenario for all insurance products in the application is as follows:
• There is an insurance case;
• The user presses the SOS button;
• Selects the type of policy and the target action (call the operator, call back, view instructions; drafting an insurance claim application directly through the application);
• Receives alerts on the progress of the case and further actions through push-notifications.


Call or callback order

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

Architecture: different backends and universal integration model

We developed Middleware to integrate different IT systems in which AlfaStrakhovanie insurance products live. It was necessary to think over which systems to take, some data were duplicated and it was necessary to decide what would be the source for us. Due to limitations in the internal systems (for example, it was found that we could not make a request synchronously to the server, since the update of information occurs once a day, and the server simply does not give us relevant data); in law and other areas, some scenarios had to be redone several times, from requirements to implementation.


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



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

1. The logic of even similar insurance products is quite different (for example, registration of accidents on hull insurance and CTP). As a result, it was impossible to simply take and bring into one common entity many small ones, it was often 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 the antenna for data transmission - in a critical situation of an insured event, the user least of all waits for the insurance application to “kill” his smartphone.

3. Asymmetry of GSM-traffic: the speed of sending and receiving data in mobile networks is very different. Mobile devices quickly receive data and give it away for a very long time. Therefore, when the user sees the progress indicator, most of the waiting time is spent on sending data to the server.

Yegor Taflanidi, Redmadrobot Architect
“While working on the application architecture, we thought that users might find themselves in a situation of limited access to the Internet, for example, in roaming. When you first start loading the entire amount of data. As a result, some of the functionality of the application is available without any Internet at all, and in principle the user does not see download indicators. If necessary, the information is updated in the background.

When designing AlfaStrakhovanie 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 the list of centers with identifiers. We went the other way, having foreseen a kind of “offline mode” of work - the application downloads maximum data that may be useful in the future, which allows using it even without connecting to the network. All requests are fired at the start in the optimal order. "

Swift, ReactiveCocoa and Android 6 Adaptation

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


Roman Churkin ( firmach ), leading iOS-developer Redmadrobot
“It was decided to use a bunch of MVVM pattern and ReactiveCocoa library. The fact is that when using the MVVM pattern, it is necessary to solve the problem of binding the View Model data and the reaction to changing this data to their display on the View. It is for the implementation of such bundles was used ReactiveCocoa. This avoided the bloated KVO syntax. We tried, made certain conclusions and for the time being we will use Reactive Cocoa neatly, so as to depend on a minimum on such a cumbersome library. It is possible that in the future we will abandon it in favor of alternative solutions. ”

Also on this project we started to introduce Swift into use. A part of the project is already 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, to release the application right away on the new version - this was a task that we solved well, judging by the zero number of crashes among users.

We also actively used the practice of code reuse - this reduced the development time and increased reliability. Among the reused modules, for example, was authorization via Touch ID.

In addition, during the development, we paid great attention to compliance with the best practices and safety standards. The protection measures in AlfaStrakhovanie Mobile are based on the approaches that we use in banking applications, and this is a rather high bar: from the banal SSL-pinning'a to protection against the debugger connection. The application will resist launching on jailbreak and root devices as much as possible.

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


Maxim Efimov ( MaximEfimov ), head of the Android-development group Redmadrobot
“Unlike Android 5, with the release of Android 6, the application by default does not ask for anything, it only requests access at the moment it needs. The user can enter the settings and turn off the permission that he gave earlier. This is good from the point of view of UX in terms of working with a smartphone as a whole, but from the point of view of ease of support for programmers 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 design of navigation

We made the first prototype of the application even under iOS7 - since then Apple's mobile operating system has experienced two major updates. Here is how the map of screens in the first version looked:




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



In the client profile there was an idea to place additional useful information such as a blood group, and also add an alert to the user's close 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 ability to change the color palette of the entire axis, and indeed it looked quite brutal, like a robot.





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



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




Sergey Galtsev, leading designer Redmadrobot
“At the end of the first presentation of the design to the customer, we inserted a video with paratroopers who jumped off a cliff and threw the thesis that we would be in free fall to test the usability of the application so that the parachutist could pass the help request script until the parachute opened. 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: the idea of ​​giving information to an expanding list is the usual such approach from the corporate software world - we refused. This works fine in a web environment, but not in a mobile application, here you need separate screens with an elaborate transition system.



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

Some statistics

88679 line of code is written;
850+ screens and 100+ icons are drawn ;
2 versions of iOS managed to come out during the preparation of the project;
From 4000 meters jumped 2 paratroopers who tested the application;
During the work, no developer or designer was hurt.

Results and plans

For the first four months, the AlfaStrakhovanie Mobile iOS application already has more than 28 thousand installations, the Android version has more than 33 thousand installations. 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. AlfaStrakhovanie Mobile is equal to one and a half applications of My Beeline , two Mobile Opening Banks and five Safe Trip applications (Renaissance Insurance).

So we did AlfaStrakhovanie Mobile. We hope that the application can serve as an example for our colleagues, which we ourselves so lacked at the start of the project. Now the application is available in the AppStore and Google Play , it works on smartphones for iOS 8+ and Android 4.4+. Of course, we have an impressive backlog of improvement tasks and a large number of hypotheses on how exactly these improvements are implemented. We are working on the system Agile, and releases with the enrichment of the application interface solutions and functionality are every two weeks. And, of course, we are open to criticism and suggestions - they can be shared in the comments. That's all, thank you for your attention!

We thank for the help in the preparation of the material by Alexander Lashkov and Stanislav Makarov .