I study economics at NTPU. Can I join, too?
How I joined the team
When I first started university, I didn’t have a clear goal for my life. I was studying economics at National Taipei University, knew a little design, and had participated in some projects in the g0v community. But I still didn’t know where those experiences might take me.
Later, I met an older student online, and we talked about an opportunity to join a team working on NTU’s university administration systems. My first reaction was surprise: “I study economics at NTPU. Can I really join the team at NTU? How could an opportunity this good exist?”
At the time, working on systems that people at NTU would actually use was an opportunity I hadn’t imagined. The team looked at things I had made in g0v, thought I might be able to take on the work, and asked whether I wanted to come.
They happened to need help, and I happened to be looking for a chance to try something. I wasn’t thinking very far ahead. If someone was willing to invite me to work with them, I wanted to see what I could contribute. There were also more experienced designers on the team to guide us, so I could learn as I worked. I said yes.
And so, a student studying economics at NTPU, who made things in an open-source community in his spare time, began working on NTU’s administrative systems. The projects I had shared within that community took on a new role: they gave people who barely knew me a reason to believe I could handle the work.
The Office of Academic Affairs and the team drove the overall effort. My work included the course website, the transfer examination application system, the teaching evaluation administration interface used by the Curriculum Division, and the Experience NTU open-source design system. I didn’t design every NTU website, and I didn’t do this work alone.
What happens when a design decision reaches a student?
My understanding of design work was quite concrete: organize requirements, open Figma, arrange the screens, and hand things over to the people responsible for implementation. A process I can now describe in a few sentences took a lot of time back then. Where a button should go, what order information should appear in, whether an icon would make sense—each needed attention.
University systems have their own complications. Students come to look up courses, plan their schedules, and get things done. They usually can’t switch to another provider simply because they dislike the interface. A small decision in a design file can determine whether someone finds the information they need or completes the task in front of them.
Our engineering teammates worked hard to make the systems run better. I gradually encountered another kind of problem: things on a screen can mean different things to different people. An icon might seem right for a particular field, yet already mean something else in another context. The categories in our design files might not be the categories a student thinks of when looking for information.
From design files to students’ lives
These questions were difficult to answer just by staying at our desks and thinking. So I began talking with students.
Today, “talking with students” might suggest a carefully planned research program. In practice, I often just wanted to practice interviewing: find someone to sit down with, ask how they normally used these services, and hear what they had encountered. I took notes and arranged interviews, but much of the work still felt basic and piecemeal.
Once, a student told me that when he needed a university service, he often went straight to Google. I had assumed that certain university portals already brought together plenty of information. But as we searched together, I discovered a gap between “there’s a link on the website” and “a student can find what they need.” That conversation also raised questions about using the new course website on a phone. These comments weren’t necessarily easy to hear, but they made the circumstances beyond the screen tangible. Public conversation notes
Looking only at a design file, I could easily think the work was done: the information was there, the entry points were drawn, and the features existed. But the student was describing a different experience. He was preparing to choose courses, looking for resources, and managing his life. The system was just one place he had to pass through along the way. Following his sequence instead of mine helped me see what I had missed.
Making the work approachable
I also began keeping records of these conversations.
In the public collaborative notes, I introduced myself as “Tofus, a student worker at the Office of Academic Affairs” and proposed an open space for conversation. Students could ask about university systems, work alongside me, and help edit the records. The document also recorded something that frustrated me at the time: feedback was often fragmented. It was easy to receive a complaint and change one thing without having enough context to understand how the problem had arisen. Project description for the collaborative notes
Looking back, that document did something subtler than preserve notes: it made work that had been hidden within the team recognizable and approachable to other people.
“There’s a group updating the systems” is still vague. But when a document names a person responsible, explains what people can discuss, and shows how they can contribute to the records, students have someone they can reach. They know whom to ask, and that what they say might be recorded. Putting my name there also meant that I needed to take questions, organize information, and explain the work.
In 2023, I also presented the Experience NTU open-source design system at a g0v hackathon. Taking design materials beyond the team, so others could see what we had made and how to access it, was another concrete way to share the work. The original public talk registration records the title and my name.
On August 26, 2023, I introduced the NTU project at a g0v hackathon. The projection behind me describes a project initiated by NTU computer science students. Taking our design work beyond the team and explaining it to others was part of the job, too.Photo: Yi / g0v.tw. Resized; no cropping. · Photo source · CC BY 2.0Only later did I understand the value of those basic tasks
I now understand more clearly why these forms matter. A public name, a record of a conversation, an act of listening—over time, they can give people a sense that this office is willing to communicate, that they can ask questions, and that users’ experiences deserve to be brought back into the discussion.
I wasn’t thinking about all of this every day back then. I was still absorbed in drawing UI, arranging interviews, and organizing material. Sometimes, I wasn’t even sure what those tasks changed beyond leaving more documents behind.
Later, friends I knew in student government spoke very positively about the Office of Academic Affairs during that period. What they had experienced was openness and a willingness to engage with students. Hearing their feedback helped me see the everyday work I had contributed to in a new way.
I can’t take all the credit for that assessment. The commitment to openness, the services our engineering teammates built, and the efforts of other designers and colleagues all played a part. What I do know is that talking with people, recording their comments, and explaining the work publicly were my ways of participating. Tasks that had seemed basic to me later became part of how others understood the team.
How design’s influence grows beyond the screen
This also changed how I measured design.
I used to judge my work mainly through the screens: were they good enough, did the flow make sense, and how much had I delivered? My experience at NTU made me notice that once work is handed over, it enters another world. People ask: Why was this changed? Whose needs were considered? Who can I contact when something goes wrong? Is there somewhere for my feedback to go?
These questions affect whether something is accepted, and whether people are willing to participate again. To contribute here, a designer needs to step beyond the screen, understand the circumstances of different people, and make their own work open to questions.
I became interested in a kind of work that brings out what makers and users struggle to see about each other, then turns it into material they can discuss together. It requires drawing, but also asking questions, writing, explaining, and repeatedly making real contact with people.
At the beginning, I had simply said yes to an older student and gone to see how I could help. By the time I left this work, I had begun carrying a different question: when people don’t yet understand something, or don’t know how they can participate, can I create a way in that is easier to approach?
Later, that way in sometimes took the form of an image, sometimes a story, and sometimes an app someone could hold in their hands and use.
