Berlin bar-restaurant operating since 2008 with no digital presence beyond Instagram and word of mouth.
Role: UX Researcher (team) | UI Designer (individual) | Team of 3 | 2 weeks
Week 1: team research and mid-fi | Week 2: individual hi-fi
Tools: Figma, Lyssna, Google Forms, Photoshop, Slack, FigJam
Only 10-15% of followers see posts.
No way to book online.
No menu visible before visiting.
Would you use a website/app? (40.7% Yes)
Have you ever visited Kvartira62? (63% No)
Survey: 27 respondents.
Top needs before visiting: menu (85%), prices (81%), photos (81%), opening hours (58%).
Week 1 — team. Owner interview, Google Forms survey, affinity mapping. Mid-fi prototype: home → menu → reservation flow.
Week 2 — individual. Re-analysed data, identified key issue: navigation buried core functions. Solution: persistent bottom bar with Reservations / Menu / Events always visible.
The team's mid-fi included an interactive table map for reservations. I removed it in the individual sprint for two reasons: it limits the owner's flexibility to reorganise the space, and showing occupied tables risks discouraging bookings before the user even tries. A simpler time-slot and guest-count flow solves the user's core need without creating operational dependencies.
Moodboard → 5-second test on Lyssna → visual direction confirmed: warm, energetic, not folkloric.
Beyond the core design task, I created a logo for Kvartira 62 — a door with the number 62, light spilling from inside. It reflects the venue's founding concept: an apartment open to everyone, warm and unhurried. I also suggested the owner consider renaming his Facebook page — the current name carries Russian connotations that may alienate part of the Berlin audience given the current climate.
Website and mobile app in Figma. Three core flows always reachable: menu, reservations, events.
Returning to data after the team sprint was the right call — it changed the navigation logic before hi-fi, not after. The first mid-fi buried the three core functions inside the general navigation. Users shouldn't have to think about where to find a menu or how to make a reservation. It should be immediate.
Removing the interactive table map was another decision driven by business logic rather than pure UX preference. A static floor plan that requires constant updating creates an operational dependency the owner simply doesn't have the bandwidth for. And showing occupied tables risks discouraging bookings before the user even tries — a problem the phone reservation system never had.
The owner reviewed the final result and responded positively — he said he plans to implement it when his schedule allows. That was the closest thing to a real-world validation this project could get.
If the project continued, the next step would be usability testing on the reservation flow with real users — specifically the time slot selection, which works visually but hasn't been tested under real conditions. A second iteration would also explore whether the event calendar needs filtering by date or category as the content scales.
