Product Ideation · Vijaybhoomi University
Visitors to our campus often wait at the gate for a long time. They are waiting for someone to approve their visit. I studied why this happens, designed a fix, tested it with eight people, and rebuilt it.
Summary
Phase 1 · The current system
Every visitor fills in a six-screen form made by an outside company. They fill it in at the gate. Then they wait for someone inside the university to approve it. After that, a pass arrives on WhatsApp.
Four things make this hard:
The six screens below belong to the current system. I captured them as evidence. My own design is in Phase 4.
Phase 1 · Method
| Code | Who | What I did |
|---|---|---|
| P1 | Visiting parent | Recorded her story, then sent written questions |
| P2, P3 | Two gate guards, on different shifts | Interviewed each one alone, in Hindi, about 10 minutes each |
| R2–R9 | 6 students, 1 past visitor, 1 other | Online card sort with 20 cards |
| TT1–TT5 | 5 students who did not do the card sort | Paper tree test with 8 tasks |
I use these codes only here and under the evidence photos. The two guards gave almost the same answers. So the problem happens every day, on every shift.
Phase 1 · Persona
Before the research, I wrote a proto-persona: my guesses about a visiting parent. The research proved all four guesses wrong.
| My guess | What the research showed |
|---|---|
| She finds apps hard to use | She filled in six screens correctly, twice, in a moving car |
| The long form upsets her most | She accepted the form. The waiting after it upset her most |
| She waits about 20 minutes | She waited over an hour, applied twice, and had one request cancelled |
| She wants to get in fast | She wants to know for sure she will get in. Being turned away costs her a six-hour round trip |
Homemaker, 40 to 50 · three-hour drive each way · visits often · comes on Fridays at lunch, when her son is free
She had four advantages most visitors do not have. She knew about the form. Her son sent her the QR code from the gate. She started an hour early. And her son was on campus to help. She still waited over an hour.
I was thinking whether I would be allowed inside or not that day.
The number on the right is how she felt, from +5 (great) to −5 (terrible). The times count from when she reached the gate.
Phase 1 · Empathy map and journey map
I built both maps in FigJam from her recorded story and the guard interviews. Every quote on them is in her own words. Tap a map to open it full size.
The approval step has no one in charge, no time limit and no backup plan. If the approver does not answer, the visitor just waits.
A shorter form lifts only step 2 on her journey, from −1 to 0. Her worst moment, at the gate, stays at −5. That moment comes from the approval step.
Three sources agree. Even the guards do not know who approves:
Very difficult to figure out whom to ask approval for, especially when a parent is visiting.
“Who should I ask approval from?” is one of the three questions visitors ask us most.
If they lift up the call, all well and good. If not, the guests just keep waiting.
Phase 1 · User stories
Phase 2 · Information architecture · Card sort
I made 20 cards, one for each thing the system can do. Nine people sorted them online into six groups. They were also free to say a card fit no group, or make up a new group. Eight results were usable. Three things stood out.
All eight people put “see if my request has been opened” and “see how long a decision takes” in the same group. People clearly want one place to check their request. The current system has no such place.
Half the group (4 of 8) said “pass the request to a backup person after a set time” fit no group. They had never used a system that does this. Still, one person came up with the same idea on their own:
Time to respond. After which the visitor can seek help.
“Add another visitor to the same request” won 5 of 8 votes. But three people also said it was the hardest card to place. The numbers made it look settled, and it was not.
Visitors and students disagree. The parent wants the form to ask for less. One student wanted more, like a visitor photo and a car number. The visitor gives up the private data and gets nothing back for it. So I followed the gate register and kept five fields.
My form had no “not sure” choice. One person told me so. They were right. Some people picked “fits no group” when they meant “I do not know”. The tree test helped me tell those two apart.
Phase 2 · Information architecture · Tree test
I turned the card sort into a menu with six sections. Then five new students tested it on paper. I read them a situation, like “It’s been an hour and nobody has answered your request.” They pointed at the menu heading that they chose. They saw one level at a time, with no design or search to help them.
A filled dot means the person’s first choice was right. I set the pass marks before testing: 4–5 is good, 2–3 is unclear, 0–1 means the menu is wrong.
| What happened | What it tells me | Change |
|---|---|---|
| I guessed that the backup task fails. It passed, 4 of 5. | People knew where it belonged once they had a real reason to look for it. | None |
| Nobody found visiting hours. It took 75 seconds on average. Four of five said that they wanted to call the gate desk. | People ask a person about hours. The heading also mixed hours with gate location. | Split hours and location |
| “For Hosts” failed, 1 of 5. Four went straight to “Apply for a Visit”. | Students do not call themselves “hosts”. They think “I am arranging a visit.” | Removed “For Hosts” |
| “Add a visitor” went the other way. The card sort said Apply. Three testers chose Checking. | On a card, it sounded like filling in the form. In the test, the request was already sent, so it meant changing it. | Moved to Checking |
I filled in one sheet per person during each session. Each sheet shows their first choice, path, time and words for every task. Tap a sheet to open it full size.
The sheets say P1 to P5. On this page they are testers 1 to 5, so they do not get mixed up with the parent and the guards.
CAMPUS VISITOR ACCESS (after testing)
├── Request a Visit renamed from Apply for a Visit
│ └── includes: request a visit for my guest moved in
├── Checking on My Request
│ ├── status, who has it, backup approver
│ ├── add another visitor moved in
│ └── guests expected today moved in
├── Getting In and Out
│ └── gate location split out
├── My Information and Privacy
└── Getting Help
└── visiting hours split out
REMOVED: For Hosts
“Checking on My Request” now has eight items. I thought that was possibly too many, but the tree test gave me no reason to split it. So I wrote it down as the first thing to test next. The usability test later showed that it was too many: only 1 of 8 people found “add a visitor” there.
CAMPUS VISITOR ACCESS (first version, from the card sort) ├── Apply for a Visit name, phone, reason, who 6/8 · add visitor 5/8 · hours 3/8 ├── Checking on My Request opened 8/8 · who has it 7/8 · backup fit no group ├── Getting In and Out entry pass 8/8 · exit pass 8/8 ├── My Information and Privacy ID proof 7/8 · privacy 6/8 ├── Getting Help gate desk 7/8 · no signal 8/8 └── For Hosts guest request, guests today my own label
| Task | First choice right | No going back | Middle time | Went to instead |
|---|---|---|---|---|
| Request status | 5/5 | 4/5 | 15s | none |
| Privacy | 5/5 | 5/5 | 10s | none |
| No signal | 5/5 | 5/5 | 20s | none |
| Who I am visiting | 4/5 | 3/5 | 20s | Checking ×1 |
| Backup approver | 4/5 | 4/5 | 32s | Help ×1 |
| Second visitor | 2/5 | 2/5 | 20s | Checking ×3 |
| Student registers | 1/5 | 4/5 | 40s | Apply ×4 |
| Visiting hours | 0/5 | 1/5 | 75s | Help ×2, In and out ×2, Checking ×1 |
Four people went straight to the wrong place for “student registers a guest”, with no going back. They were sure, and they were wrong. I also marked every task as “reached” on the sheets, even when the path shows the person never got there. So I used first choices and paths, not the “reached” column.
Phase 3 · Prioritization (MoSCoW)
I listed 27 ideas: 21 from the menu and 6 that people suggested. I grouped them into features, then sorted them into Must, Should, Could and Won’t. The first version had room for only four must-haves.
Student registers a guest · digital entry pass · alert when decided · remind the approver · add a visitor · gate desk number · pass that works offline
Reuse last visit · visiting hours · gate directions · exit pass · guests expected today · usual decision time · time slots · privacy notice
Two features competed for the last spot. I scored each from 1 to 5 on three things: Desirability (do people want it), Feasibility (can we build it) and Viability (will the university accept it). I wrote down what each score meant before I scored.
| Score, 1–5 | Backup approver after a time limit | Student registers a guest |
|---|---|---|
| Desirability | 5 | 3 |
| Feasibility | 4 | 2 |
| Viability | 4 | 2 |
| Total | 13 | 7 |
Desirability: four sources point to the backup approver, and one card-sort person asked for it on their own. The student option mainly helps visitors start early, and the web link already does that.
Feasibility: the backup approver is a timer and a rule. The student option needs student logins, a new user type and a link to the student records.
Viability: guards already phone backup people by hand. The backup approver just does that for them. The student option goes against the university’s choice to keep approval with a few staff.
| Score | Desirability | Feasibility | Viability |
|---|---|---|---|
| 1 | Only my own guess | New systems and outside links | Undoes a university decision |
| 2 | Guessed from one source | New user type, login or outside link | Needs a new rule and adds risk |
| 3 | One person asked for it | Some changes to what exists | Needs a rule, low risk |
| 4 | Several separate sources | A rule or timer on existing data | Writes down something people already do |
| 5 | Several sources, someone invented it, and it fixes the worst moment | Only settings | Saves money, no new rules |
Phase 4 · Design
I drew the screens as gray wireframes. Then I checked them against Nielsen’s heuristics and fixed what failed. Last, I linked them into a prototype you can click.
There are sixteen phone screens. Eight show the main path from home to approval. Five show errors and problems. Three are information pages. Here are five of them.
Scroll sideways to see all five. Open all sixteen screens as one image.
I checked my first sketches against Nielsen’s ten usability heuristics. Three failed. Each failure brought back a problem from the research.
SketchThe status said only “Pending approval”. It did not say if anyone had opened it, who had it, or how long was left.
WireframeIt shows three named stages, who has the request, and how many minutes until it moves on. A “last updated” time shows when the screen is out of date.
SketchOnce you started the form, the only button was Continue. There was no way to go back or leave.
WireframeEvery screen has Back. Each form step has “Cancel and return home”. A pop-up tells you your details stay saved if you leave.
SketchStep 2 asked you to type the approver’s name. That is the same mistake that left the parent waiting.
WireframeIt asks who you are visiting. There is a review screen before you send. If a name is not found, the screen explains why and gives other ways to search.
This is the Figma prototype that eight people tested in September. Tap the buttons to move between screens. If you tap a spot that does nothing, Figma briefly shows the spots you can tap. The rebuilt version is in the demo.
If the prototype does not load, open it in Figma.
Request a Visit → About you → Your visit → Review → Sending → Waiting → Refresh → Moved to backup → Refresh → Approved.
| Must-have | Screens |
|---|---|
| Send from anywhere, five fields | Home, the two form steps, review |
| The system picks the approver | “Who are you visiting”, name not found |
| Visitors can see the status | Waiting, no signal |
| Backup approver after a time limit | Waiting countdown, moved to backup, approved |
Phase 5 · Usability testing
Eight people tested the Figma prototype on 16 and 17 September 2026. Each person worked alone, from a Google Form. The form gave them eight tasks, like “nobody has replied to your request”. After each task, it asked if they managed it, how easy it was, and what the screen told them.
Two people were a parent or relative of a student. Four were students. One was a working professional and one chose “Other”. Five used a phone and three used a laptop.
I checked each answer against what the screen really shows. Most people said they managed the task, but less than half understood the screen. In a test with no observer, “I managed it” measures confidence, not understanding. So every result below comes from the answers and the comments, not from what people said they managed.
A filled dot means the person’s answer matched what the screen shows. Rows with fewer than half are marked in red.
Four problems stood out.
Five of eight people thought the waiting screen meant that they had permission to enter. The screen said “Waiting for a decision”. But it also said the request “moves to a backup approver at 13:59”, and people read that time as a promise. This is the worst result, because the whole design exists to stop false confidence at the gate. Both approvers were also named only “Administration”, so people did not know which was which.
Shows my reference number and that im allowed to enter.
Only 1 of 8 went to “Checking on My Request”, where this task lives. Six went to “Request a Visit” and were about to make a second request. The tree test said the opposite: 3 of 5 chose Checking. The tree test showed only the heading. The usability test showed the heading with a subtitle that sounded read-only. A tree test measures whether a label fits, not whether people see what they can do there.
Nothing on the menu mentions adding a person or group visitors.
When nobody replied, two people chose to call someone. One chose to cancel and apply again, which is the habit that the current system teaches. No status or error screen had a gate desk number. The backup approver is a good idea, but people still want a person to call.
Would like a call or help option on this screen in case the backup is also slow.
“Cancel and return home” sounded like it deletes your details. The pop-up then said the details stay saved. The “name not found” screen showed a professor’s name to a parent who was looking for their child.
Yes seems very reliable regardless of you losing connection.
These faults came from how I built the Figma file, not from the design. They cost people some tasks.
The ease rating for each task was 6 or 7 out of 7, even for the task that only one person got right. So I do not use the ease ratings as evidence.
The System Usability Scale (SUS, a standard 10-question score out of 100) had a mean of 76.9 and a median of 81.3. The usual benchmark is 68. But with eight people and scores from 32.5 to 100, the number tells me very little.
| Person | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|---|---|---|---|---|---|---|---|---|
| SUS | 87.5 | 70.0 | 32.5 | 90.0 | 62.5 | 97.5 | 75.0 | 100.0 |
Phase 6 · Redesign
I rebuilt the app as a working web page, not a set of linked pictures. Each change below answers one problem from the test. On the left is the wireframe that people tested. On the right is the new version. Tap an image to open it full size.
| Problem in the test | Change | Evidence |
|---|---|---|
| A sent request looked approved | Start with “Not approved yet. Do not enter until this says Approved.” | 5 of 8 |
| Nobody found how to add a visitor | “Add a visitor” button on the status screen | 1 of 8 found it |
| People wanted a phone number | “Call gate desk” on every status screen and on the pass | 3 of 8, and two direct requests |
| First and backup approver looked the same | Desk 1 and Desk 2 | 1 person |
| “Cancel” sounded like delete | “Finish later” | 1 person |
| A professor’s name on the parent’s error screen | “Staff no longer approve visits. Name the student you are seeing.” | 1 person |
The new version has the four must-haves. It also has four should-haves that the test gave evidence for: add a visitor, a gate desk number, a digital pass, and a pass that works with no signal. It has nothing from the could-have or won’t-have lists.
Phase 6 · Demo
This is the working version. It runs in your browser and sends nothing anywhere. Its clock runs fast: one minute passes about every half second.
If the demo does not fit your screen, open it in its own tab.
I have not tested this version with users yet. The next test starts here.
Phase 7 · Peer benchmarking
Three classmates studied other campus systems. We shared our written studies and compared them. I did not use a live demo, because a written study shows the evidence behind each choice.
All four of us found the same problem on our own: after you send a request, nothing tells you what happens next. In one classmate’s survey, 67% of people had waited for an approval with no status. But we chose four different answers.
| Study | Answer to the waiting | It needs |
|---|---|---|
| Office request tracking | Predict: show the expected date the request is done | Staff who work at a steady speed |
| Complaints | Name the owner: show which department has the complaint | Rules that send each complaint to an owner |
| Classroom booking | Show it early: show free rooms before you ask | A timetable that already exists |
| Visitor access (mine) | Act: move the request to a backup on a timer | A rule and a clock |
Only my answer still works if staff do nothing. The other three tell the user about a stuck request, but they do not move it. My answer has a cost: the university must agree who the backup approver is. That is harder than adding a date to a screen.
Reflection