Jobcenter - One platform, three different audiences
App, website and admin portal for the hiring company, the candidate and the outsourced worker, with payslips and benefits read from the payroll system.
Three people, three relationships, one product
Jobcenter supplies temporary and outsourced labour. That puts three very different people around the same business, and each wants something different:
- The hiring company wants to post vacancies, follow requests and see its numbers. The candidate wants to find a job and apply. The worker already placed wants their payslip, benefits and income statement, and is heard through a satisfaction survey.
The product challenge was fitting all three into one app without turning it into three apps glued together, and without making the worker navigate screens that are not meant for them.
What each profile finds
Client. Vacancy posting with a complete form, including contract type, role, salary range, education, required experience, work location, working hours and attachments. Plus document submission, tracking of their own requests, and the dashboard with account indicators.
Worker. Payslip, benefits, income statement, document submission by photo taken on the spot, and the satisfaction survey.
Candidate. Access to open vacancies and CV registration.
One scope decision is worth recording: candidate CV registration was not rebuilt. Jobcenter already published its vacancies on an established job portal, and the app takes the candidate there instead of duplicating a CV database.
Recreating what already works elsewhere costs a lot and delivers little. Rebuilding only makes sense when the result is better for the person using it, and it was not.
The most important data was not Jobcenter's
Here is the architecture decision that defines this project.
Payslips, benefits and income statements did not live in a Jobcenter system. They lived in a third party payroll system. The product had two options: copy that data into its own database, or read it at the source.
The choice was to read at the source. Replicated payroll data is data that diverges: one calculation adjustment in the source system and the worker sees one figure in the app and another on the payslip, and there is no good fix for that after it happens.
The cost of that choice was the dependency. The product only shows a payslip when the source system exposes one, and the integration stayed pending for long months, waiting on the third party's data interface.
The pending item was logged and chased daily, in the project channel, until it was resolved. When the integration arrived, there was still a round of authentication fixes, because the token issued by the new route was not accepted by the payslip and benefits routes.
The lesson for similar projects: when the central information of the product sits with a third party, that dependency is the biggest schedule risk, and it has to be visible as such from day one, not treated as an integration detail.
Design validated screen by screen
The project had a long and well documented design phase, and it ran through the beginning of the pandemic, with the client's team moving to working from home in the middle of the validations.
What was delivered in that phase:
- Information architecture for the entire product. Navigable prototype of the app, validated with the client in successive rounds, with feedback screen by screen. Navigable prototype of the web version. Client profile dashboards designed from the indicator spreadsheet the client already used. Formal design handoff to development, recorded on video, so the intent behind each screen was captured beyond the file.
One experience decision came out of that phase: the satisfaction survey form began showing filling progress, precisely to reduce drop-off from people who see a long questionnaire and give up midway.
Stack and practices
- React Native for the iOS and Android app, with PDF document viewing for payslips. React on the website. Strapi as back end layer and admin portal. Relational database, with the production environment on the client's cloud infrastructure. Containers with an automated build and deploy pipeline to the staging environment. Integration with the third party payroll system for payslips, benefits and income statements. Adobe XD prototypes with preview links, validated before development.
The app was published on both stores, and X-Apps supported the client in setting up the publishing accounts and production infrastructure, which stayed in their name.
Does your product depend on data living in another system?
Almost every corporate product depends on a system that already exists and is not yours: payroll, ERP, CRM. The decision between replicating the data and reading it at the source defines the product's reliability and the schedule's risk. X-Apps helps make that decision with both costs on the table.