To understand the problem space, I ran a competitive audit of three major museum apps — Walt Disney Family Museum, Art Institute of Chicago, and St. Louis Public Library — and conducted interviews with 5 participants aged 19–60, who shared their experiences with art galleries and audio tours.

Three things stood out from the research: audio tour apps consistently lacked accessibility features like subtitles and translation; virtual tours were being used as a substitute for in-person visits, not just a supplement; and there was no universal app that worked across galleries worldwide — every venue had its own.

Non-native English speakers mentioned that they often had trouble fully comprehending the meaning of the installment even with a tour guide or audio tour.

Those who often visit the galleries use the virtual experience as a substitution of the physical experience. It helps them decide if the current exhibition is interesting for them to go see it in-person.

Two findings from the interviews stood out above everything else. Non-native English speakers described feeling locked out of the full experience even with an audio tour available. And frequent gallery-goers were using virtual experiences not as a supplement, but as a decision-making tool — to decide whether an exhibition was worth seeing in person. Neither use case was being served well by any existing app.

The research revealed two distinct use cases that needed their own flows — a user experiencing a gallery in person, and a user seeking a remote virtual experience. I mapped both before touching any wireframes to make sure the information architecture served each scenario without forcing either user into an awkward path.

After mapping the flows, I moved into paper wireframes first to work through layout and hierarchy quickly before committing to digital. Once the structure felt right, I moved into lo-fi digital wireframes and built a testable prototype.

I ran two rounds of usability testing — once on the lo-fi prototype and once on the hi-fi prototype. Participants were asked to complete the two core flows (in-person and virtual) in an unmoderated environment. The lo-fi round confirmed the overall flow worked without major issues. The hi-fi round surfaced two specific problems worth acting on:

Before building hi-fi screens, I defined a UI foundation — color tokens, typography scale, button states, a media player component, and navigation patterns. Establishing this upfront meant every screen stayed consistent without having to make the same decisions twice. It also made the prototype significantly faster to build.

Designing Artour solo meant I had to hold the full picture at every stage. That constraint made me more rigorous — when you're both the researcher and the designer, you develop a stronger instinct for which insights are actually actionable and which are interesting but irrelevant. The biggest shift in my thinking came from the accessibility research. I went in expecting accessibility to be a feature layer added on top of a finished experience. What the interviews revealed was the opposite: the users who needed accessibility features most weren't a niche edge case. Non-native speakers, older visitors, people in noisy or crowded environments — designing for them improved the experience for everyone.

1. Research how AR features could enhance the virtual tour experience
2. Conduct further usability studies to validate the iterated solutions
3. Run a dedicated research round with non-native English speaking participants — my testing pool skewed toward fluent English speakers, which means the translation feature I'm most proud of is also the one with the least direct validation. That's the honest gap, and it's where I'd invest the next round of research.

If Artour were to launch, I'd track: translation feature usage by language, closed caption engagement and font size data, usability error rates across key flows, and virtual tour engagement compared to in-person usage — the last one would help validate whether the virtual experience is genuinely serving the remote-first use case the research identified.