An Evaluation of the TALAB Enlistment Process

Kathleen Ong
User Experience Society
9 min readOct 29, 2017

Co-written with Avery Si and Alexis Collado, Edited by Carlos Arcenas

Have you ever felt scared to do something for a second time, knowing you got hell the first time? That’s what most Ateneans were feeling especially with what happened in last year’s Talakayang Alay sa Bayan (TALAB) enlistment.

TALAB is a way for the Ateneo de Manila University to bring awareness to current issues in the Philippines through lectures, presentations, and tours. Last year’s theme revolved around the Macros Regime and Martial Law, very apt with the controversial burial of Marcos in the Libingan ng Mga Bayani.

TALAB is actually the re-branded program of the Alternative Class Program (ACP), which ended in 2009. At the time, ACP was just simply a recreation session for students, but TALAB elevated the concept by organizing events that socially relevant. With TALAB happening the first time last school year, the organizers chose the Ateneo Integrated Student Information System (AISIS) for the online enlistment process.

Normally, AISIS is used by students to pick their classes for the semester. You click on a subject in the Enlistment page. Then another page will appear, with the possible class choices for that certain subject and a corresponding Enlist button. Delisting a class occurs in the Enlistment page. You can’t simply do something, like unclick, to do it. Oh also, no one should forget to click Confirm Enlistment button every time you’ve chosen a class, before going back to enlist for other classes — or else you lose the slot. In short, there’s this back and forth navigation that happens, which can be a little crazy when hundreds of people are vying for the same class, although TALAB is somewhat different.

TALAB is much simpler since a user must only choose two classes from a very long list of choices. But the hypothetically simple process of enlistment was one of the traumatic horrors for students last year, trumping even the regular enlistment (which is traumatic enough).

People know the story of the crashing server, which almost everyone experienced, and the disappearing slots within the first ten minutes. At one point, TALAB became a trending topic on Twitter, because many students had something to say about the experience.

And although Ateneo tried its best to provide a second chance to enlist in classes, some still had no luck.

What about this year?

The 17 Sustainable Development Goals (SDG Compass)

This year’s theme is the Sustainable Development Goals (SDGs) of the United Nations. The SDGs tackle different issues relating to poverty, inequality, and climate change, all of which are interconnected. People are recognizing that sustainable development is necessary in order for the future to exist as we do in the present. This also means thinking of long-term plans that impact Philippine society.

Along with that, the User Experience (UX) Society partnered with the Computer Society of Ateneo (CompSAt) to design and implement a better enlistment process for this year’s TALAB. They listened and really took note of what the students needed.

Building the TALAB enlistment system was not an easy feat. It took several weeks of rigorous design research work in order to arrive at the core of the problem and land on our final designs. Here’s what the team did:

Design Process

Various students in the Co-Design Session of UX Society

Because the TALAB enlistment system was used by Ateneans, the team wanted to involve some students in the design process to take in their feedback from last year.

1. Online interview screening

Before the co-design session, the team held an online interview screening process in order to make sure that they could select the right participants who can contribute great insights and provide good feedback. The team also made sure to select 2 participants from different courses (in this case, we got students from Management Information Systems, Computer Science, Information Design, Electrical and Computer Engineering, and Management Economics) to get different design perspectives during the co-design session.

2. Co-design Session (w/ Ateneo students)

A Co-design Session is a design research method where the project team involves its target end-users in the early design phase of a particular product. The session typically starts with storytelling and gathering ideas and insights from their previous experiences with using a particular product. From these insights, the participants will be tasked to concretize their ideas through rough flows charts and sketches. The purpose of this session is to be able to generate as many ideas as possible based on direct inputs from the end-user’s side and to further validate if those ideas are meeting the needs of the target audience.

This was the process the team followed during the co-design session involving the students who were selected earlier:

a. Open forum discussion with students on their TALAB experience.

b. Crazy 8’s — Individually prepare 8 different sketches of ideas based on inspirations and feedback. (8 minutes)

c. Share it with the team. Each member should describe his/her idea to the team. (10 minutes)

d. Team selects ideas that they will detail together in the form of sketches (prototypes) and/or flows. (20 minutes)

e. Present your detailed idea/sketches/prototypes to the team. (5 minutes)

Considering all of the ideas and insights the team had gathered from the co-design session with the students, the team conducted an internal design studio to work on the details they had so far and to further concretize it through user flows and wireframes.

3. Design Studio (only designers and developers)

A design studio is a rapid idea-generation technique used to come up with tons of concepts in a short amount of time. We held this session together with the developers from CompSAt. We conducted individual sketching and pitching, while critiquing was done within three groups. After each cycle, the individual members were to iterate on their design, but are allowed to use ideas from their group mates. In the end, each group was to come up with a final design.

We had over three alternatives where we debated feature components, technical feasibility, and the soundness of the ideas. Things like single-click enlistment, filters, a separate information site, enlistment summary mechanics, interaction flow, server load, and the technology stack were discussed and debated on. Design trade-offs were discussed here, since we could not implement all of our wishlist features because of technical limitations.

It’s a much better way to argue and critique than over chat or email, as we were able to weigh the pros and cons of each design faster and more efficiently. Each team defended their idea, and in the end, we used concepts from each group to come up with the final design.

4. High-fidelity Mock-ups

Synthesizing all ideas, insights, and research, we were ready to turn low-fidelity sketches to something more close to the actual TALAB website. Three designers from UX Society worked on the website mock-ups on Sketch App in a span of two days and their developer hand-off to CompSAt was done through Zeplin. From this point forward, CompSAt was in-charge of the front-end and back-end development process, taking the project to completion.

So, how did the new system fare?

This time, students had better things to say about the new system on social media. Enlistment went fairly well for most students. People found it painless and hassle-free, the opposite of the past enlistment.

Others enjoyed the overall look.

Some even asked to make AISIS adapt the very design of the TALAB enlistment, which is BIG, considering that last year’s design was previously hailed as being worse than the regular one.

The UX Society conducted its own survey right after enlistment. It distributed an online form through social media platforms, such as Twitter and Facebook. The survey had a total of 98 respondents comprised of sophomores, juniors, seniors and super seniors. Each group had 34, 40, 21, and 3 respondents, respectively.

According to UX Society, 90% of respondents had an overall positive experience. In the sample, 32% said their experience was “smooth.” 28% commented on how the whole thing was fast and/or easy. 50% had no problems at all.

Going into the more specific components of the process, people had something good to say about the usability and look of the website. In terms of usability, 36% mentioned the conflict check feature, where available classes that conflict with a chosen class cannot be selected by the user. 26% of respondents noted the easy navigation of the website. 16% found the hide button (which eliminates full classes from view) very convenient. In terms of look, 10% complimented the overall design, while 11% mentioned the interface in particular.

Despite the positive feedback from the respondents, there are still some aspects that need improvement. 4% found that information, such as schedule changes, venues, and sponsors, was lacking. 6% had enlistment summary issues that were mainly regarding the visibility of the summary itself, since it was placed on the bottom of the enlistment page. 4% did not know of the process of enlistment, probably because the password needed was not the standard AISIS password that Ateneo uses for all login-based access networks. The new process also did not anticipate that some students only needed to enlist for a single class instead of the required two classes.

The biggest suggestion from respondents was to show available slots prior to the enlistment itself. There was another suggestion to have filtering and sorting features for dates, topic type, and status. People also hoped for more noticeable display of buttons and information. One respondent commented that some of his friends assumed that all of the events were on the 17th of October when in fact some were on the 14th. Another respondent did not see the hide button immediately. In addition, the dissemination of information was poor. Although most of the respondents managed to get slots, they only found out about the enlistment date and process at the very last minute.

But still, even with these critiques from the respondents, there was a huge turnaround from the previous state of the TALAB enlistment.

Seeing some patterns

From the results of the evaluations, the students are:

All about real-time updates.

Many students wanted to see how much slots there were before they enlisted. Of course, everyone wants to have a schedule that fits perfectly to what they are interested in and what is most convenient for them. What better way to do that than planning ahead before your enlistment? The sense of uncertainty lets some people take strategy to the next level.

People should be able to have an idea of what is the next best thing for them, without that much planning.

Wanting Fast, Fast, and Faster.

There are just things that everyone wants — a solid TALAB class with a famous personality as the speaker. The only way to get it? Speed. The person who can login and click the fastest wins. Therefore, people want utilities that aid in speed. It’s why many people mentioned the conflict check. One step of the decision process is eliminated. Is this class going to affect the other one? Yes? Or no? No need to remember the schedule. You immediately know the answer. People want features that make the process of picking a class easier.

However with speed comes selective attention. In the hunt for that perfect class, people sometimes miss a few things — buttons or even details. The solution would be to find ways to bring those things to attention despite the user’s focus being elsewhere.

Thinking like Ateneans.

All users of this system were familiar with the Ateneo way of doing things, so when a login page asks for your ID Number? You would naturally type your password for AISIS, unless you were informed beforehand. Because of the familiarity of the process, some people have mistaken the TALAB enlistment as an actual extension of AISIS.

The Future

We know what can be improved based on the current system. Nonetheless, there are many things that can be explored in the next iteration. The TALAB design team has several suggestions that can totally change how we do enlistment:

Trading classes with friends

Trading can allow for more flexibility even after the enlistment process itself is over. This can be the fix to the “I regret picking this” and “Oh no, I can’t go!” moments.

e-Receipts

It makes sense to have a receipt for online purchases, why not for your enlisted classes? This ensures that you really got that slot, and you weren’t just dreaming. A e-receipt can also be proof in case of any mix-ups during TALAB.

Different Design

The TALAB enlistment may seem different, but its basic features are the foundations of AISIS enlistment process, only now with a few upgrades. Moving away from the usual way of doing things can lead to different possibilities. There might be a better solution, but change is held back by the current standards of Ateneo.

In the end

The goal of all of this is simply for everyone to have a wonderful TALAB experience overall, and that starts with the enlistment process. Enlistment gives you an impression of how TALAB is organized. It is the step that moves you closer to actually attending the event. Whether this year’s system managed to fulfill its part towards the goal is relative, because users are different. Regardless, there is a movement towards inclusive design. The needs of students are being anticipated. If newer versions of TALAB continue the trend, inevitably one day we will reach “#enlistment_paradise.”

--

--