Which user journey can deliver the best experience to Helppier Mobile’s users?
Continuing our Helppier Mobile development article series, we are happy to share the process of choosing the best user journey for our mobile users. At this moment, it’s important to note that this user journey might be chosen as a way to be the best option to deliver the best experience for our 3 target users: admin users, developers, and end-user.
First things first, who are our 3 target users?
Admin users are the ones responsible for the creation of every flow inside the Mobile app. This user is usually the first one to test the application because he/she is the one more interested in it, either because they are the ones that want to improve the onboarding process, reduce support costs or increase user conversion and engagement. Our goal with this type of user is to create a simple and easy way to create flows, delivering every specific need of these users.
The developers are responsible to install the SDK into the app. Our objective with them is to deliver the easiest way to install the Helppier SDK into our client’s app, but at the same time with the best performance.
Finally, the end-users, as the name says, are the final users. They are the users who are going to see the bubbles on our client’s application. Our team needs to deliver them a fast and updated experience.
Which are the Admin Users’ main needs?
Knowing that the admin users are usually the first user to the app, we started to investigate ways to allow this type of user to add different types of flows to their application:
- Onboarding sequences
- In-app messages
- Tooltips
- Guided tours
Adding onboarding sequences and in-app messages are the ones that these types of users see that have the highest gain because the user journey is shorter, and their impact is easier to understand (either the end-user saw them or not).
Tooltips and Guided tours are hard to understand/implement because the admin user needs to think about the sequence of the steps (and the content for all the steps), what is the interaction with each one (for instance, will the user need to click on an element to move to the next step) and the logic behind it (what happens if one of the steps is to tell the end-user to open a menu, but the menu is already open?). This brings a lot of experiments, where the admin user tests different variants and error scenarios (what to do if the guide cannot move to the next step because the element is not in the page?) of the same guide until he/she is satisfied with it.
Some possible solutions
We decided to start looking for solutions for the most difficult need: The guided tour and tooltips. For our admin users to be able to create these types of flows, we need them to be able to interact with their application and at the same time capture each step they do. Several solutions were considered:
- Create a plugin for the IDEs that allow admin users to create a guided tour in these environments.
- Create a back office with a web builder that can read the mobile application code and then allow the admin user to record the steps.
- Connect the physical device to the desktop via cable and then mirror the mobile app. The admin user will interact with his/her device and all input actions and screen are recorded and sent to a back office.
- Create a specific SDK that when added to the mobile application would allow the admin user to record the steps in it.
Option 1
Option 1 was discarded because this would mean that the admin user would need to be a technical person and defeating the purpose of this being used by someone from the marketing, product management or customer support areas. All the other options were analyzed in detail.
Option 2
First, we analyzed other tools that have the same type of setup like some testing tools (for instance Appetize or TestApp). They all start by uploading the Android or iOS application to the back office, then show the home page of the application and allow the users to interact with it. This is a very hard option to implement. We need to set up a server where we add an emulator, then we needed to install our SDK on it, and then simulate/stream every action done by the admin user to the server and send a screenshot after that.
Due to this, we needed one server (a docker-machine) per recording process (so an admin user could create more than one guide at each time). This made this option not just much harder to implement but also made the business case (revenue per application that uses our SDK against the costs of running the whole system) much difficult to support and the engineering costs of the solution much harder to do (for instance we need to shut down and delete the server every time the admin user finish creating a guide to keep costs low). We achieved this by checking how others do it in the Selenium Grid testing space and created a similar approach.
Option 3
First we analyzed other tools that have the same type of setups like mirror tools or other testing tools. They start by installing the tool on the desktop and then connecting the mobile device with a USB cable or using an emulator of the device. By using this type of system (we used the Appium testing tool to check the user journey), we saw that, although it was technically feasible, it is still too technical (the admin user needs to download extra code, change the device settings to developer and event in some cases install some developer tool from the command prompt).
Option 4
After analyzing and implementing parts of the previous options, we found that the best way to do this is to create an SDK that the developer needs to import and then create a special version of the app with our SDK. Then this app is shared with the admin user to create the guides. In order for us to understand the actions the admin user would do, we add our UI components, that when activated by the admin would do the action for the user and in this way, we know what was the element that was selected. Whenever that happens, we send a screenshot of the application to our server, so we have a sequence of steps done by the admin user ready for the second part: Add content to each step. We did it in this way, so the admin user has more space to add the content, it’s easier to get the content (for instance an image or video) and he/she has a keyboard to add text (and change its style).
For the developer, Option 4 is the one that has less friction because he/she only needs to add our admin SDK in their development environment, build their application with it and share it with the admin user.
To deliver Helppier’s experience to the end users, the process is even easier, he/she only needs to add our end user SDK in their development environment, build their application and then submit it through the app store (in the same way that they already do to deploy the application).
For the end user, there is only one viable option: he/she does not need to do anything extra besides downloading a newer version of the application with our end user SDK.
The best solution
As noted in the previous paragraph, with Option 4 we need to deliver two SDKs to support guided tours and tooltips. On the other hand, for onboarding sequences and In-app messages, we found out that the best option is to use Option 4 but in a simpler way. This is because, with the Helppier Mobile, the admin user just needs to select the type of flow and its position (full screen, top banner, bottom footer, center of the screen message), so the developer does not need to add the admin SDK.
This is yet another advantage because it allows the admin user to create these types of content without any action needed by the developer. The admin user can play around in the Helppier back office, changing the content at will but in order to accelerate the development of this type of content, we allow the user to choose one of the existent templates and preview it in a device preview area (like a simulator).
What’s next?
We are happy to keep sharing articles regarding the Helppier Mobile development. Please stay tuned to not miss any part of this process. If you haven’t our previous articles, please check the begging of this process at our Helppier for Mobile: The pursue for the best mobile SDK article.
