The group building a better timetable

The first version was a shared document with too many colors. It listed room changes, missed notices and the questions everyone seemed to ask at the beginning of the week.

Four classmates decided to turn that document into a small timetable tool. None of them had all the skills they needed, so they split the work and asked other students what actually caused confusion.

Their first interviews were held wherever they could catch people: outside lecture rooms, in a library queue and over lunch. Students were less interested in a clever dashboard than in knowing whether a room had changed. The team crossed several ideas off its list before writing much code.

One classmate handled the interface, another checked the timetable data, and the others organised testing and updates. The division was imperfect. When one person was buried in assignments, someone else had to understand enough of the work to keep the project moving.

Start with the problem in front of you

They resisted adding every feature people suggested. The early version had one job: make the next class easier to find. Each test with a friend revealed a different assumption they had made.

The most useful feedback was often the simplest: I cannot find my room or this schedule is out of date.

They learned to show when a detail had last been checked. That small line of text was more useful than making an uncertain answer look confident. When a room change could not be verified, the tool sent students to the official notice rather than guessing.

A test on an older phone revealed another problem: the schedule was too hard to read on a narrow screen. The team made the next class more prominent, reduced the amount of navigation and let users reach a room number without scrolling through the whole week.

The group now meets between lectures to correct details and discuss what to build next. Their project has become a lesson in listening as much as coding.

Keeping it useful

The hardest question is who will maintain the information when the founding group is busy or graduates. They are documenting how updates work and talking to student representatives about a handover. A timetable that looks polished but quietly goes stale would recreate the very problem they set out to solve.

For the moment, they are watching how classmates use the simplest version. Some open it every morning; others only need it when a timetable changes. Both habits matter. The team wants a tool that earns a place in a student routine, not one that demands attention for its own sake.

Built with the campus

The tool remains a work in progress. That is part of its strength: the people using it can tell the team what is missing, and the team is close enough to understand why it matters.