Back
Back
Portal.mn – Event ticketing platform
Mongolia's event ticketing platform, designed solo from zero across web and native apps — with a seat map that fits venues it hasn't seen, and a resale marketplace on top of it.
YEAR
2023–2025
ROLE
Product Designer
TEAM
Solo designer, 1–3 engineers
PLATFORM
Responsive web · iOS · Android
STATUS
Live
Outcome
25,000+ tickets sold at peak event 15+ integrated payment partners 3 platforms — responsive web, iOS, Android Designed solo from zero. Still running, with an active secondary market.
Challenge
Mongolia had no dedicated ticketing platform. Events sold through Facebook posts, bank transfers, and paper at the door — which works until a concert sells out and nobody can reconcile who actually paid.
Three constraints shaped the product. There's no dominant card processor, so payment runs through fifteen-plus providers with their own flows and confirmation timing. Venues are mixed inventory — halls, theatres, stadiums — with no standard geometry between them. And tickets that sell out immediately create a second problem the moment the first one is solved: people who bought tickets they can't use, and people who want them.
The seat map was the hardest single piece. Not because any one venue is complex, but because a new venue arrives whenever a new client signs, and the system has to absorb it without being rebuilt each time.
My Role
Sole designer across the whole product — discovery, event pages, seat selection, checkout, ticket wallet, the organiser side, and the resale marketplace — on responsive web and both native apps. I built the design system it runs on, and the brand, pitch decks, and event posters alongside it. I didn't build it. Engineering was one to three people and product calls were made together. The title was Head of Design, but there was no design team to head.
Process
Seat maps as a system, not as drawings
The obvious approach is to draw each venue. That works for three and collapses on the fourth, because every new venue becomes a bespoke design task and nothing carries forward. Instead, venues decompose into three primitives — sections, rows, and seats — assembled per venue rather than drawn per venue. A concert hall and a stadium are the same components in different arrangements. Most venues get built from templates; custom work happens only where the geometry genuinely doesn't fit. The consequence is the point: a venue Portal has never seen can be configured rather than designed, which is what lets the platform onboard clients without a designer in the loop each time. The same flow handles reserved seating and general admission. The map appears when seating is assigned and doesn't when it isn't, but discovery, selection, hold, and checkout are one path. A buyer never has to know which kind of event they're at.
A secondary marketplace, not just refunds
Sold-out events produce two frustrated groups at once — people holding tickets they can't use, and people who missed out. Most platforms address the first with refunds and ignore the second, which pushes resale onto Facebook groups where nobody can verify anything. Portal built the resale market into the platform. A ticket holder lists their ticket, a buyer purchases it, and ownership transfers inside the system — so the ticket is verifiable at the door and the original holder's copy is void. I designed the flow and the architecture end to end: listing, pricing, discovery of resale inventory alongside primary tickets, transfer, and what happens to a resold ticket's original owner. The platform runs on blockchain infrastructure, but that isn't what made resale work — the transfer logic would have functioned without it. The design problem was ownership and trust, not the ledger underneath.
Holds that scale with demand
Selecting a seat has to reserve it, or two people buy the same one. But a hold on a quiet event and a hold on a sold-out concert are different problems. Portal uses both: a countdown timer once seats are selected, and a queue in front of checkout when demand warrants it, chosen per event. The timer makes an existing constraint visible. The seat is held and it won't be held forever — showing that is better than a silent hold that expires without warning, which is the failure mode that generates support tickets.
Keeping the map on mobile
Mobile seat selection is the hardest surface. The map is dense, seats are small, and a phone shows a fraction of a stadium. The easier pattern — section, then row, then seat as three list screens — is faster to build and easier to tap. It also destroys the thing a seat map is for: seeing where you'll be sitting relative to the stage. Portal kept the visual map on mobile with pinch-zoom and tap. It asks more of the user and preserves the spatial understanding that makes seat selection feel like choosing rather than picking from a list.
Trade-offs
Resale prices are uncapped.
Sellers set whatever they want. Most modern ticketing platforms cap resale at or near face value to suppress scalping, and we chose an open market instead — it keeps liquidity high and stays out of the organiser's pricing relationship with their audience. The cost is obvious: on a genuinely sold-out show, prices go where demand takes them, and the platform is the venue for that. It's the decision on Portal I think about most.
No organiser analytics dashboard.
Portal built refunds, transfer, and personalised discovery; organisers got sales data by other means. With one designer and a small engineering team, dashboard work would have come out of the buyer-facing experience, and that's where the platform lives or dies.
The mobile seat map.
A list-based selector would have been faster to build and easier to tap. Keeping the map is a real cost in interaction difficulty, and I'd make the same call.
What I learned
Designing for venues I hadn't seen produced the good answer. If Portal had launched with three fixed venues I'd have drawn three maps and been stuck at the fourth. Being forced to accommodate the unknown is why sections, rows, and seats became primitives.
Solving sold-out events creates a second problem immediately. Getting tickets to sell out fast is the win; the moment it happens you have people holding tickets they can't use and people who missed out. Building the resale market was answering a problem the product's own success created.
Support tickets were the research. There was no formal testing — organiser complaints and support volume were what we had, and they pointed at the same places repeatedly. Less rigorous than watching users, specific enough to act on.
The easier mobile pattern was the wrong one. A section-row-seat list would have tested better on tap accuracy and lost the reason seat maps exist.
Back
Portal.mn – Event ticketing platform
Mongolia's event ticketing platform, designed solo from zero across web and native apps — with a seat map that fits venues it hasn't seen, and a resale marketplace on top of it.
YEAR
2023–2025
ROLE
Product Designer
TEAM
Solo designer, 1–3 engineers
PLATFORM
Responsive web · iOS · Android
STATUS
Live
Outcome
25,000+ tickets sold at peak event 15+ integrated payment partners 3 platforms — responsive web, iOS, Android Designed solo from zero. Still running, with an active secondary market.
Challenge
Mongolia had no dedicated ticketing platform. Events sold through Facebook posts, bank transfers, and paper at the door — which works until a concert sells out and nobody can reconcile who actually paid.
Three constraints shaped the product. There's no dominant card processor, so payment runs through fifteen-plus providers with their own flows and confirmation timing. Venues are mixed inventory — halls, theatres, stadiums — with no standard geometry between them. And tickets that sell out immediately create a second problem the moment the first one is solved: people who bought tickets they can't use, and people who want them.
The seat map was the hardest single piece. Not because any one venue is complex, but because a new venue arrives whenever a new client signs, and the system has to absorb it without being rebuilt each time.
My Role
Sole designer across the whole product — discovery, event pages, seat selection, checkout, ticket wallet, the organiser side, and the resale marketplace — on responsive web and both native apps. I built the design system it runs on, and the brand, pitch decks, and event posters alongside it. I didn't build it. Engineering was one to three people and product calls were made together. The title was Head of Design, but there was no design team to head.
Process
Seat maps as a system, not as drawings
The obvious approach is to draw each venue. That works for three and collapses on the fourth, because every new venue becomes a bespoke design task and nothing carries forward. Instead, venues decompose into three primitives — sections, rows, and seats — assembled per venue rather than drawn per venue. A concert hall and a stadium are the same components in different arrangements. Most venues get built from templates; custom work happens only where the geometry genuinely doesn't fit. The consequence is the point: a venue Portal has never seen can be configured rather than designed, which is what lets the platform onboard clients without a designer in the loop each time. The same flow handles reserved seating and general admission. The map appears when seating is assigned and doesn't when it isn't, but discovery, selection, hold, and checkout are one path. A buyer never has to know which kind of event they're at.
A secondary marketplace, not just refunds
Sold-out events produce two frustrated groups at once — people holding tickets they can't use, and people who missed out. Most platforms address the first with refunds and ignore the second, which pushes resale onto Facebook groups where nobody can verify anything. Portal built the resale market into the platform. A ticket holder lists their ticket, a buyer purchases it, and ownership transfers inside the system — so the ticket is verifiable at the door and the original holder's copy is void. I designed the flow and the architecture end to end: listing, pricing, discovery of resale inventory alongside primary tickets, transfer, and what happens to a resold ticket's original owner. The platform runs on blockchain infrastructure, but that isn't what made resale work — the transfer logic would have functioned without it. The design problem was ownership and trust, not the ledger underneath.
Holds that scale with demand
Selecting a seat has to reserve it, or two people buy the same one. But a hold on a quiet event and a hold on a sold-out concert are different problems. Portal uses both: a countdown timer once seats are selected, and a queue in front of checkout when demand warrants it, chosen per event. The timer makes an existing constraint visible. The seat is held and it won't be held forever — showing that is better than a silent hold that expires without warning, which is the failure mode that generates support tickets.
Keeping the map on mobile
Mobile seat selection is the hardest surface. The map is dense, seats are small, and a phone shows a fraction of a stadium. The easier pattern — section, then row, then seat as three list screens — is faster to build and easier to tap. It also destroys the thing a seat map is for: seeing where you'll be sitting relative to the stage. Portal kept the visual map on mobile with pinch-zoom and tap. It asks more of the user and preserves the spatial understanding that makes seat selection feel like choosing rather than picking from a list.
Trade-offs
Resale prices are uncapped.
Sellers set whatever they want. Most modern ticketing platforms cap resale at or near face value to suppress scalping, and we chose an open market instead — it keeps liquidity high and stays out of the organiser's pricing relationship with their audience. The cost is obvious: on a genuinely sold-out show, prices go where demand takes them, and the platform is the venue for that. It's the decision on Portal I think about most.
No organiser analytics dashboard.
Portal built refunds, transfer, and personalised discovery; organisers got sales data by other means. With one designer and a small engineering team, dashboard work would have come out of the buyer-facing experience, and that's where the platform lives or dies.
The mobile seat map.
A list-based selector would have been faster to build and easier to tap. Keeping the map is a real cost in interaction difficulty, and I'd make the same call.
What I learned
Designing for venues I hadn't seen produced the good answer. If Portal had launched with three fixed venues I'd have drawn three maps and been stuck at the fourth. Being forced to accommodate the unknown is why sections, rows, and seats became primitives.
Solving sold-out events creates a second problem immediately. Getting tickets to sell out fast is the win; the moment it happens you have people holding tickets they can't use and people who missed out. Building the resale market was answering a problem the product's own success created.
Support tickets were the research. There was no formal testing — organiser complaints and support volume were what we had, and they pointed at the same places repeatedly. Less rigorous than watching users, specific enough to act on.
The easier mobile pattern was the wrong one. A section-row-seat list would have tested better on tap accuracy and lost the reason seat maps exist.