On this page
Overview
This was not another fictional case study. It was a small problem I experienced personally, and a chance to explore how far a product designer can take an idea beyond the screen.
The result is Interview Learning: a place to prepare for each interview stage, keep what you want to say in one place, and learn from how each one ended. It is an experimental concept rather than a public launch, but it is live and working.
The starting point
I prepared, but not in the right way. During my job search, I realised that preparation is not only about researching a company or practising answers. It is also about:
- Knowing what to prove
- Choosing the right examples
- Asking better questions
- Learning from each interview
- Carrying those lessons forward
But interview preparation was scattered across notes, tabs, documents, and memory.
The opportunity
Every interview is different. Different role, different company, different interviewer, different expectations.
So preparation should not be one long list of notes. The product needed to help users prepare for the current stage, while keeping previous learning available as context.
My experiment: no Figma
I wanted to test a different workflow, starting with the problem rather than with polished screens.
Instead of creating polished screens first, I started with:
- Quick brainstorming
- User stories
- Core journeys
- Product and technical planning
- A small working MVP
Code became the place where I designed, tested, and refined the experience.
The core journey
One calm flow from opportunity to learning.
Add an interview opportunity
The role, the company, the date, the stage, and the job description in one place.
Prepare for the current stage
A working space for the round in front of you, not for every round at once.
Record what happened
The outcome captured while it is still fresh, in a few taps.
Carry learning into the next step
What you learned stays available the next time a similar conversation comes around.
Create an interview journey
Users can add the role, company, date, stage, and job description. The job description is not just stored. It can help surface focused Role Highlights for preparation.
Design focus: reduce the blank-page feeling and make the first action clear.
See progress without searching
The Dashboard brings active opportunities, past interviews, progress, and next actions into one place.
The goal was not to show more data. It was to help users quickly answer one question: what am I preparing for next?
Prepare one stage at a time
A recruiter screen and a final interview do not need the same preparation. Each stage gets its own working space for:
- What I need to prove
- Key examples
- Questions to ask
- Reminders
- Interviewer research
- Job-description highlights
Earlier preparation stays available as read-only context, without mixing into the current stage.
Turn the job description into focus areas
A job description can contain a lot of information. Instead of showing every keyword, the product identifies a small number of focused Role Highlights to guide preparation.
The experience also accounts for the real states of an AI feature: analysing, ready, delayed, and refresh available.
Make reflection part of the flow
After an interview, users can quickly record what happened: moving to the next round, waiting for an update, not selected, or an offer received.
This keeps the product current and makes reflection feel like a natural part of the journey, not an extra task.
Keep preparation useful outside the app
Users can download their preparation as a clean PDF. It makes it easier to review notes before an interview, keep a personal copy, or look back at how preparation changed over time.
Designing beyond the screen
Building this in code made the invisible parts of product design visible:
- Empty states
- Loading and delayed states
- Error messages
- Authentication flows
- Data ownership
- Mobile responsiveness
- Keyboard and focus behaviour
- Performance, security, and privacy
A screen can look complete in a prototype. A product needs to work when real people, real data, and unexpected situations arrive.
The technical foundation
Chosen to support a real working experiment rather than a demo.
- Next.js: frontend experience and application logic
- Supabase: authentication, PostgreSQL database, and access control
- OpenAI: job-description analysis
- Docker-based local Supabase tooling: local development and database testing
- Vercel: deployment
- GitHub: version control and quality checks
Security and reliability were considered throughout, through authenticated routes, row-level access rules, protected environment variables, tests, and deployment checks.
What I learned
Product design does not end at the handoff. This experiment helped me understand how closely product thinking, design, AI, and engineering can work together.
The ability to design a screen is valuable. The ability to turn a problem into a working, thoughtful product is even more valuable.
Explore the experiment
This is an experimental concept, not a public product launch, but it is live as a working prototype. If you are exploring a similar product challenge, interested in the process, or want to discuss product design beyond traditional case studies, I would love to connect.