People document their trips extensively (photos, screenshots, crumpled tickets) but lack tools that transform these scattered artifacts into cohesive, beautiful memories. This case study traces the journey from identifying a structural gap in the market to designing a focused iOS app that solves it.
When people go on a big trip (hopping between cities, visiting temples, concerts, transit) they accumulate a pile of meaningful moments: a train or plane ticket, a museum pass, a football match stub… And by the time they're home, those things have dissolved into a camera roll, a stack of confirmation emails, and a bag of crumpled tickets they'll never find again. I know it because it’s my case anytime I travel.
The issue I face is that there are tools today solve either logistics (Apple Wallet) or quick generation (Ticket Lover) but nothing creates a beautiful, organized, exportable memory out of those moments.
There’s an opportunity here to occupy a space between "functional" and "beautiful." A focused tool that turns trips into aesthetic, shareable memorabilia without trying to be a booking app, a travel planner, or a diary.
Before committing to a direction, I needed to validate a simple but critical assumption: that people were not only documenting their trips and events, but also dissatisfied with how those memories were being preserved.
To do this, I combined three complementary approaches: a quantitative user survey (n=40), a set of survey-inferred Jobs To Be Done (JTBD), and a competitive analysis of existing products in the space. Together, these allowed me to move beyond observable behaviors and identify the underlying tensions between how memories are experienced and how they are currently captured.
The survey done in January 2025 revealed a consistent pattern: people are already documenting their experiences extensively, but the tools they use are not designed for memory-keeping. The table below summarizes how users currently capture their trips and events.
| Method | Adoption |
|---|---|
| Photos in camera roll | 94% |
| Screenshots of bookings | 81% |
| Physical tickets kept | 58% |
| Notes or journaling | 29% |
| Dedicated apps | 14% |
The dominance of camera roll and screenshots highlights a key issue: documentation exists, but it is incidental, fragmented, and not designed to be revisited. This becomes more evident when looking at organization. For multi-day trips, 67% of users report that everything ends up mixed in their camera roll, while only 41% attempt to structure content into albums.
The mismatch is clear: users think in terms of complete experiences (i.e. their whole trip somewhere, a defined week, a precise location…), but their data is stored as disconnected files.
Several strong signals emerged from the data, each pointing to a different failure in the current ecosystem that I have identified.
This indicates that memory preservation is not just about storage or retrieval, but about pride, identity, and emotional resonance.
From these signals, a set of core Jobs To Be Done emerged. These jobs describe not what users do, but what they are trying to achieve. The table below summarizes the most central jobs:
| Job | Core tension | Role in product |
|---|---|---|
| Turn scattered evidence into one story | Chaos → coherence | Foundational |
| Preserve physical memorabilia digitally | Attachment vs fragility | Foundational |
| Transform functional artifacts into memories | Utility vs meaning | Foundational |
| Create missing keepsakes | Nostalgia vs absence | High intent |
| Share content confidently | Expression vs embarrassment | High frequency |
The first three jobs are critical. They define the core value of the product: helping users move from fragmented, low-quality artifacts to cohesive, meaningful representations of their experiences. This reframes the problem space entirely. The issue is not that users lack data or documentation tools, it is that existing outputs do not feel worthy of the experiences they represent.
To understand how the space I mentioned earlier is currently addressed, I analyzed three representative products: Ticket Lover, TicketBoard!, and Mementix.
| Product | Strength | Weakness | Positioning |
|---|---|---|---|
| Ticket Lover | Fast ticket generation, templates, image recognition | No organization, broken sharing | Creation tool |
| TicketBoard! | Simple memory logging | No aesthetics, no export, abandoned | Event diary |
| Mementix | Social features, event coordination | No design depth, no trip structure | Social platform |
Each product optimizes for a different dimension, but none combine them effectively.
Ticket Lover focuses on speed and generation, but lacks any meaningful way to organize or revisit memories. TicketBoard! takes the opposite approach, acting as a simple archive of events, but without any aesthetic ambition or shareable output. Mementix introduces a social layer, but shifts the focus away from the artifact itself toward interactions between users.
The competitive landscape reveals a structural gap rather than a feature gap. Existing products fall into two categories:
None address the full lifecycle of a memory: creation, organization, and expression. This can be summarized as follows:
| Dimension | Ticket Lover | TicketBoard! | Mementix | My idea |
|---|---|---|---|---|
| Aesthetic quality | Medium | Low | Low | High |
| Organization depth | None | Low | Medium | High |
| Shareability | Broken | None | Internal only | External-first |
The research converges on a single conclusion: The problem is not access to information, nor the lack of tools. It is the inability to transform meaningful experiences into artifacts that feel equally meaningful.
My idea is positioned to solve this by focusing on three principles:
In that sense, what I am creating is not a storage solution, nor a ticketing tool. It is a system for turning fragmented, functional data into cohesive, meaningful memories.
My idea is positioned as a creation and memory-keeping tool for visually driven iOS users, deliberately focused on a narrow but under-served layer of the travel experience: transforming fragmented artefacts into meaningful, aesthetic memories.
Starting on iOS is a pragmatic choice rather than a strategic one as I have experience with SwiftUI and Xcode. Expanding to Android could be a scaling decision, if the project takes off on iOS.
The target user is not defined primarily by demographics, but by behavior and expectations:
This is an aesthetics-first user, not a productivity-driven one. They are not trying to optimize their travel, they are trying to represent it well. This distinction is important because it directly influences product decisions: speed, simplicity, and visual output matter more than feature depth.
This is an intent only at this stage, as I will be running a fully open beta first. Monetization will come at a later stage.
The monetization strategy is built around meaningful constraints, not artificial paywalls. Users think in terms of trips, periods, or locations. These naturally translate into collections within the product. Instead of gating features, Lumoria limits capacity at the level of user intent.
The free tier allows users to experience the core value, but introduces limits that create friction at the right moment:
These limits are designed so that users can still complete a first meaningful use case. The restriction appears only once they are invested in the product and have identified the value for them (Aha moment reached). This avoids premature monetization while making the upgrade feel like a continuation, not a purchase.
The paid version removes structural limits and enhances the core experience:
The value proposition is simple: no interruption in building your memories, and higher-quality output.
Growth is driven by product behavior, not external channels. Three loops work in sequence.
At launch, the focus is on validating three things: activation, engagement, and retention.
These metrics map directly to the core loops:
The IA is organized around one finding from the research: users think in trips, not in files. Only 41% of users structure travel content into albums; the majority let everything accumulate unsorted in their camera roll. The primary mental model is experiential, not archival.
This determined Lumoria's top-level structure. The organizing unit is the collection — a trip — not a folder of artifacts. Every other layer derives from that.
Four flows structure the product, each grounded in a specific research signal:
| Flow | Research signal |
|---|---|
| Ticket creation | 40% wanted to recreate memories but lacked accessible tools |
| Collections | 67% reported travel content dissolving unsorted into their camera roll |
| Export | 74% ranked visual quality first — they share because the output is worth sharing |
| Freemium gates | Users invest in trips; gating at the collection level aligns with that investment unit |
Rather than optimizing for flexibility, the goal was to reduce decision fatigue and guide users through a constrained, high-quality experience. The product makes decisions — about layout, structure, visual hierarchy — so users can focus on the memory, not the tool.
The most consequential structural decision was to build ticket creation as a linear, multi-step funnel — not a free-form editor.
The funnel has six steps:
A free-form editor (like Canva) maximizes control but requires simultaneous decisions about layout, type, color, and content without scaffolding. The research signal was consistent: the target user is aesthetics-first and friction-averse. The funnel trades flexibility for speed and quality consistency. Users who want a polished result quickly get one without needing design expertise.
The trade-off is explicit:
The creation flow accounts for real-world interruptions. If a user exits mid-process, they can resume where they left off or discard progress with confirmation. State is preserved across all steps.
In a single-screen interaction, partial loss is low-stakes. In a six-step funnel, abandoning mid-flow without recovery creates disproportionate frustration and breaks the creation-to-export loop that drives organic sharing. Session persistence is a direct activation requirement, not a polish feature.
The freemium model is not layered on top of the product but it is embedded into the experience's structure. The core principle is that limits appear only after value is established. The research described the target user as someone who doesn't know they want the product until they've completed something meaningful with it.
The upgrade flow is triggered when the user has reached the collection cap (2). This limit should be the primary conversion mechanism: it triggers at the moment of highest investment, when the user has already built two collections and wants to start a third. T
When a limit is reached, four paths are presented:
The four-option structure is deliberate. A binary upgrade-or-stop creates a high-pressure moment. The invite path gives users agency without paying, reduces resistance at the conversion point, and advances the product's acquisition loop simultaneously.
I started designing this app by using the Simple Design System from Figma. I knew I would not use it in production but I needed to get my ideas out in Figma and I did not want to spend time creating a design system or identity this early in the project. I started designing an authentication flow (login, signup, forgot password screens), fleshing out the navigation with a Home page, Collections page, Settings page… I quickly got to a V1 of the designs that were functional, but soulless.
The authentication screens make the shift most legible. In the first exploration, the login screen opens with “Please login to start using the app.”, a sentence that does nothing except state the obvious. The sign-up form required six fields before the user had seen a single piece of the product: first name, last name, username, email, password, confirm password. Both decisions were reversed. Copy became “Welcome back!” and “Let’s get started”. Sign-up was reduced to name, email, and password. Less friction at the moment of highest uncertainty.
The presentation model changed too. The first exploration used full-screen navigation for all three screens. The final design uses sheet-style modals dismissed with an X rather than a back arrow which makes authentication feel lightweight and only a step in getting to know the product.
The cork board was the most instructive rejected direction. It was the first metaphor for collections, literal enough to immediately communicate “grouped, physical memories”, warm enough to feel tactile. It looked beautiful in isolation. But it didn’t survive contact with the broader identity direction: against an editorial, luminous aesthetic, cork felt rustic and busy. It was replaced by a clean card grid with stacked ticket previews.
The home tab also disappeared as a first-class view. The first exploration opened with a dashboard on which there were shortcuts to other parts of the app, a resume-in-progress banner if a ticket was being edited, recent tickets, shortcut to favorite collections. The final design removes the home tab entirely, making Collections the landing view. This reflects a structural insight: for a product built around trips, the organizing unit is the collection, not the individual ticket. Surfacing that immediately, without an intermediary dashboard, aligns the first thing users see with how they actually think.
I stopped on the name Lumoria. It’s a contraction of lumière and memoria: light and memory. The name captures the product’s purpose directly: capturing moments in light, preserving them as memories. Two syllables, soft on the ear, distinctive without sounding invented. The tagline followed the same logic: Tickets that last forever. Concrete enough to explain what the product does. Emotional enough to explain why it matters.
The identity uses three distinct assets, each with a defined role and context.
The logotype sets “Lumoria” in EB Garamond Semibold with one structural detail: the dot on the lowercase “i” is replaced by a 7-point star. This is not an ornament — the star reads at the same visual weight and scale as a standard tittle. It is integral to the letterform. Clearspace on all four sides equals the width and height of the lowercase “o” at the same size; this rule is never violated.
The logogram is the app icon mark: a rounded rectangle containing a horizontal 4-color band with a 7-point star cutout at its top center. The cutout is dual-meaning — it reads simultaneously as light diffraction (the star as a radiant source) and a ticket perforation (the notch at the top edge of a stub).
The combined logo places the logogram left and logotype right, vertically centered.
The color system runs across four modes: Light, Dark and a high-contrast mode for each of them. The neutral palette spans from white (#FFFFFF) to black (#000000) through a standard gray scale, with semantic tokens for every elements (button fills, borders, text levels, inactive states…). Throughout the product, I use a palette of colors that cover the whole chromatic wheel. I use them scarcely, to highlight items or indicate meaning (danger, warning…)
Lumoria uses a dual-font system. EB Garamond Semibold is reserved for brand identity: the logotype, App Store headlines, splash screens, marketing. It never appears inside the product UI. All in-app typography uses SF Pro, with consistently negative letter-spacing across every style. The type scale maps directly to iOS system styles, ensuring full Dynamic Type compatibility without additional implementation work.
Working on this project alone made organization more important, not less. Without a system, every new screen would require rediscovering decisions already made. With it, I could build faster, more consistently, and adapt to constraints (visual or technical) without rebuilding from scratch.
Every screen in Lumoria is built from components. This approach means updating a button style propagates instantly across the entire app. It also makes the four-mode system visible: switching from Light to Dark mode shows immediately how every component responds. And in code, the component hierarchy in Figma maps directly to SwiftUI view hierarchies, eliminating translation work and keeping design and implementation in sync.
The system is token-based. Rather than hardcoding individual color values, everything resolves to a named semantic token that exists across all four color modes simultaneously. A primary button’s background isn’t #000000 in light mode it’s button/primary/background/default, which maps to #000000 in Light, inverts in Dark, and adjusts automatically for contrast requirements in HC Light and HC Dark.
Any screen built against the token system inherits correct behavior across all four modes without per-screen overrides. This makes designing a new screen or performing a modification in a component fast and reliable, something I absolutely need in a team-of-one.
The most consequential design system decision wasn’t about buttons or spacing — it was treating ticket templates as structured layouts rather than flat images. Each template type defines content zones (where the user’s data sits), cutout areas (the 7-point star perforation), and safe margins. When adding a new ticket type, the work isn’t “design a new template from scratch.” It’s “define the zones for this shape within the existing system.” This constraint forces consistency and makes it trivial to add varieties: plane tickets, train tickets, concert stubs, all use the same underlying structure.
I already have some tickets that are ready to be used in the beta, but more will come for the public release of the app. Creating tickets is the most time-consuming part of the process as each template needs to be different enough from one another to justify having different templates.
1 - Templates before data, not after
Showing templates first creates a specific risk: a user picks a template, then discovers it requires fields they don’t have (train number, gate, etc.). I mitigated this by surfacing required fields on each template card, the mismatch is discovered before commitment, not after. The alternative, data first, template second, felt less inspiring and killed the emotional hook at the start of the flow. Leading with a visual outcome creates commitment. Leading with a blank form does not.
2 - Collections as a first-class feature, not folders
The organizing unit had to carry the same emotional weight as the tickets. Folders are functional and neutral — they don’t suggest anything about what they contain. Collections are experiential. The early exploration tried a cork board metaphor — literal, warm, skeuomorphic. It worked conceptually but collided with the editorial identity direction that emerged during branding. The final design uses a card grid with stacked ticket previews: same underlying idea (depth, grouping, a trip as an object), executed without texture.
3 - Export
iOS has native subject-lifting that detects the ticket shape and strips the background automatically. However the quality of this feature remains unreliable for digital assets. It works well for pictures taken with the camera has the camera digitally maps the subject(s) and the background. This does not happen for the tickets created in the app. The way I mitigated this in the creation funnel is by allowing the user to export the ticket as a png with no background. That way, users can still import them in the app of their choice. Social apps most certainly have a “Cut out” or “Sticker” feature that allow the user to create stickers based on pictures. iOS apps can also have a sticker extension, that would transform pictures into stickers in the background and
Before moving into SwiftUI implementation, I conducted a usability test on the high-fidelity prototypes using Maze. This acted as a "control gate" to ensure that the core architecture, specifically the transition from a functional tool to an aesthetic memory, was intuitive.
Due to the constraints of the testing environment (8-block limit on the free plan), I strategically prioritized testing three foundational flows:
- Authentication The entry point of the app. - **Collection Creation **Testing the mental model, since research showed users struggle with organization, I needed to see if "Creating a Trip" felt like a natural first step before making a ticket. - **Ticket Creation **The core value, this tested the linear 6-step funnel against the user's desire for speed and "aesthetic-first" results.
The test is still running as I am writing these lines. The current direction seems that the prototype is easy to use, with an average usability score of 4.6 (5 meaning that the prototype felt natural and straightforward). The comments suggest that users were frustrated by the “rigid” test, they could not tap where they wanted and expect it to work. They went down a predefined path. Arguably, this is not the best user test I could possibly come up with, I just had to trade spending extra time on the user test vs. moving faster onto implementation, as I know that it will be a lengthy process.
This phase confirmed that the design was ready for build. A second, more rigorous control gate, the Beta test, is scheduled for May 2026 to test these flows under real-world conditions (actual travel, varying data quality, and export behavior). I will be updating this section with more data as the beta goes live.
The technology stack was chosen specifically to minimize friction between design and implementation. SwiftUI was the natural choice not just because of familiarity, but because its declarative model aligns seamlessly with a token-based design system. The component hierarchy built in Figma translates directly into a view hierarchy in code with minimal translation work, keeping design and implementation in sync without manual mapping or duplication.
Supabase handles the non-design layer: authentication and the database (user accounts, collections, ticket data). This keeps the implementation straightforward and lets the focus stay on the experience.
StoreKit powers the subscription layer with a critical decision about timing: entitlement state is checked not at launch, but at the moment a user hits a structural limit. This keeps the free experience fully uninterrupted until the product has made its case.
Amplitude tracks what matters at launch: activation (time from first open to first ticket created), engagement depth (funnel completion by step), distribution (export rate), and retention (7-day and 30-day). Event instrumentation is built into each step transition of the creation funnel, making drop-off visible at the individual step level rather than as an opaque aggregate.
Before a public App Store release, I’m running a closed beta through TestFlight with the full product available, all ticket types, collections, the premium upgrade flow. The goal is signal on the complete experience, not a trimmed-down build.
Access works through a simple subscribe-to-invite loop: interested users leave their email address, I send them a TestFlight link. This keeps the cohort intentional, people who opted in have enough curiosity to act, which means early data is cleaner than a broad public release would produce.
What I’ll be watching during beta