WorkMarket Worker Native Mobile App
The native mobile app is for freelancers searching for work, setting up their tax and banking information, performing work, and getting paid.
Case Study, Onboarding
New onboarding design. It previously got a 33% conversion rate with a series of screens with wordy coachmarks. When we launched the full onboarding with a 4-step information process with nice big type in short sentences that proposed things that would directly benefit the user and bold clear CTA’s, conversion rates went up to 66%.
Previous onboarding for the app had a 33% conversation rate. It was an endless series of grayed out app screens with copy-heavy coachmarks. There were many problems with it aside from that as well. Account creation wasn’t enabled, users were unable to give us information to allow us to help them find work and they couldn’t access or edit their profile information. We sought to add these requirements and update the UI, lessen the amount of copy and shorten the process with the aspects of the app that attracted freelancers the most. With research, we found that finding available work and getting paid quickly were top of mind so we made it easier for them to get their profile filled out to get and set up their payment information right off the bat.
I designed various versions of onboarding and did research, putting them in front of users and non-users, unfamiliar with the app. We wanted to see if non-users understood the value proposition of the app (90% of downloaded apps are used only once) and how quickly users navigated through the process. We narrowed it down to this design with these screens for MVP. When we launched the new onboarding with a 4-step information process with nice big type in short sentences that proposed things that would directly benefit the user and bold clear CTA’s, conversion rates went up to 66%. KPIs were also account creation total vs the desktop platform, amount of time to first job.
Mobile App Redesign
User profile. Having the ability to add title, address and skills were critical to a good mobile profile experience, goals were to increase platform engagement, promote the employer/worker relationship by allowing workers skills and assets to stand out easily to employers. Also changed the nav to be clearer for users.
User’s funds screen. The goals for this redesign were to make it easier to read in a list format rather than a horizontal format, which felt awkward, make the hierarchy and desired action clearer, make a bolder CTA that was easier to reach with your thumb as well.
Assignment details screen. Users are on usually on the go, they’re driving, they’re often at other jobs while they’re browsing work. The details hierarchy needs to be easier to extract from the assignment details than they currently are.
When redesigning key screens such as profile, account balance and the welcome screen, we stripped a lot of unnecessary copy, gave it clearer type hierarchy and made important CTAs bigger and brighter. Users are on the go, they’re driving, they’re often at other jobs while they’re browsing work-they need to be able to scan information easily. With these UI improvements, app store ratings and reviews improved.
Since it was all feature parity, research was not done, but intensive user testing was conducted. Tasks were tracked, plotted out on a spreadsheet, individual task success were rated, good and bad feedback recorded and design recommendations based on the testing sessions were synthesized and presented to the team. This is the practice that I conduct all of my user research and testing with, it helps get the scrum team on the same page.
Additionally, we added more delight with a new loading state. The above demonstrates that deliverables for engineers can be static files as well as gifs for pacing and interaction.
Case Study, Home Screen
Users had to navigate multiple tabs to browse and complete work and get paid. Some of the most viewed parts of the app were assigned jobs, invoices, available and overdue payments, FastFunds, bullhorn notifications and available work. What we needed was a central jumping off point to help them access these things quickly. We also needed to help them find relevant work faster, so encouraging them to fill out their profiles, follow companies and set up their banking and tax information needed to go here too. We needed a home screen, but with all the options, what do we put front and center?
With in-depth interviews and card sort sessions with freelancers, we ranked the most important things for users to access immediately in the app. The top ranked items were viewing their job invites, assignment statuses, new messages, browsing available work, viewing their week ahead, their FastFunds and available funds to withdraw. With the exception of their week ahead, all of these things were incorporated on the home screen MVP.
Adding Tax and Banking Info
Allowing users to upload their tax and banking information via the app was key to completing the journey for the user without having to rely on the desktop experience. What we needed to keep in mind was not only the user’s security but their perceived sense of security. We wanted users to feel that they could trust us with their sensitive information. I tested variations of the design with users and non-users of the platform and conducted in-depth interviews. All users felt secure uploading such sensitive information because the desire to get quickly in the app outweighed any security fears, additionally, they also found the lock icon insured security, even though it’s just an (tiny) icon.
Mobile App Personas
Most personas for the mobile app are independent contractors. The majority of them are self-employed freelancers such as journalists and IT specialists. A segment of them work for agencies like brand representatives and translators. The other chunk of personas using the app are what are known as "team agents" or third party managers of teams of independent contractors that dispatch work.
Roadmap Planning and Strategy
The Product Manager and I conducted research, concept validation and user testing with prototypes. Afterwards, I would present the findings of the research to the scrum and product teams with user pain point assessments and design recommendations.
If the feature was greenfield and an MVP needed to be figured out, affinity mapping sessions and card sorts were conducted with team members and users respectively after research. Bubbling up of themes and patterns would dictate the priorities of the feature.
If it was a large enough feature that releases had to be planned months in advance, a user prioritization matrix was created in conjunction with the PM combining priority, urgency and feasibility feedback from the engineers.