Redesigning RTÉ Player: Individual Contribution and Team Collaboration (5/5)

Michael Bengwayan Jr.
4 min readJan 22, 2021

This blog is the final posts of a series of blogs for an academic group project. The goal of the project is to iteratively redesign and evaluate the user experience (UX) problems of the RTÉ Player mobile app. In this blog, I will be discussing how I lead my team and how we collaborated to reach our goal.

If you haven’t read the previous posts yet, you can find them in the links below:

  1. Redesigning RTÉ Player: User Research on Watching Behaviour and Pain Points.
  2. Redesigning RTÉ Player: Project Planning, Milestones and Team Dynamics
  3. Redesigning RTÉ Player: Prototyping the Redesign
  4. Redesigning RTÉ Player: Designing the Test Plan

Early in the project, I nominated myself as team leader and everyone agreed. I was open to the possibility though of being replaced should everyone see it fit. Fortunately, it never was. As the team leader, I focused on managing expectations, guiding the team from an architectural standpoint and spearheading our concept testing efforts.

I. Managing Expectations

One common problem in team meetings is circular discussions. It’s when conversations would keep going for an extensive period of time and produce no results. To avoid this, I proposed preparing agendas before meetings and setting the meeting duration. However, there were times that I allowed discussions to continue so as not to restrict brainstorming sessions.

Circular discussions are also caused by conflicting ideas which is almost inevitable. For this, I used the parking lot method when facilitating our meetings. This technique sets aside complex ideas and question in a “parking lot” which can be revisited later on so that essential topics can proceed.

An Example of the Parking Lot Technique

To set expectations for the team, I also planned our timeline. This helps in the team’s visibility of the project’s progress.

II. Guiding from an Architectural Standpoint

I often ask my teammates “why” to help them see the bigger picture of problems and provide solutions that not only address surface-level needs but also architecture-level needs.

For example, in helping users browse easier, my team designed the Smart Pick and Pick by Mood which offer users more personalised options. They worked great but did not address the root cause of the problem.

From our heuristic analysis, we know that there are plenty of information architecture (IA) issues in the app but not the overall extent of it. That’s why I conducted a content analysis, as-is and to-be, which helped us see the root cause of all IA issues. Episodes or television shows are found on almost every screen, links in one tab are cross-referencing to other tabs and there were also a lot of duplicated contents in the categories.

Content Analysis: As-is VS To-be (See higher resolution in Miro)
Current VS To-be Navigation Structure (See higher resolution in Miro)

III. Leading the Testing Effort

We brainstormed on a lot of good features but we didn’t have enough time to prototype everything, and with no clear requirements, there was the possibility of scope creep.

To solve this problem, I defined the test plan first before any prototyping effort. This way, we understood what features we needed to prototype and how to design them. This technique is called test-driven designing.

After we were done with our tests, I analysed and synthesised all the data while the rest deliberated on quick fixes that they can apply.

Key Takeaways

It was a great privilege working with my teammates Áine O'Neill, Jaesin Yu, Michaela Mc and Tom Gillan. They were always present during meetings, ready to help and were mindful in how they communicated. I respect and appreciate them all. I would be honoured to work with them in the future, should our paths cross again.

Team Saturn

--

--

Michael Bengwayan Jr.

T-shaped designer and life learner, portfolio design enthusiast and nerd.