Scattered graduation shows, in one index
FLATTEN
Summary
I designed the data model before the screens. A relational model links person, project, programme, institution and year, and the success measure and the operations tool were both settled before the build. It has not launched publicly.
- 52,214
- 786
- 20
Overview
This is a content product whose data model and operating structure were designed from the start. Graduation shows come first: they are public, happen every year, have fixed dates and venues, and students want them seen.
Problem
University project records scatter across school sites, show sites that last a year, Instagram, Behance and PDFs – and on the way, who made what, in which programme, where and when is lost. Collecting links doesn't bring that relation back. Recovering it needs a structure that stores the relation in the first place.
Key decisions
Build the person–project–programme–institution–year model first
What separates a link collection from a record is the schema, not the screen. To widen later into works and people, those relations have to be in the tables from day one.
Twenty tables link the five axes. A show is only the model's first use: school pages, department pages and year listings all derive from the same relations.
Separate the ongoing programme from each year's show
Linking years is the one structural advantage over the scattered records. Kept in one table, this year's show overwrites last year's.
A department's graduation show (programme) and that year's show (edition) are separate, so school pages build up year by year. Joint shows link many-to-many.
No posters by default
A poster is someone's work in its own right. Filling the index faster with other people's graphics would break the thing the product says it protects.
Posters without cleared rights are blocked from rendering; a typographic, neutral metadata card shows instead. The card works on school, department, dates and venue alone.
Fix the success measure before building
So the numbers can't be reinterpreted after the fact.
The key measure was defined first, as a design value: the share of sessions that view at least two different schools. Moving between departments of one school doesn't count, because crossing the school boundary is the reason the product exists.
The real first product is the operations tool
The human time it takes to verify and post one show sets the service's limit. Building the public screens first leaves screens with no way to fill them.
An admin tool came first: a candidate queue where date, venue and cancellation must be checked by a person before anything is published.
Two smaller decisions
Designed for zero added cost. An unvalidated product mustn't close because of its bills. Events are batched and rolled up nightly so the dashboard never scans raw events, and no paid products are used. ₩0 is a design value; the operating figure arrives after launch.
A zoomable poster wall. Hundreds of shows should be scannable at once without getting slow. It draws at most 900 tiles (a design value) and drops detail as you zoom out, loading images only up close.
Process
Data
- Source – the 2023 department list from the national university information portal, 52,214 rows.
- Design department master – 786 departments at 217 institutions, pulled out of those 52,214 rows. A department's name alone doesn't say whether it's a design department, so it was checked institution by institution. Ninety departments are prioritised for the first wave (a design value).
- Structure – 20 tables, built to link people, projects, programmes, institutions and years. An edition hangs off a programme, a programme off a department, a department off an institution.
Build
- The operations tool came first – the admin queue was built before the public screens. Collected candidates publish only after a person checks date, venue and cancellation.
- The metadata card is the default form – designed in type alone so it stands without a poster. A cleared poster sits on top of it.
- Cost was held down structurally – events are batched and rolled up nightly, and the dashboard reads only the rollup tables.
Reflection
It hasn't launched. Nothing has been validated by use. What follows is what held while building, and what is still open.
What held up
- Deciding the relations before the screens. School pages, department pages and year listings became cross-sections of one model rather than separate screens, so widening into works and people won't need a new schema.
- Separating programme from edition. Linking years is the product's only structural advantage, so that split is the product's reason to exist.
- Making the admin tool the first product. The judgement that human verification time is the ceiling on coverage still holds.
What failed
- I planned to use posters as the index's default image. A poster is someone's work, and rights couldn't be cleared at scale, so the neutral metadata card was rebuilt as the default form.
- I assumed one public dataset would produce the master list. Department names alone didn't isolate design departments; 217 institutions were checked separately and the first wave narrowed to 90.
- No judgement has been contradicted by use yet. Everything that changed so far changed during building.
What I would test next
- Whether the key measure moves – the share of sessions viewing two or more different schools. The first season's measured value decides whether this continues.
- The real processing time of the admin tool – how many minutes a person spends verifying and posting one show is unmeasured, and that number is the ceiling on coverage.
- Whether a card without a poster gets clicked – it's unknown whether the neutral metadata card holds attention on its own.
- The next axis – whether to widen from graduation shows to works, people, capstones and collaborations depends on the first season's validation.