// COOLTOUR
Context
MOME ID course · team of 3
Role
UX & UI designer
Duration
4 months · 2025
Scope
Research · UX · UI · Illustration
Summary
COOLTOUR was our team project in the MOME ID (Interaction Design) course at Moholy-Nagy University of Art and Design, Budapest: four months from research to a clickable prototype, ending in a final presentation in May 2025. It's a concept, not a shipped product.
My part: I was the only one on the team with a UX background, so the UX, the UI and the eight characters were mine. The research, the synthesis and the journey map we did together.
Rural cultural institutions in Hungary live on school holidays and long weekends, and their income swings with them. Our research showed that the well-resourced ones barely need another app, while the under-resourced ones can't reach visitors at all — and visitors with time and money still miss programs, because the information never reaches them. So we designed one app for both sides:
Two sides, one navigation. Visitors and institutions get different home screens but the same three tabs; the middle tab handles entry on both sides — the visitor's tickets, the institution's scanner.
A monthly membership on a 12-month plan, with a free tier. The COOLTOUR Pass is billed monthly with a 12-month commitment, so the money keeps coming in the quiet months too.
Regional badges. Ten visits in a region earns its governor — a king, a jester, a knight — and an extra discount: a reason to visit the small museum, not just the famous castle.
The Problem
The course asked for a platform that would raise visits at rural cultural venues outside the season and balance their revenue across the year through new sales models.
The brief named one user: the institution. But revenue won't grow without people who want to come, so the first question wasn't what to build but for whom — and the answer was both sides.
Research
We started with a research plan that questioned the brief itself — is there really an off-season? Then we ran semi-structured interviews with five institutions, from a village culture house to the Festetics Palace, and four visitors from our own circles, one of whom I interviewed myself. The visitor sample was small, and only two of the five institutions were the under-resourced kind COOLTOUR is most for. Next time I'd recruit beyond our own circle — a retired couple, a teacher planning a class trip.
Visitors: the information doesn't reach them
A couple who plan trips around events, a mother whose children need something to hold their attention for forty minutes, and a single woman who prefers quiet weekday programs want different things from the same castle. What they shared was the problem of finding out:
"You often want to find a program — you have the time, the money, the weather's nice — but the information never reaches you." — 29, single, Budapest
Last year's event, not this year's. Facebook events lack the program; a festival's own site sometimes still points to last year.
No way to filter for children. The mother of three found child-friendly sights by scanning a map herself, because the listing site she tried couldn't show programs suitable for children.
Unclear pricing cost a visit. An event was skipped because neither the price nor how the ticket worked was clear.
On paying, opinions split. The solo visitor would, depending on the price. The mother of three: "I wouldn't buy a pass for the app. A platform that collects events in one place would interest me."
Institutions: two different problems
We expected one kind of institution. The interviews found two, and they needed opposite things from an app: one group is already online and has no time for another platform; the other can't reach visitors at all.
Five institutions, the same interview guide — and two very different problems.
Seasonality was the one thing they all shared: every institution had quiet months, so the brief's premise held. So COOLTOUR had to serve both groups, with a different promise to each.
Synthesis
We sorted the interview notes on two affinity boards, one per side, then built three visitor personas — Csenge (a family), Petra (a couple) and Szilvi (solo) — with their empathy maps, one for the institutions, and a visitor journey. Six pain points came out of it:
Visitors can’t find what’s on, and venues can’t afford to tell them. The smaller notes come from our empathy and journey maps.
They led to our How might we questions, among them: how might we help a cultural institution attract more visitors off-season, so it can raise its revenue?
Ideation: eighteen ideas, one core
One feature at the center — everything in one place — and the rest sorted around it.
We sorted eighteen feature ideas into three rings. At the center sat everything in one place — needed by everyone, all the time. From there, the user flow decided what got built. Two nice-to-haves made it in anyway: badge collecting, which became the last step of the visitor flow, and social-media sync, which answers the institutions' pain of keeping every platform up to date.
A "persona non grata" exercise — imagining who would abuse the service — produced a fake institution that sells tickets to an event that doesn't exist. The institution registration answers it: a tax number checked against public records, bank details, and two-factor authentication for the contact person.
Testing the wireframes
Before the UI, we tested the clickable wireframes with three students from the course, on both sides of the app; two sessions were written up in detail. The biggest problem was the most distinctive idea: neither documented tester understood the governors.
Three findings changed the UI:
"Not clear what the badges are." → Every character now opens a pop-up that explains it, shows its region and counts the visits left — the second screen of the Governors block below.
"There's no ticket button." → The event page gained a price, a one-line note on how entry works and a Buy button.
Favorites and notifications were hard to find. → They moved from header icons to a plain row on the profile.
Not everything came from the test. The add-event form got an entry type — free, free with Pass or paid — where institutions decide how the Pass applies.
The testers were design students, not visitors or institution staff. The next test would be with institutions: can a small museum's staff create and sync an event without help in ten minutes?
Final Design
Both sides share the same dark three-slot tab bar — Home, Tickets, Profile for visitors; Dashboard, Scan, Add event for institutions. The header gradient tells them apart: pink for visitors, blue for institutions.
Registration and membership
Csenge tells the app what she's into before it shows her anything.
Find an event
Every card and pin is an event, not a place.
Governors
Eight regional governors — seven regions plus Budapest — each a character to earn.
Publish and check in
Put an event out, and let people in.
The design system
Two typefaces carry two voices: Staatliches for the characters and plan names, Roboto for everything you read and tap. Colour splits the same way. Neutral surfaces keep the interface quiet, mint marks every action — buttons, the active tab, selected controls, progress — and the pink and blue header gradients tell visitors and institutions apart at a glance.
For this case study, I reorganised our colour styles into primitive and semantic tokens; the screens themselves use the original styles.
Colour
Primitives hold the values; semantic roles say what each value is for.
Typography
Staatliches for the characters and plan names, Roboto for everything you read and tap.
Reflection
The revenue split we left open. Our feature sort gave institutions a share of the membership, but we never worked out how. I'd now pool the fees and split them among institutions by how many Pass holders visited each, paid in equal monthly installments — predictable income even when visits are seasonal. It only works if the extra visitors bring in more than the discounts cost — which is what I'd measure first, alongside the off-season share of visits.
The institution side belongs on desktop. We had planned it, and the jury said the same: staff would enter events once, on a website at a desk, and the phone app would only need to scan tickets at the gate. The prototype stayed mobile on both sides; a desktop institution side is the first thing I'd add.
The app starts with a question, not a promise. The jury pointed out that the first screen asks visitor or institution? before saying what COOLTOUR is. A short onboarding — two or three screens on what the app does for each side — would come first, so the role choice makes sense when it's asked.
Designing in a mixed team. My teammates came from graphic design and development. We shared the research evenly — each of us ran our own interviews — but neither of them had worked in Figma, so the wireframes, the UI and the prototype fell to me; learning the tool from scratch — auto layout, components and reusable elements, prototyping — would have taken longer than the course allowed. What I'd change is the start: map everyone's skills in the first week and plan the build around them — copy, test scripts and asset prep for the others, Figma for me — so the build phase doesn't rest on one person.
Also open. What the scanner does without internet; the launch — a two-sided product starts empty, and we never chose which region and institutions go first; and the agreements behind the app — several of the institutions are publicly owned, so joining a revenue-sharing scheme would be their owners' decision.
On AI: the characters started as image-model sketches that I redrew by hand in Illustrator.