Amuse Consumer App

When I joined Amuse, the app existed, but barely. There was no visual brand, no component library, no documented interaction patterns. Screens had been built feature-by-feature without a coherent system underneath them. My first task was to figure out what Amuse should look and feel like before we could build anything worth keeping.

From the start, my Product Lead and I made talking to real users a priority. We ran structured interviews and recruited strangers for guerrilla testing sessions, watching real people interact with early builds, asking what they were looking for, and listening for the gaps between what they said and what they did. That combination of direct feedback and competitive analysis gave us a clear north star: people didn't want another information app. They wanted to feel the excitement of discovery.

With that philosophy in place, I ran a moodboarding exercise with the team: three distinct visual directions, each with its own personality, to force an honest conversation about what Amuse should feel like before anyone touched Figma.

Direction locked, I moved fast: rough screens, quick concept tests, throwing ideas at the wall before committing to anything. The goal was to get a feel for how the visual language translated into actual product surfaces.

Before I could design features, I needed a foundation. I built Amuse's design system from scratch, defining the color language (a deep dark base with the signature teal #5BF5FF accent), accessible typography using Outfit across all weights, a complete icon set, and a component library that could scale with a fast-moving startup.

The system was built in Figma with engineering handoff in mind: every component documented with states, variants, and usage notes. This became the shared language between design and engineering, cutting spec friction significantly.

The story player is the core of the Amuse experience, the screen users spend most of their time in. I designed it as an evolving system rather than a fixed screen, starting with Fun Facts and Video stories and expanding over time as we discovered new user needs and partner requirements.

Each story type presented its own design challenge: Trivia needed clear right/wrong feedback states that felt rewarding, not punitive. Audio stories needed a player interface that worked without visual content. Spotlights needed to annotate dense exhibit imagery with hotspots. The gesture model (swipe up/down for next story set, tap for next story, long press to reveal background) had to be learnable without a tutorial.

Audio Description started as a widget tucked inside the info card, an easy workaround, but the wrong answer. It separated AD content from the core experience rather than making it part of it. We moved it into the story player itself so that visually impaired users would experience the same flow as everyone else, just with narrated descriptions instead of visual content.

Once we recognized the real user need, we went to the source. My Product Lead ran structured interviews with visually impaired users, not hypotheticals, but real people navigating the real app, and gathered direct feedback on what worked and what didn't. We took that input and built proper spec around it: a dedicated AD story type, an AD badge for easy identification, narration controls, and a Settings toggle that lets users prioritize AD content in their feed so it surfaces first.

Beyond Audio Description, I kept accessibility as a standing constraint throughout the whole product. The app was audited by an accessibility specialist, and I consistently maintained WCAG-aligned contrast ratios, ensured all text was scalable without breaking layouts, and kept tap targets and interactions straightforward enough to work without fine motor precision.

Once the foundation was in place, the work shifted from building everything from scratch to shaping what came next. With a real user base and product data to pull from, the questions got more interesting and so did the process.

Research became a consistent part of the rhythm. My product lead ran a steady program of user sessions: in-person walkalong sessions at partner museum sites, remote interviews, competitor analysis, and focus groups. I was brought in throughout as the design voice, helping translate what we heard into real product direction. That often meant working through the problem space together before anyone touched Figma: a shared FigJam board covered in sticky notes, a collaborative doc mapping out priorities, or a longer structured workshop with the wider team during one of our in-person meetups.

Having a product lead who took research seriously made a real difference. Decisions were grounded in actual behavior, not assumptions. My role was to show up with an opinion, push back when something didn't hold up visually or interactively, and make sure the design perspective was present from the earliest stage of any initiative.

Not everything shipped. Some of the most valuable design work I did at Amuse was recognizing when to stop. A few experiments that didn't survive:

Amuse shipped. Real people use it in real museums. We onboarded cultural institution partners including the Yale Peabody Museum, running user tests on-site and iterating the product based on how actual visitors moved through the space. The design system I built has scaled through multiple major feature launches without needing a full rebuild.

Three years as the sole designer at an early-stage startup taught me things that no amount of senior roles at larger companies could have: how to make consequential decisions with incomplete information, how to advocate for design quality when speed is the priority, and how to tell the difference between a feature worth building and one worth killing. Beyond product, the role stretched into museum signage, QR code displays, and marketing design across social, print, and web, the full range of what being a solo designer at a startup actually means.