Major Project 2
02/02/2026 - 27/03/2026
Ng Zheng Kai 0359424
Bachelor of Design in
Creative Media
|Major Project 2
INSTRUCTIONS
Progress
There's a particular kind of optimism that comes with the start of a new project. The brief is fresh, the ideas are flowing, and the problems feel distant enough to be exciting rather than daunting. When our team, Ian, Michael, Jordan and I, first sat down to figure out what Beacon would become, that optimism was very much in the room. What followed over the next several weeks was a process that tested it repeatedly, reshaped it, and ultimately left us with something we could genuinely stand behind.
This is my honest account of that journey. Not a highlight reel, but a real reflection on the design work, the collaboration, the setbacks and the growth that came with building Beacon from concept through to production.
|
| Fig 1.1 Logo design by Ian |
What Is Beacon?
Before getting into the process, it's worth explaining what we were actually building. Beacon is a gaming teammate finder application, a platform designed to solve a problem that any serious gamer has run into at some point: finding people who play the way you do.
Existing solutions are all over the place. You're either posting in subreddits, hoping Discord servers have active members, or getting matched randomly with strangers who have completely different expectations of the game. Beacon was conceived as something more intentional. A dedicated space where players could filter by playstyle, availability, game title and communication style, build squads with actual purpose, and even tie their streaming presence into their profile.
The idea came out of Major Project I, where we built out the pre-production side of things: research, personas, user flows and early wireframes. Major Project II was where we had to take all of that and actually make it real.
The Design Process
Starting from the Foundation
One of the advantages of coming into Major Project II with prior documentation was that we weren't starting from nothing. The research we did in Major Project I gave us a foundation to work from rather than rediscover. That said, going back to that documentation with fresh eyes also made it clear how much had been left at a surface level, and how much deeper we needed to go now that we were actually building.
The first few weeks were spent translating all that research into a real design direction. What should Beacon actually look like? What does the experience feel like for someone opening it for the first time? We went through a lot of references, built mood boards, and had some fairly animated discussions about tone. The gaming space has a wide aesthetic range, from hyper-aggressive neon heavy interfaces to cleaner, more restrained product design, and we wanted something that felt genuine to the audience without leaning into every tired cliché in the space.
|
| Fig 1.2 Moodboard |
Iteration and Refinement
What followed was a lot of back and forth, which in hindsight was exactly what the work needed, even when it didn't feel that way at the time. Our early wireframes were rough and functional. They mapped out the logic without worrying about how anything looked. From there we worked up to higher fidelity, checking the design against our user personas and refining based on what came back from specialist consultations.
The matchmaking filter system went through at least three meaningful redesigns. The first version tried to do too much at once and was genuinely overwhelming. The second swung too far the other way and cut out things users would actually want. The third landed somewhere more sensible, where the essential filters were front and centre and the more advanced options were accessible without dominating everything else.
The squad building flow had its own journey. Early on it felt like filling out a form, transactional and a bit cold. We pulled it in a more social direction, drawing on interaction patterns from apps people actually enjoy using, and that made a real difference to how the whole feature felt.
|
| Fig 1.3 Before and After Prototype Screens |
|
| Fig 1.4 Main page (Matchmaking Page) |
What the Process Taught Me
The thing that stuck with me most from this phase was that every design decision needs a reason behind it. Looking good is not enough on its own. You have to be able to explain why something works, why it serves the user and why it was the right call over the alternatives. That kind of thinking is what separates documentation that actually tells a story from documentation that just records what was done.
I also came to genuinely appreciate constraints. Deadlines and feedback sessions forced decisions that we might have otherwise kept deferring. Not every call was the right one, but making them and dealing with the consequences taught me more than unlimited time ever could have.
Challenges and How We Navigated Them
The Communication Problem
If I had to name the biggest challenge we faced, it wouldn't be the scope, the timeline or any particular technical difficulty. It would be communication, specifically the absence of it at the moments when it mattered most.
Beacon has a lot of moving parts. Matchmaking screens, squad profiles, community pages, streaming integration. Each of us was building different components at different times, often simultaneously. What we didn't fully account for was how fast that parallel working would produce inconsistencies if we weren't actively talking to each other about what we were doing.
The cracks started appearing in the mid-production phase. Buttons that weren't the same size across different screens. Spacing that followed slightly different rules depending on who had built a particular component. Typography that had quietly drifted from what we'd agreed on. Colour usage that was mostly right, until it wasn't. None of it was catastrophic on its own, but together it added up to something that felt like it had been made by four separate people working in isolation, which in some ways it had been.
|
| Fig 1.5 Design inconsistencies |
Why It Happened
The root cause was simple. We hadn't set up a shared source of truth early on, and we weren't looping each other in when individual decisions got made. Someone would adjust a component, change a spacing value or tweak a colour, without mentioning it. Someone else would then build something new off the older version. Over enough weeks those small gaps compound into something that's genuinely hard to untangle.
There was also an assumption sitting underneath all of it, one I think each of us held without quite realising it, that because we'd aligned on a visual direction at the start, we were all operating from the same detailed mental model. We weren't. Decisions that felt obvious to the person making them weren't always obvious to everyone else, and without a consistent shared reference, we were each quietly filling in the gaps in our own ways.
It's a bit humbling to realise that something as basic as making sure buttons look the same across screens actually requires more deliberate effort than it sounds like it should.
How We Fixed It
The moment things shifted was during a mid-project consultation where the inconsistencies got raised in a review. Having it pointed out by someone outside the team made it harder to minimise, and it pushed us toward a more honest conversation about how we were actually working.
After that we made some concrete changes. We pulled together a proper component reference so that agreed styles, sizes and values were documented somewhere everyone could check against. We started doing short syncs before work sessions to flag what each person was building and catch anything that might affect shared elements. We started sharing work in progress more often rather than waiting until something felt finished.
None of it was a dramatic fix. But it moved us from a way of working where consistency was something we hoped would happen, to one where it was something we were actively maintaining. The screens from the later stages of the project are noticeably more cohesive than the earlier ones, and that difference came directly from those changes.
What It Taught Me
The lesson I keep coming back to is that design consistency is really a communication problem dressed up as a design problem. A component library doesn't protect you if the team isn't talking to each other about the decisions being made. The tools help, but the habits are what actually matter.
I also learned that flagging something early, even when it feels small, even when you're not sure it's worth bringing up, is almost always the right call. The inconsistencies we spent time fixing late in the project could have been caught in a two-minute conversation weeks earlier. That ratio doesn't change no matter how experienced you get.
What I Took Away
On Design
I came into this module with a decent foundation in UI/UX and a comfortable relationship with the tools. What I'm leaving with is harder to put a name to. It's a more honest sense of the gap between design that is competent and design that is actually considered.
Competent design solves the problem. Considered design solves it, explains why it works, accounts for the edges, holds up under scrutiny and feels deliberate in every detail. I can look at the earlier screens of Beacon and see exactly where the thinking ran out. That ability to read your own work critically, to understand not just what looks off but why it doesn't work, is the thing I'll carry furthest from this.
|
| Fig 1.6 Community Page |
On Collaboration
I thought I knew how to work in a group coming in. I have a more specific understanding of it now. The skills that actually matter, communicating before something becomes a problem, being explicit about ownership, giving feedback that lands rather than just lands somewhere, are learnable things. They're just not things you can learn without doing the real thing.
Working with Ian, Michael and Jordan over this length of time, with stakes and deadlines that were real, was different from anything shorter. The project was long enough that we couldn't rely on initial momentum. We had to build actual working habits and, when those stopped working, rebuild them.
I'm proud of what we made together. Not without reservation, but genuinely. We took a document and turned it into something you can actually open and use and understand. That's not nothing.
On the Process Itself
The brief asked for a portfolio of design artefacts. What I didn't expect was how much making those artefacts would change my understanding of what the work actually involves. The research, the iteration, the feedback that stings, the decisions you have to make without enough information and the ones you have to revisit after the fact. All of it is the work. Not the setup for the work.
If I were starting Beacon again I'd set clearer agreements with the team from the beginning, document decisions as they happen rather than reconstructing them later, and raise problems earlier than feels comfortable. I'd trust the research more than the first idea, and spend longer in low fidelity before jumping to high.
But I wouldn't swap the process I actually went through for a tidier one. The hard parts were where most of the learning happened.
Figjam Board
Comments
Post a Comment