My Alumnus

1. 01.

   There is nothing to check against.

   Alumni hand back their only ID at graduation, and the admin cannot reach alumni data. The register has no authentication, no search and no audit trail.

2. 02.

   The time goes to the phone chain.

   A doubt at the gate becomes a string of calls, and the visitor pays for it: up to 30 minutes in one account.

3. 03.

   Approvals depend on people who may not answer.

   Genuine visitors are turned away because the one person who could vouch for them did not pick up.

4. 04.

   The guard is accountable for a decision he has no information to make.

   This one surfaced late in the research and shaped the whole guard console.

Six methods, at one campus, to see how the gate works today and why it fails.

• Interviews

  Four one-on-one: three alumni and one main-gate guard.

• Contextual inquiry

  Two field visits: the security gate and the administration office.

• Experience audit

  21 touchpoints across alumnus, guard and admin, each scored on five criteria.

• Secondary research

  Gate-security practice, the DPDP Act 2023 and UGC safety guidelines.

• Artifact analysis

  A teardown of MyGate, Envoy and Raptor: the guard screen and the visitor credential.

• Gap analysis

  Needs mapped against four existing products.

1. 01.

   Recognition lives in people, not records.

   When the guards change, the campus forgets its alumni.

2. 02.

   Graduation takes away the only proof.

   The one credential that shows you belong is returned the day you graduate.

3. 03.

   Every doubt becomes a chain of phone calls.

   Access depends on who picks up, not on who the visitor is.

4. 04.

   Records are written but never read.

   The process captures data and has no memory.

5. 05.

   Knowing in advance makes the check disappear.

   When the gate already knows who is coming, verification becomes opening the gate.

• Silent approvers

  Detail

  No product defines what happens when the approver does not respond. A time limit with a fallback is undocumented across every product studied.

• Record to decision

  Detail

  No product joins the alumni record to the gate decision. Alumni-ID tools have the record but no guard console; visitor tools have the console but no alumni record.

• The empty-handed walk-in

  Detail

  No product verifies a visitor who carries nothing. Every option needs an ID scan, an app credential or someone to vouch in real time.

• About 420 tokens

  What it does

  In three tiers: primitives, semantic roles and component tokens, each with a light and a dark value.

• A contrast gate in the build

  What it does

  The build fails if any of 81 listed text and background pairs drops below its minimum in either theme.

• 0 automated violations

  What it does

  axe-core across all 50 mockup pages, in light, dark and forced colours.

• Mockups to app

  What it does

  The same token and component files style the mockups, the prototype and the live app.

• Heuristic evaluation

  Who

  One expert evaluator

  What it found

  22 findings: 4 major, 11 minor, 7 cosmetic

• Cognitive walkthrough

  Who

  Expert, as the guard and admin personas

  What it found

  13 tasks: 8 clean, 5 with a failure story

• Simulation

  Who

  A script on the real guard console

  What it found

  A queue of 12 visitors: holds 4 to 1

• Think-aloud

  Who

  One working security guard, live app

  What it found

  4 of 5 tasks completed; 1 approval silently not saved

Waiting comes from holds, not from taps. Routine entries took 5 to 16 seconds of guard time, and every long wait in the simulation was a hold of up to 10 minutes.

• Visitors held at the gate

  Before

  4

  After the fixes

  1

• Mean time at the gate

  Before

  3 min 43 s

  After the fixes

  1 min 12 s

• Longest time at the gate

  Before

  11 min 30 s

  After the fixes

  10 min 25 s

• Guard's own time, all visitors

  Before

  4 min 12 s

  After the fixes

  3 min 53 s

• One evaluator, who also built the app, ran the heuristic evaluation and the walkthrough.
• Three of the four methods are expert or model based. Only one think-aloud session, with one working guard, observed a real user.
• No admin was observed using the admin console, and there has been no pilot at a real university. The demo runs on fictional data that resets nightly.
• Baselines come from four interviews and two field visits at one campus. They are accounts, not timings.