Taiwan’s nightlife is booming—but it’s still mostly “offline”. Club listings rely on outdated sites, and invites are handled manually. Bomber saw this as a clear opportunity to bring digital innovation into the scene.
BOMBER
They create a big streak in Taiwan by create the first SaaS ERP for nightclub
Taiwan and Nigh Entertainment
Huge product scope, Language gap on research, and Limited source
Nightclub is phase 1, and to give end to end solution, it need a lot of sub product to cover this. It’s a huge product scope. Starting from POS front office, POS kitchen, Security apps, promoter and more sub product that need to be created
10 sub product + 6 months timeline
I just want see the design..
If you think your time is limited, you can go through directly to outcome design through this link
Let's continue talk about design process..
Problem 1
LANGUAGE GAP & RESEARCH
Most of team coming from Indonesia, we can speak english but not Chinese. For design team it's a big challenge for research, as we know research is fundamental step before develop product.
PROBLEM
With proper research, a product roadmap becomes more focused, and feature plans are validated, avoiding decisions driven purely by ego. Our product was built for the Taiwan market, but most of the team was based in Indonesia, making research difficult to conduct. Additionally, research often takes time, and at that point, the product owner saw it as unnecessary.
When I joined, the product was still a blank slate—no foundation, no clear direction. The team was building a SaaS platform based only on the owner’s input, with little to no research. I quickly realized this approach wouldn’t work.
I pushed for research several times, but it didn’t stick—until things started to fall apart. Within a month, features piled up, deadlines slipped, and development lost focus. That was the moment I stepped in again, and this time, the team finally embraced research.
Once research began, new doubts arose—especially from top leadership questioning how our team handled it. To address this, I created a structured research framework (details confidential), presented it, and we iterated together. It wasn’t perfect at first, but over time, the results spoke for themselves. A tough start turned into a rewarding win for the product.
Problem 2
HUGE SCOPE & SCALABLE DESIGN
You can't build a skyscraper with a messy blueprint—proper file architecture in Figma is key to creating scalable, organized designs. Here are some key things that I had done in Bomber related prepare and build the architecture.
LOST IN FIGMA
Context is crucial for developers, especially when they’re exploring our design files. With a large scope and numerous features, they often feel lost while navigating the Figma files.
Clear naming conventions make it easier for developers when they need to find something, as they can simply select the relevant larger module.
SCALING PROPERLY
I applied the concept of Object-Oriented Programming to streamline the distribution flow of tokens, components, and colors.
Universe is theme file where you can create another theme, Galaxy used for store basic component and Spaceship for brand component. Rest of them is used for production file.
MANAGING ISSUE
The most common issue we faced was developers not achieving pixel-perfect accuracy, leading to many UI inconsistencies. At the time, tasks were assigned through Trello and later Jira, but the problem was that developers weren’t fully aware of their mistakes. Here’s how we addressed this issue.
Problem 3
CLEAN HAND OFF
With such a large scope, the handoff process became a key factor at Bomber, greatly affecting the timeline. When developers had to constantly go back and forth with designers to confirm features and flows, it consumed a lot of time, especially if they weren’t on the same page. Here’s how I ensured the design communicated effectively with both the dev team and non-tech stakeholders.
STATES FOR DEVELOPER
Context is crucial for developers, especially when they’re exploring our design files. With a large scope and numerous features, they often feel lost while navigating the Figma files.
Too many back-and-forth questions can slow down development. To avoid this, I focused on creating highly detailed documentation—especially around layout behavior across screen sizes, which is where most developers struggle. This proactive approach significantly reduced confusion and kept the team moving efficiently.
SIMPLE DATA DIAGRAM
In the Software Development Cycle, the backend team typically collaborates with the design team from the start. Data diagrams serve as a valuable tool for backend developers to prepare the database and API.
Communication Framework
Working remotely makes communication crucial. Poor communication can disrupt the entire workflow, yet it’s often difficult to detect. That’s why at BOMBER, I established basic guidelines for communication patterns and a work framework to prevent unwanted issues.
FLOW CHART
Flowcharts became the simplest way for our team to align our thinking. I typically created them as a starting point, which then served as a discussion tool for the whole team and was refined over time. Flowcharts also acted as a fundamental reference when a feature was more complex.
The most common issue we faced was developers not achieving pixel-perfect accuracy, leading to many UI inconsistencies. At the time, tasks were assigned through Trello and later Jira, but the problem was that developers weren’t fully aware of their mistakes. Here’s how we addressed this issue.
OUTCOME
Below are some of the designs I’ve worked on, though I can’t showcase everything due to a client NDA.
Thank you for visit
The design above was created based on discussions with the product owner and insights from user research. We used an Agile Design methodology, meaning the design process was done iteratively. As a result, there may still be some aspects that are not fully refined yet, with room for further improvement as we progress.
I’m open to presenting this directly if needed. Unfortunately, I can’t share everything here due to an NDA with the involved parties.
