SecondOffice: A case study
Problem Statement
Alex is an entrepreneur in the USA who has a vision of developing an iOS app for its ongoing project. He wants to hire a team from India as they are affordable and talented. He does not want to hire them as a freelancer or on a contract basis. He wants to hire them as his employees and establish an office in India. However, the problem is Alex does not want to spend too much time in the legal processes of different countries to establish an office; he also does not want to spend his HR’s time hiring people from India due to the time-zone gap. He also has trust issues; suppose he hires an employee in India, and they stop responding after a few days.
The key problem we identified in our case was
Problem 1: Trust
Trust plays an important factor here; Alex is not going to hand over money to unknown players in the market to hire for him. Alex is cautious in nature and will need constant feedback from 3rd party hiring authorities. Alex will need a well-known player in the market with enough public information around them to trust 3rd-party hiring companies.
Problem 2: Liability of hiring
Alex does not want to go into the legal obligation to open an office in India because this requires tremendous time and money.
Even after hiring, there is a possibility of employees not responding to him for his tasks, so management in India is also a challenge for him.
Problem 3: Resources
Alex doesn’t possess enough resources to spare for hiring in India. He does not want to employ his own HRs for the same task. This is a challenge for Alex to implement resources for hiring in India.
Understanding the business
Our business model differs from the various perspectives of giving projects and hiring.
In SecondOffice, the client hires an employee and assigns the project to the employee. These are not freelance gigs but employee-employer relationships. These employees are long-term assets to our users, which are affordable and talented.
SecondOffice itself says: Instantly pop up a physical office across the planet, and recruit top global talent as employees, not freelancers.
Understanding the user
We need to understand who will be our users and our audience. Finding a proper user is easy, but defining who is not our user is challenging.
Our primary audience is based on these factors.
- Age
- Occupation
- Location
Understanding our user
Persona insights
Problems
Currency difference: Our user is tensed with the constant change in currency.
Keeping in the loop with the hiring process: Our user is frustrated with the lack of communication from HR, which is a byproduct of time-zone differences, high cost of communication, and pinging for every update.
Hypothetical solution
We concluded currency change would be a major factor, so we hypothesized making a default currency for the same. Once selected, all currencies on the platform will be changed to the user’s default currency.
For the second frustration, we concluded by making a table that will show the progress of each candidate.
Information Architecture
Usability Testing
Usability testing determines whether testers can complete tasks successfully and independently.
In usability testing, we provided testers with basic tasks and observed their behavior for the same.
The first task given to the user was to post a job on SecondOffice.
Insights from User Testing
We took the overall insights from our major stakeholders, our client, and HR. These are the people who will be using our platform.
Get McKinley Rice Blogs’s stories in your inbox
Join Medium for free to get updates from this writer.
We observed the following insights in our remote User Testing.
- We observed our user extra time during the testing to calculate the currency conversion. We deduced this as a feature to be implemented in our platform.
- We also found out that the terms “CTC” and “ECTC” made very little sense to users specifically belonging to a demographic other than India.
- Standardization of Currency, We found that currency jargon differed from country to country; for India, the standard payroll is talked in salary * Lacs per annum, while for the US, it was salary * $10k per annum.
- Daphene also pointed out that their company follows a different hiring procedure for different profiles, and thus she would like some freedom over the hiring process.
Solution
- We implemented a feature in the settings page to directly convert the currency to your preference without other implications.
- This saved users extra time and effort they needed to make for converting values.
Before User Testing
After User Testing
3. CTC and ECTC are industry jargon used in India and are mostly understood by everyone. However, this was not the case in other countries. So, we implemented an information icon that helped the user with identifying what these jargons meant.
Implemented Demonstration
While hovering over the Information icon, the user gets the definition of the term.
4. Standardization of currency in salary was another issue that was pointed out during user testing.
Before Testing
From the insights, we found out that the salary chips provided, as shown above, were not helping users since they were not standard in their currency.
A 0–3 LPA chip is okay for India, but when converted, it will become 0–3.7K in USD, which is terrible in nature as the standard in the US should be 0–10K. Hence we made the following changes.
After User Testing
We made them an input field which solved our problem of standardizing the salary fields.
Task 2: For the second task, we asked users to make a performance evaluation of their employees.
Users were presented with screens, and we observed the path they followed and made the following observations.
- Performance evaluation differs from organization to organization; some organizations do evaluations based on weekly, bi-weekly, monthly, or quarterly.
- Organizations may also do employee evaluation which is done one-on-one. This is separate from the team evaluation. In this case, the evaluation of a single employee is done on a fixed-time basis.
Before Testing
In this design, we used to evaluate the employee directly; there was no filtration of dates in this case which became a challenge in checking the evaluation of the employee on any particular date.
After Testing
After implementing the new design, we are sorting them by dates, thereby sorting each employee’s evaluation. By doing this, it does not matter when evaluation is taking place; we can always filter out a particular employee by just going on that particular date.
Insights from User Test
We also concluded that users need a prior explanation of the platform for a better understanding of the workflow.
Users were also jumping to hiring rather than filling out the company information; this could become a problem for the credibility of the company’s image.
Solution
We made one-time onboarding overlays which helped users understand the platform’s basic information architecture.
Before Testing
After Testing
We concluded that users need to be prompted to complete their profile before they can proceed with posting a job, SO we made a progress bar that will help users to navigate to complete their profile.
Hypothesis demonstration
With the completion of each step, the user is prompted to the next step.
Conclusion
This is an MVP project and just the beginning of the model.
For the future, we have decided to implement many features based on the user’s feedback. We are also going to implement a store page which will help our client to get the physical assets required by their employees.
In conclusion, this project is just the beginning. Many major changes will be taking place in the future.
Written by: Kaushal Batra, UI/UX Designer.
