One shared view of day one.

Between a signed offer and the first day, the plan lives in several places. Talent Acquisition, People Ops, IT and the hiring manager each hold a piece of it. The new starter holds none. Gaps show up on the first morning, when it is too late to fix them quietly.

Lumi came out of my own years in HR, watching the gaps between the people responsible for a new starter's experience. It is now my capstone project for the Product Management with AI course at neuefische, and I am building it so that companies could one day use it.

• It started as an assumption. So I tested it before designing anything: surveys I built with Google Apps Script, and conversations with hiring managers from different industries, HR professionals and people who had recently started a job. They pointed to the same gap, between the offer and the first day. It didn't decide whether someone stayed or left. It did cause a lot of friction in the first 90 days, when a new starter is trying to feel part of the company.
• Deciding what Lumi is not. It measures the onboarding, not the person. Performance management stayed out. It also doesn't replace an HR system: in the prototype, documents and account setup still happen in Personio.
• The employee isn't the buyer, but their experience is the point. So new starters were part of the research from the beginning.
• A clickable mock-up wasn't enough. Screens that don't remember anything can't show a handover. The prototype had to keep its state from one screen to the next.

I worked in the order a product team would: discovery, a feature list, a user flow, wireframes in Figma, then a coded prototype built with Claude Code.

• Eleven screens, six roles. A "Viewing as" switch shows the same new hire as People Ops, Talent Acquisition, the hiring manager, IT, the new starter or HR leadership.
• One story that works end to end. A test login fails. People Ops flags a blocker. IT fixes it. People Ops tests again and marks the new starter ready for day one. Each step updates every other screen.
• Honest about the AI. The assistant in the prototype answers a short set of expected questions from simple rules. It is not a real AI model yet, and the page says so.

It runs on sample data at a fictional company. Every name in it is made up.

The day after the first build I went through it as each role and found what was missing. I added:

• A welcome page for the new starter, with a countdown and a first-day timeline.
• A documents checklist and a welcome email with a one-time sign-in link, so no password travels by email.
• Relocation tracking, step by step.
• Three short coffee chats in week four, each with a three-question survey.

The feature list grew from 12 to 16. I fixed six bugs and re-tested each one. One usability finding stays open on purpose: I want to see whether testers get stuck before I change it.

• Test it with real users. So far the only reviewer has been me. Next comes a usability test script and sessions with HR practitioners.
• Replace the rule-based assistant with a real AI model.