Flagship case · Project 01
Placement Operating System
A placement product only works when it distinguishes readiness, eligibility, preference and job-specific fit — then carries those decisions through an employer-specific hiring workflow.
Every product visual is labelled by provenance, so original work is never confused with a portfolio-created explanation.
A genuine working document, wireframe, screenshot or output that can be shown publicly.
A recreated product view grounded in the original work, using synthetic or anonymised information.
A simplified model created for this portfolio to explain system behaviour, workflow or product logic.
Problem underneath the request
The request sounded like a job board. The real problem was a multi-sided decision system.
Placement teams needed to know who was broadly ready, who met the rules for a specific opportunity, who actually wanted that opportunity, and who matched the job-specific evidence. At the same time, every employer could run a different hiring process while every student could be active in several applications. Treating all of that as one status or one score would have made the product brittle and hard to explain.
EdTech · Placement operations · Workflow platform · Matching systems
Can this student enter placement?
A configurable view of learning evidence and programme expectations.
Does this student meet this job’s rules?
Education, language, location and other job-specific constraints.
Does the student want this opportunity?
Role, location, salary and other personal choices remain independent.
How well does the evidence match the role?
Job-specific learning criteria and weighted achievement signals.
My role
I owned the operating logic that connected learning evidence to placement execution.
My scope covered product vision, roadmap, requirements and business-rule translation across job management, readiness, matching, applicant tracking, student-facing discovery, resume data and integrations. I worked across placement teams, campus roles, engineering and source learning systems to make the workflow executable rather than leaving it as organisational knowledge.
Product vision, roadmap and phased delivery
Readiness and matching logic
Configurable job and hiring-stage workflows
Student and job-centric applicant tracking
Resume, preferences and student job discovery
Learning-platform integrations and rollout coordination
Product system model
Two operating journeys meet at a decision layer — then continue through one auditable hiring process.
The student journey and the opportunity journey have different data, states and owners. The product joins them at matching and application rather than forcing either journey to become a copy of the other.
Original Product Artifact
The product model became a real operating surface.
The PMS wireframe set spans placement operations, job management, student opportunity discovery, applicant tracking, skills, preferences and resume workflows.
33 original 1920 × 1080 wireframes from the working Placement Management System design set.
The decisions that shaped the product
Not a feature list. The product changed when these decisions became explicit.
Each decision resolved a piece of operating ambiguity and created a concrete product implication for the system that followed.
- 01
Model each job as a configurable hiring workflow.
Hiring stages, duration, dependencies, responsible roles and assessment tools were configured per opportunity instead of forcing every employer into one global process.
- 02
Connect learning evidence directly to placement decisions.
Signals from learning platforms could contribute to readiness and job-specific shortlisting criteria instead of being copied manually into placement spreadsheets.
- 03
Keep readiness configurable.
Placement expectations change across schools, curricula and roles. Readiness therefore needed to evolve without hard-coded product changes.
- 04
Separate eligibility, preference, readiness and fit.
These dimensions were modelled independently instead of being hidden inside one opaque score.
- 05
Support both job-centric and student-centric tracking.
Placement teams needed to manage an opportunity pipeline while also understanding one student across several active applications.
- 06
Treat preferences and resume data as first-class product data.
Location, role and salary preferences informed matching, while structured resume data could be reused across the placement experience.
Artifacts and source evidence
The main evidence now sits beside the decisions it supports.
This chapter keeps the complete source material accessible without repeating large previews already shown in context.
Job Management Module · P001
Hiring-stage configuration, job-specific shortlisting criteria, validation rules and implementation use cases.
Complete PMS wireframe archive
33 full-resolution screens across jobs, applicant tracking, student experience, skills and placement operations.
JP_UC001 · Create and publish a job opportunity
The source specification carries the workflow into actors, triggers, preconditions, validation, success steps and exception handling.
Outcome and evidence
Observed outcomes
What changed in the operating system around the product.
Faster student shortlisting through automated readiness and matching signals.
Reduced spreadsheet and manual coordination across jobs, students and hiring stages.
Improved visibility into employer-specific hiring pipelines.
Made readiness assessment more consistent and explainable.
Gave students direct visibility into jobs, applications, preferences and resume completion.
Improved coordination across placement teams, campus roles and students.
Fully deployed production product with observed operational improvements. No unsupported quantitative impact claims are presented.
What the work changed in how I think
The product shipped. The operating lessons travelled further.
Readiness is not eligibility.
A person can be broadly ready for placement and still fail the rules of one specific opportunity.
Explainability improves operations.
Matching becomes more useful when teams can see which dimension blocked or supported a decision.
Operational knowledge must become product logic.
Criteria, states, exceptions and ownership have to be explicit before engineering can implement them consistently.
Configurability is a durability decision.
Workflow products become brittle when every policy or employer variation requires code changes.