The migration flow is a vital page that deserves our close attention. It is the first impression that migrated users get from our dashboard. It also represents a possible source of revenue if the users continue to use our services.
However, the migration flow is not performing well. It is one of the most common issues that users contact our customer support about. The data shows that the migration success rate is very low. We need to improve it.
After redesigning the migration flow, we achieved a higher success rate and more revenue potential. Moreover, we can reduce the number of user inquiries related to the migration.
This article will give a brief overview of the process and the outcomes without revealing any sensitive data, as per the company policies.
Better clarity when choosing and configuring fleet regions AccelByte Multiplayer Server
Before and after improvement
One of the essential steps users need to take when running a multiplayer server is creating a new fleet. A fleet is a system that deploys and connects dedicated servers, allowing players to join a game session. To set up a fleet, users must provide several pieces of information and configure fleet specifications—one of the most important being region capacity.
The Problem
Shortly after I joined the project, we received feedback from users reporting that their fleets couldn’t deploy any dedicated servers. They reached out, unsure of what went wrong. After investigating, we found that the root cause was missing configuration in the region capacity. Users simply left it blank, assuming it would be automatically managed. Unfortunately, this wasn’t an isolated incident—many users faced the same issue.
Key Insights
Our team delved deeper into user feedback and uncovered three main reasons behind this problem:
Assumption of Automation: Game admins believed that the region configuration was automatically handled by the system, so they left it blank.
Confusion with QoS Regions: Game admins mistakenly thought that setting up regions on the QoS Regions page was sufficient. In reality, QoS (Quality of Service) Regions are used to optimize network performance by selecting the most suitable server region based on latency, while region capacity specifically configures the number of instances available per region.
Lack of Guidance: Users weren’t sure what to do in the region capacity section, as the required inputs (like Min. DS, Max. DS, Buffer, and Region Capacity) lacked sufficient explanation. This uncertainty led users to skip the configuration entirely.
The Solutions
To address these issues, we implemented the following improvements:
Interactive Guidance: We added a small action prompt to guide users through selecting and filling in the required information, making the process more visible and approachable.
Contextual QoS Information: We included brief, informative text about QoS status for each region, clarifying its purpose and how it differs from region capacity.
Clear Explanations: We provided contextual information about the key configuration fields (Min. DS, Max. DS, Buffer, and Region Capacity) to eliminate ambiguity and guide users step by step.
These changes significantly reduced confusion and support tickets related to region configuration. Users now better understand how to set region capacity correctly, and the frequent questions about this process have vanished.
Make instance type selection easier by better grouping and sorting AccelByte Multiplayer Server
Before and after improvement
One of the key steps users need to take when running a multiplayer server is creating a new fleet. A fleet is a system that deploys and connects dedicated servers, allowing players to join a game session. To set up a fleet, users must fill out several details and choose specifications, with one of the most crucial being the instance/server selection.
The Problem
When I first joined the project, I approached it with a fresh perspective, testing the product as a new user. One challenge immediately stood out: selecting the right instance was time-consuming due to an overwhelming number of options. To validate my experience, I gathered user feedback—and it turned out I wasn’t alone. Many users faced the same issue.
Key Takeaways
After discussions and analysis, here are the key takeaways:
Provider Preference: Game admins often have strong preferences for specific host providers. As the company planned to add more providers, it was important to design a scalable solution.
Decision Hierarchy: Game admins typically prioritize RAM size first, followed by CPU Cores, and finally price.
Pricing Confusion: Users frequently asked for instance pricing, even though a link to the pricing document was already provided—indicating the link was either hard to find or unintuitive.
The Solutions
To address the usability challenges and enhance scalability, I made the following changes:
Improved Scalability:
Previously, the instance selection lacked flexibility for future expansions, especially when adding new host providers.
I restructured the layout to accommodate multiple providers, ensuring it would remain efficient as new options are introduced.
Server Type Categorization:
Instead of listing providers directly in the dropdown, I grouped them by server type, making it more intuitive for users to select the appropriate option.
This approach minimizes cognitive load by clearly indicating whether the server is optimized for production, general use, or other specific functions.
Better Organization through Grouping:
The original long, unstructured list made it hard to scan and select instances.
I introduced an accordion-style grouping based on instance family (e.g., CPU, GPU, General Purpose), allowing users to expand only the relevant category.
Changed the interaction from sort to filter based on CPU and RAM to improve findability.
Clearer Information Labels:
The ambiguous Info label led to confusion about what the button would display.
I replaced it with “Pricing Info” to set clear expectations and reduce uncertainty.
As a result, the confusion around instance selection significantly decreased, and the streamlined process is still in use today.
Improve QoS region's information clarity on region configuration AccelByte Multiplayer Server
Before and After Improvement
In AccelByte’s Multiplayer Server, there are two types of region entities that serve different yet related purposes:
Fleet Region DS Configuration: Defines the number of Dedicated Servers (DS) available in each region. It sets the capacity for game sessions by specifying Min. DS, Max. DS, and Buffer, based on the Region Capacity.
QoS Region: Determines the Quality of Service by selecting regions with the lowest latency for players. It ensures that game sessions are hosted on the most optimal server location.
The Problem
We encountered cases where users had correctly configured the Dedicated Server and Buffer amount for a specific region, but the fleet still failed to claim a server in that region. After a thorough investigation, including analyzing analytics data, we discovered the root cause:
Some users did not activate any QoS region during the setup process.
A significant number of users never even visited the QoS page while configuring their fleets.
This confusion arose because users didn’t fully understand the relationship between Fleet Region Configuration and QoS Region—assuming that setting up the DS configuration alone was sufficient.
The Solution
To address this issue quickly and effectively, we implemented the following improvement:
Dynamic Alert: When users select and fill the Dedicated Server and Buffer amount for a region that has no active QoS, a dynamic alert now appears, informing them that the QoS region must be activated for the configuration to work.
This quick-win solution not only prevents fleet deployment failures but also educates users on the importance of enabling QoS regions—even if they are already familiar with the technical terms.
With this small but strategic update, users now receive real-time feedback during setup, significantly reducing configuration errors. This proactive alert serves as a subtle educational touchpoint, helping even advanced users avoid common pitfalls.
Project Background
Migration flow is the first impression that users get from our dashboard. It also represents a possible source of revenue if the users continue to use our services.
After a deeper review, we got that this flow have some problems, such as:
Migration issue has the most tickets from customer success team
Only ~20% from the total visitors are successfully submitted
From the successfully submitted requests, less than half of them are successfully migrated
Discovery
The problems that we discovered are still wide, so we need some further and deeper research to get into the core problems and what disrupt the users from achieving their goals.. For this case, I used these methods:
Desk Research
Frequent issues from the users' conversations with agents
Why my migration request rejected?
What URL should I type when I want to upload my backup files?
Very unclear information on what should I fill
What do you mean by login URL in this form?
I can do it easier by myself in another provider, why I can’t do that here?
Funnel analysis
Here are the cause of the failed migration:
Unaccessible WordPress or other CMS’ login URL
Nameserver connection issue
Unsupported uploaded files
Qualitative Research
User interview
I invited 3 users that migrated from another hosting providers, and I asked them these key questions:
What motivate you to migrate into our service?
What step do you think is the most difficult in order to migrate your website? And how you solve that?
What kind of ideal process that you expect to do in order to migrate your website?
How can you say the migration process of your website is successfully done?
Initial testing
In the same session with the interview, I also gave the users some scenario to get their way of thinking on filling out the migration form. These are the key scenarios:
From those researches, we get these key themes and insights:
Density
There’s a lot of technical information and things going on inside the current version of migration page that makes some users failed to understand the context of the needed questions.
Transparency
The user can’t really tell what comes next after they submit the website migration request, and that makes some of them feel anxious when clicking the Submit button.
Error prevention
In the current version, the user will get the error notification after the migration request submitted and processed, and it takes too much time for them to recover from that errors.
In summary,
The user that wants to migrate their website needs a clear and detailed explanations about the migration requirements, so they can migrate their website easily.
Constraints and challenges
To get the happy-ending for all of the parties, I collected the insights from the team as well, moreover the engineers and product higher-ups. And these what they were concerning about this project:
Short timeline
As the project was to solve a "generational" problem, the team already felt the frustration as well when working on the tasks that related with this issue. So the team want to have a tight timeline and limited resources to solve this migration issue.
Tracking-rich design
One of our bottleneck in solving this migration issue was the lack of behavioral data on the previous version of the migration page. It was because the team had a lot of constraints when want to add the tracking due to the dense page layouts. So the new solution must be tackling this one as well.
Main concept
From the mentioned constraints, me and the team converge the rough ideas into the main concept, we can quickly get the idea and refer to this main concept.
Expand
Make the form as step-by-step
Simple questions, but a little bit longer process
Reuse the existing Hosting Onboarding overall layout to fasten the process and iterate later
Automate
Automatically detect user’s website details, like CMS, etc
Auto-fill or even skip some of the flow
Can be done gradually in several iterations, learnings and code research needed
From previous main concept, we decided to break the page into several key steps: Platform Detection, Method Selection, and Destination. We also add a summary to let the user double-check and validate their website information before requesting.
As mentioned before, the team decided not to do a lot of efforts and reusing something that we already developed before and existing right now to give the users familiarity of our system.
So we reused our existing Hosting Onboarding template as the main layout, and modified some steps that needing a unique visual treatment to give the user guidance of what they should fill, and here are the layouts and illustrations style:
Simple selection image
Illustration for indicating something simple and not needing any more explanations, like platform logos.
Instructional image
Illustration for giving the user guidance for something that they think is hard to do or needing more context, like uploading a file, because there are a lot of steps that they need to do.
Action selection image
Illustration for indicating an actions that they will do, so the users can foresee what they will do next, like in methods selection.
Conditional image
Illustration for indicating the conditions that will happening after choosing several questions, like when the users choosing the output destinations of their website.
Here is the final result of the project. This one is the base iteration that the team will explore more and evaluate. So there will be a lot to be evaluate and iterate in the future.
Here is the design of the key pages of the feature. These pages are the one that can solve the passengers' problem regarding to the navigation.
Disclaimer: I concepted this without any detailed technical specs, and only based on my own assumptions and experiences on designing an online transport apps.
Additional form to input destination
As I state before, I want to ask the goal, which is the destination, upfront. And the right placement of this input is inside the main bus service selection section that takes a lot of attention.
Route selection screen
In this screen, I want to give the user a summary of the main information that the passengers need when using a bus service. Here I show the route summary (in map), estimated time, and bus type that they will use.
I also add the parking availability. So the passenger that using their own vehicle can expect where to park their vehicle.
Route details screen
This will be the details of the route summary. Passengers will see the details like the starting bus stop including the distance from their current position, bus type that they will use including the price, where to switch the bus type if needed, and the final bus stop near the destination.
Roaming screen
This will be the screen after the passenger hit Use This Route button from previous screen. There will be various states of this screen depend on what state the passenger into.
For example in this screen, is the state when the passenger is waiting in the bus stop. In this case, I show the live location of the bus (yes, the bus already have a GPS tracker), the price, vehicle license number for easier identification, and the bus code that reflect how the bus code shown in real life (most important).
The states will automatically switched after reaching certain checkpoints for easier interaction. Just like in mainstream ride hailing platforms.
As the development goes because of the tight timeline, I tried to evaluate the approach to the users so we can mitigate the worst part better and to define what to do next faster so we can deliver it faster as well.
In this case, I used:
Evaluative usability testing
The task is: Migrate this (demo) website to Hostinger, and this is the key points that I focused on to get the behavior details of the tester:
How did the testers find the migration feature
What did the testers write in domain input step, ask expectation
What did the testers write in login information input step, ask expectation
What did the testers write in file upload directory input step, ask expectation
Ask about warning step key point
How did the testers insert the new website destination, ask expectation
As Figma has a new policy regarding to their sharing policy, I can't give any access to try this interactive prototype. But, to demonstrate how the final design solution, I attached the video recording of the prototype.
As this project is only just-for-fun, I didn't really do any testing for this design.
Interested to talk further?
Feel free to getting in touch with me by hitting the button right there
.png)
.jpg)
.png)
.png)
.png)
.png)
