HeadHunter Evolution on iOS

The other day, our team released the updated HeadHunter app for iOS . With this release, in addition to the updated interface and the revised code, long-awaited possibilities for editing the summary, updating its publication date and changing the visibility appeared. And we added the experimental ability to create a resume from scratch.

Since its birth in February 2012, the application has experienced a difficult childhood.
The first version of the application was developed by external contractors. However, we did not have a relationship with them, and for some time the application lived its own independent life. And in February 2013, our mobile development team took over it, which by this time was already actively engaged in developing the HeadHunter application for Android .
')
The first version of the application had:

• about 16 thousand users (judging by the downloads);
• an incredible number of falls;
• unknown number of real users and their problems.

As you understand, people who were very loyal to the hh.ru service could use this application, so it was decided to go to a new quality level.

“Everybody get out of the dusk!” (C)

First of all, I wanted to make sure that users could use the application that was available at that time without frequent drops. To do this, it was necessary to stop working blindly. Therefore, we took in hand debugger, catching and correcting the most obvious errors that could reproduce.
From an instrumental point of view, we used leaked detection tools supplied with xcode. About it there are several efficient articles on Habré .

Next, we organized the distribution of the application through hockeyapp.net. In addition to distribution, this service gives clear crash-notifications. And he also supports crash notifications directly into the bugtracker: in our case, the integration option with jira came up.

To have detailed technical statistics, including the number of errors, we added statistics from flurry.com to the application.

After that, the application was released in March 2013 under version 1.2
In total, it took us 3 public releases to cure most of the kresy, refactor the code, and thereby make the behavior of the application much more stable.
However, when updating the application with new functionality in January 2014, we received an even more incredible number of crashes. But this time we were fully armed: the presence of monitoring and error reporting system helped us very quickly catch and fix more crashes. The next update, released after 7 working days, including a review in the Store, was already stable after the first release.



As can be seen on the graph, we started with ~ 900 crashes per week (upper graph), the crash was in every 50th session of the running application. (lower graph) (graphs obtained from flurry.com).

If you look at the chart, it looks scary only the absolute number of crashes. The application’s relative multiplicity of audience was more stable than its predecessor.
The next step in setting up the team’s work will not be a reactive response to errors, but a proactive one.

Note on the organization of testing: we have with varying success turned out to use hockeyapp to demonstrate intermediate results within the company. He has a rather complicated scheme for connecting new users. As a result, we have a well-established scheme with two iOS applications in hockeyapp: one for daily updates and demonstration of results within the development team, the other for demonstrating a wider audience of testers, updated every 2-4 weeks.
But testing on some stable and extensive group of alpha testers on their own could not be organized. I would be glad to hear the experience of readers, as they organize this kind of testing.

“To start from scratch before it takes a long time to crawl up” (c)

After stabilization of what we already had, we started to recycle the application, as to convert it to a new design, we had to rework all the code.

Incremental update did not work. It is simply impossible to release a half-converted application - there will be too many interface differences. Making changes in two code bases at once is an expensive solution, fraught with code mismatches. By that moment, two new conditions arrived that needed to be taken into account:

• API version hh.ru was released (not yet public, but it was necessary to run it in combat conditions);
• The site has been implemented the possibility of authorization through social networks.

We still didn’t have a finished application with a new design and it was still a long way from the release, much of the feedback was about authorization errors. This inspired us to experiment: to release a quick release on the old code base, in which to implement work on the new API and authorization through social networks.
By mid-September 2013, we rather quickly prepared and released such an update. After that, in October, we launched a joint promotion for mobile applications in the form of a smartapp banner, which gave a significant increase in both the settings of both applications and the number of active users.



This release gave conflicting, but valuable experience. At the junction of the new API and authorization, we received a decent amount of errors. The reaction to this update was a wave of low ratings in the App Store from users.

What we have learned from this for ourselves (in fact, all the conclusions are captaincy confirmed on personal experience):

• do not make hasty releases :)
• positive reviews are rarely written, but negative ones are easy.

If you look at the picture on the key metrics of the whole, there was a positive trend:

• there was an increase in the number of active audiences, a relevant increase in the number of installations;
• the number of targeted user actions in the application also grew.

This made it clear that there is a positive trend, which means we are on the right track.

By the way, to monitor user behavior in applications, we use time-tested tools: flurry.com and Google Analytics. And also we use Distimo.com for the general monitoring behind applications for different platforms. Since All these tools provide an API for accessing our data - we took advantage of this opportunity and built some custom statistics in which we can compare user behavior on several platforms at the same time.

And here he is, the long-awaited

The experience of the previous release gave us excessive caution. We decided not to do it just for the sake of redesign. and added extra value:

• resume editing;
• update the date of publication;
• and as an experiment, the creation of a resume was worked out.

About redesign, in general, you can write a separate article - there was everything: test groups, and redrawing each of the models many times into several options, and fierce daily discussions of each version of the layout, and live prototypes.

To evaluate interface layouts from all services, flinto.com helped us a lot, which allowed us to very quickly prototype an interactive interface. By the way, we actively used the same service for prototyping the android application and the new version of the mobile site.

As a result, we got this new design:


Meanwhile, beta iOS 7 appeared in the arena, and we haven’t transferred the whole application to the new rails yet. Therefore, they allowed themselves to change everything once again:


Separate attention deserves the ability to manage your resume directly from the phone. Inside the team we went through many stages from “this is a serious process, it’s impossible to write a normal resume from the phone”, to “this is a very useful thing”.

In my opinion, a fairly successful professional profile editing model is represented by LinkedIn. Colleagues implemented the work with the profile in two modes: viewing and editing, between which the user can switch.

In the hh.ru application, we decided to combine the viewing and editing mode, assuming that the main use case would be a short review of our resume and making minor adjustments and additions (for example, updating work experience).

As a result, the resume editing interface is as follows: the first screen allows you to quickly view all the resumes, and the screen for each block of properties allows you to immediately make corrections and additions.



For the experimental possibility of creating a resume, we chose the step-by-step wizard mode, with which you can go through the considerable number of steps that are required to create a high-quality resume. In general, we will have to work on the resume creation interface, so we will be happy to hear recommendations and suggestions for improving it.

The task of managing the summary in the application hh.ru we, in my opinion, managed to solve at a good level. Statistics on the events in the application will show the real picture.

Talk to me.

Interaction with users in the AppStore is such a special story.
Compared to GooglePlay functionality, the App Store’s ability to interact with users is, to put it mildly, limited. The release cycle can be long due to a review. Contact with users of the platform is not possible.

Due to the inability to simply respond to a person, his negative results in a low public rating. Dialogue with the user helps to solve his specific problem in typical cases to identify shortcomings and eliminate them.

We started experimenting with helpdesk services integrated directly into the application. Hh.ru already has several ways to interact with users, including solutions from Russian service providers. Unfortunately, none of them provides the means to work in a mobile platform. I had to look for such tools in the global market.

At the moment we are using the helpshift.com service, because it supports the Russian language and is simply integrated into the application, although there are still some interesting tools. There are, of course, technical deficiencies, but we successfully and efficiently solve them together with the development team of the service.

I should note that the ability to communicate with the user in the application gives several advantages:

• negative user experience is transformed into a neutral or positive, instead of splashing into a public assessment without solving the problem;
• current feedback is easily collected on the most important features;
• There is an additional source of information about the shortcomings of the application.

I still can not assess the degree of influence of such a functional on a public assessment, but I can already say unequivocally that it is positive.

Where are we now

“Where have all our adventures led us?” You ask.
At the moment we have:

• more than 200,000 application downloads from the AppStore
• MAU in the region of 100 000 - 130 000 users, and the rate is growing
• AppStore rating for the latest version of the application varies between 4 and 5 stars
• the application lives fairly stable in the top positions of the top free applications in the Business in Russia category
• the audience of the application is still the most active among all mobile platforms on which HeadHunter is represented, although not the most numerous

As you could see from the graphs at the beginning of the article, we still have a pool of errors. And that means we have work to do. Of course, we plan to continue to engage in not only increasing stability, but also introducing new features and not very noticeable at once, but very useful improvements.

I hope the new application and its development experience will be useful to you! Accept thanks to the stars :)


I think that Habr's audience does not need to wish good luck in search of work - she herself finds professionals. Just keep your resume up to date!