What she needed

• Search togetherAdd, share and manage listings in one place
• Skip the retypingPull listing details in, then sort and filter by them
• Know the commuteSee the trip to a potential office and the subway lines nearby
• See it two waysSwitch between a map and a grid
• Stay organizedFavorite listings, archive ones that left the market, and add notes and tags of our own
• Decide each weekRank her favorites in a "Wrapped" top four

I described the problem and the needs to Claude and built the app through conversation, testing each version against real listings and reporting what broke. A small Cloudflare Worker syncs our data behind a shared passphrase, so Abbie and I see the same listings on any device.

What the team needed

• A clear next stepSee which mechanics to ship, fix, convert or retire
• The reasonsRead the themes and notes behind each score
• Honest numbersSee where the data has gaps before acting on it
• A place to track itKeep status, owner and details for every mechanic afterward

Claude read the sheet through Google Drive and Sheets connectors. Over one long conversation I iterated with it to produce:

• A dashboard plotting every mechanic by average rating and share rate, with vote breakdowns, recurring note themes, and a filterable table with CSV export.
• A suggested next step for every mechanic, from written rules on score, share rate, template/original votes and notes: Ship, Ship after fixes, Make a template, Rebuild as original, Template or original, Rework, Archive.
• A shared content library of all 168 mechanics with status, owner and priority that the team can edit.

Braid is an open-source vocational storytelling community for students, faculty and practitioners, developed at the University of Michigan, sponsored by the Public Interest Technology University Network and led by Raymar Hampshire. Members share short stories about what they are feeling, thinking and doing in their work.

Braid has no likes, follows, trending topics or influencers. Members react by braiding: adding their own story to someone else’s. Its goals are to make storytelling more accessible, fun and joyful for people from all backgrounds, to strengthen learning and collaboration, and to build supportive vocational communities based on deeper human connection.

I started at Braid in January 2023 as a part-time product designer while I was in grad school. My focus was gamification, but the work has really been one journey with two threads: helping people form a community, and making storytelling feel easier and more joyful without turning it into a contest. After I graduated, I kept going as an advisor to Raymar.

“Braid Camp” started as the name for the onboarding curriculum I built. New members are not all there for the same reason, so instead of one course I wrote three trailheads, each a path into Braid that matches how someone wants to take part. It was the first step in forming a community: a way in that fits why someone came. Pick a trail on the map key to follow it.

Once people are in, the question is how to keep storytelling joyful. As a product designer and advisor to Braid, I explored gamification. The risk was obvious: points and rankings could turn a place for honest stories into a place for performing. So I set out what it should do, and what it should avoid.

What goes in the pack

What stays at the trailhead

Tap any card to flip it. Flip all

To test these ideas I built three small playable prototypes with Claude. They explore different answers to the same question: how can taking part feel rewarding without ranking anyone? They are prototypes in Braid’s look and feel, not live Braid features.

Shared progress without ranking

Braid Camp

Members add a Thinking, Feeling or Doing strand and it becomes a lantern, tent or garden bed in a shared camp. No leaderboards, likes or timers.

Play Braid Camp

Playing together, live

Strand Game Lab

A live ritual plus five cooperative games for one shared screen on Zoom or around a table, with a Book of Strands that keeps only what a group chooses to save. The idea is to use monthly Open Studios as a place to test them.

Open Strand Game Lab

Progress with no pressure

Strand Garden

Plant a small true thing from your work, then come back to water it and watch it grow from sprout to bud to bloom. Three kinds in a row grow a braided vine. Plants never wilt and there are no streaks.

Open Strand Garden

Since graduating I have kept advising Braid on two threads: building community and making storytelling joyful. Think of the ideas below as signs at a trail fork. Signs pointing left lead toward community, signs pointing right lead toward joy. Tap a sign to see where it leads.

This year I reworked Braid’s email layout with Raymar. The old template put black text over a dark blue and green braid background, so the words were hard to read, and the large braid in the middle pulled attention from the message.

• Readable firstDark text on a light background, with the braid faded behind it
• Braid as texture, not a billboardThe image starts partway down, fills the container and sits at low opacity
• Key ideas stand outColored callouts pull out the two core ideas and the closing line
• Easy to keep editingI built it as HTML with Claude, then pasted it into Gmail, where it can still be tweaked

Disasters change things. People who have prepared handle them better. Since 2006 Do1Thing has promoted preparedness with a simple idea: take one small step each month. That way getting ready never feels overwhelming. For years it shared that idea through fact sheets and calendars.

Those formats reach fewer people each year. Younger tech-savvy people expect information to come to them in an app. The project came to our capstone program from the City of Lansing’s emergency management office. The office wanted Do1Thing to reach more people in more ways.

At our January 31 kickoff we came with an agenda and 14 questions. They covered users and success. They also covered features and who would maintain the app. What we heard shaped the project.

Topic

What the client told us

Who it’s for

Individuals first. They wanted to attract younger people without losing older ones. They saw university students as a natural audience.

Success

Downloads and gamification metrics. They planned to use these in grant applications. Tracking usage had to be part of the plan from the start.

Engagement

Their paper calendar has one theme a month. It has check-ins on the 1st and 15th. They wanted people engaged more often. Daily or weekly would be ideal with reminders and tips. Our twelve modules follow the same themes.

Gamification

Central to the idea. They had no specific ideas for it. That left the design open for the research I did.

Accessibility

Required for people with hearing and vision impairments. They are more vulnerable in emergencies.

Maintenance

They would update the app themselves and had no one trained in app development. So it had to be easy to maintain and thoroughly documented. That became our technical guide.

Platform

The existing app only worked on iPhone. So Android became a priority.

Social features

They liked the idea but did not want to handle moderation and harassment. So social features stayed a stretch goal.

Style

They wanted a balance between serious and happy. They asked for teal and no standard font.

By the March midpoint presentation we had done four kinds of research. Each one changed what we built.

I scoped the project with the client. Then a team of six of us designed and built the app in React Native and Firebase. It has twelve short modules that follow Do1Thing’s preparedness themes. They run from making a plan to first aid. Each module has a checklist. Finishing one unlocks a badge that is saved to your account in Firebase. The app remembers where you left off. It also has a water calculator and lets you sign in or continue as a guest. Screen-reader labels and image descriptions were built in.

We also built a web dashboard for the people running Do1Thing, so they can see how the app is being used and download the data.

I led the gamification research and design. I also mocked up the database and built the home and profile screens and the badge experience in the app. A teammate designed the look of the app and the prototype in Figma. We used Trello to track the work and React Native and Firebase to build.

1. 1

   Learn

   Research

   I studied how gamification works and compared four products in the table below. I also pulled out four kinds of players and ten common techniques to choose from.

   CompetitorsAchieversSocializersExplorers

   	Apple Fitness	Duolingo	Kahoot	Freerice
   Background
   Goal	Motivate people to exercise	Help users learn new languages	Help students learn and retain information in the classroom	Donate rice to people in need through trivia questions
   Target user	Fitness-interested adults	Adults and children interested in languages	Educators and K-12 students	K-12 students
   Users	Unknown	9.1 million DAU (2023)	70 million MAU (2018)	8 million annual users (2022)
   Features
   Goal Setting	Yes	Yes	No	No
   Levels	No	Yes	No	Yes
   Badges	Yes	Yes	No	No
   Points	No	Yes	Yes	Yes
   Leaderboard	Yes	Yes	Yes	No
   Competition	Yes	Yes	Yes	No
   Challenges	Yes	No	No	No
   Exclusive features	No	No	No	No

   Four products I compared. Green means the product has the feature.

2. 2

   Decide

   Two ideas

   Idea 1

   Storytelling and simulations

   A themed disaster scenario each month. Players are immersed in it and make decisions as challenges come up. They earn points based on how they do.

   Idea 2 · the one we built on

   Task-based achievements

   Badges for finishing real preparedness tasks. A performance graph shows progress over time and other users can see it. Reminders nudge people to finish tasks.

   We built on the second. It fit what Do1Thing already had: a calendar of small monthly tasks. It also fit the reminders the client wanted.

3. 3

   Plan

   The tasks

   Do1Thing’s program has three small tasks a month. That makes 36 across the year. I turned that calendar into the game’s tasks. Here are a few of them.

   JanuaryFind out what kinds of disasters can happen where you live

   FebruaryBuy 3 days of water at the store

   JuneMake a plan to take care of your pets in an emergency

   AugustVisit a neighbor who doesn’t get out very much

   OctoberHave flashlights and extra batteries for a power outage

   DecemberTake first aid or CPR training
4. 4

   Design

   Badges

   I designed 13 badges. One is for creating an account and one is for making a plan. The other eleven match Do1Thing’s themes. Each badge names what you did. The water badge says “Secured 3 days of water.” In the app the badges follow the twelve modules. The artwork uses open-source icons.

   

   

   

   

   

   

   

   

   

   

   

   

5. 5

   Designed, then deferred

   Points and levels

   I also designed five levels. The design included streaks and points and a leaderboard among people at your level. It also had stats on your profile. Adding friends was a stretch goal. We built the badges first and left these for later.

6. 6

   Build

   Building it

   I built the home screen. It has a module grid and the current month’s task and the Do1Thing logo. I also built the profile screen. Earned badges show in color and the rest show as locked. I built the pop-up that celebrates a new badge. I also styled guest mode.

7. 7

   Structure

   Database

   I mocked up the database schema. It covers users and badges and progress through each module and notification tokens. Along the way the design notes answered four questions.

   • Do we save a person’s place in a module? Yes. The app needs to know how many pages each module has.
   • Do we send notifications? Yes.
   • Where do the badge designs live? In the app’s code. Only the badges each person has earned are saved.
   • Do we need profile photos? No. Skipping them meant we did not have to store images in Firebase.
8. 8

   Organize

   Content inventory

   I made the content management spreadsheet. It lists all 31 fonts and icons and images in the app. For each one it records the file name and the screens that use it. It also records the name the code uses where there was one. That way the team could find every asset.

We worked in sprints with a six-person team and the retros show how the team changed the way it worked.

1. Sprint 0Jan 31 to Feb 14Jan 31: client kickoff
2. Sprint 1Feb 14 to Mar 7Team rating 7 to 8 out of 10
3. Sprint 2Mar 7 to Mar 28Mar 14: midpoint presentationRated 7. 163 points planned and 86.5% done.
4. Sprint 3Mar 28 to Apr 11117 points planned
5. Final sprintApr 11 to Apr 20Apr 17: ExpositionApr 18: final presentationApr 20: handoffRated 9. 109 of 120 points done (90.8%).

At the midpoint we named our own problems.

• Keeping track of everything we had asked the client for and agreed to.
• Talking more when one person’s task depended on another’s.
• Getting every task into the backlog before sprint planning.
• Keeping design and building in step as screens were finished.

How the retros helped

Preparedness information matters most for the people who have the hardest time getting it. So we spoke with blind and Deaf users while we worked. Two things came out of those conversations. Many Deaf people use English as a second language. A written fact sheet can be hard to follow and sign language versions would help. Several people also told us to talk to the DeafBlind community directly. Their needs would be different again.

On the build side an early demo showed how to do accessibility in React Native. We also wrote guidelines for the team to follow. By the final presentation the accessibility features were about 90% done. Finishing them across the modules was the first item left in the backlog.

A student project ends. So the handoff mattered as much as the build. We wrote a technical guide. It covers how to get the code and build the iOS and Android versions. It also covers how to host the analytics dashboard. In April 2023 I also wrote recommendations for what to do next.

We showed the project at the U-M School of Information Project Exposition, where it took first prize in the Community/Civic Engagement category. The six of us on the team are named in the school’s announcement of the 2023 award recipients. This is the poster we presented.

At the final presentation on April 18 we described the app as about 80% functionally complete. The plan was to reach 100% by the handoff.

The app was handed to Do1Thing as working code with a guide to release it. As far as I can tell the organization never published it. The last blocked cards on our board were hosting the app on Google Play and a meeting about the Apple Developer account. Those are the steps between a working build and a public release. We had prepared beta builds for both iOS and Android. So this project won a prize and delivered working code. It stops short of a public launch. What I took from it is how much a handoff decides whether good work gets used.

Our core audience is Gen Z and young millennials, roughly 18 to 30, who already make things online: memes, short videos, fan art, small games. Alongside them are people who mostly browse and play, and who might start creating once remixing feels easy. I ran the research to understand what they need, from writing the scripts and recruiting people to sitting in on the sessions and pulling out the themes.

We ran 17 interviews and playtests across those three phases. From the interviews I built four personas and used them to check each feature against real people.

Jordan

@jordan.makes

The Collaborative Builder

25 · Brooklyn, NY · Graphic designer

Thrives on collaboration and creative exchange. Sees the internet as a place to build things together, not just consume, and misses the playful, communal feel of early online spaces.

• Co-creation
• Remixing
• Groups and clubs

• Remixes mini-games with friends: “our inside joke turned into a game”
• Hosts small challenges, like “let’s all make something around this trend”
• Loves watching others build on what they made

Needs from Variant: Co-creation tools and social feedback loops.

“I love when my friends add to what I made.”

Maya

@maya.slowly

The Aesthetic Curator

28 · Seattle, WA · UX researcher

Intentional about her digital life. Values authenticity, thoughtful design and self-expression, and is tired of algorithmic clutter and performance culture.

• Discovery
• Slow creativity
• Reflection

• Browses like an interactive magazine, curating story-driven and idea-based games
• Uses prompts and gentle creative modes to express herself without pressure
• Saves creations that resonate emotionally, and engages more with discussion than competition

Needs from Variant: A calm, genuine space where creativity feels intimate.

“It feels more like creating art than chasing likes.”

Theo

@theo.tinkers

The Reflective Creator

30 · Austin, TX · Marketing manager

Curious about technology but wary of over-automation. Values transparency, privacy and control over how AI supports his process.

• Privacy
• Easy templates
• Light AI

• Turns ideas into playable sketches quickly, with light AI help
• Starts from easy templates, like “make a cozy cat game”
• Switches off heavy AI features for manual tweaks or partial help

Needs from Variant: Control and transparency, with strong moderation and privacy.

“I didn’t think I could make something this cool.”

Serena

@serena.plays

The Viral Trendsetter

22 · Los Angeles, CA · College student

Loves sharing things that make people smile. Hops between TikTok, games and memes chasing humor, energy and quick connection, and drops off fast if things get boring or over-monetized.

• Humor
• Short bursts
• Leaderboards

• Plays trending, funny community games in short bursts
• Shares meme-based games with friends by DM and in stories
• Drops into events and leaderboards for fun, and loves a quick “try again” loop

Needs from Variant: Instant fun, with as little friction as possible.

“These games are hilarious and quick.”

Personas are composites built from our interviews. Photos are stock images.

What they needed from us

After tonik handed off the first screens, I took over the product design. I made the creation flow more structured, took out the conversational mode, and added templates for people who just wanted to swap faces. Templates became the default.

Before: choose a style, then talk it out

←→

After: pick a format, templates first

What changed and why

Smaller additions

The new flow, by format

GameTemplateStory

←→

• A crowded fieldA lot of teams were chasing the same idea, so we had to be clear about what made Variant different.
• The role of AIWe spent a lot of time on how much AI should do for a creator and how much to leave to them. Our research kept pointing to AI as a tool that serves the creator’s vision, not a replacement for it.
• Compute costGenerating games, stories and faces costs real money, so we were always balancing quality, speed and cost.
• Working across time zonesA remote team spread across time zones meant being deliberate about communication, standups and handoffs.

Variant taught me what it takes to build a product from nothing, and a few things I would do differently with a second try.

I designed this research approach and ran it with five groups of outside players. The roadmap changes that came out of it led to a 28% lift in D1 retention.

• Starting from scratchWe were separate from the other Sims studios, so we couldn’t borrow their work. Create-A-Sim, decorate mode and more all had to be built from the ground up.
• A 3D game on modest phonesFitting a beautiful 3D game into the performance and storage limits of lower-end phones was a real challenge, especially in the Philippines.
• Deciding without our own dataBecause this was a brand new product, we had no data of our own to lean on, so we looked to competitors and the wider market. Some decisions came down to gut instinct, which made qualitative research like playtests and diary studies matter even more.

The game was canceled in early 2026. Looking back, two things taught me the most: why the product struggled, and why Create-A-Sim ran late.

About Create-A-Sim, in order

1. Start

   A spec is not shared understanding

   I wrote a very detailed spec (30+ pages!) and a detailed content plan, and we held a kickoff. Unfortunately, I discovered that not everyone had read it very closely.

   Next time: Check early that each team has worked through its part and left feedback and comments on the spec, so we can spend kickoff on the questions that need more clarification.

2. During development

   Name dependencies early

   Tech art and engineering each thought certain tasks belonged to the other, and some dependencies only came up late. To get everyone on the same page, I started a daily standup for the feature so we could all see what everyone else was working on. It brought a lot more transparency into the work.

   Next time: Start the standup on day one, map dependencies at kickoff, and give every handoff a single owner.

3. Deadline

   Watch the estimates

   The estimates kept slipping, and in the end we had to push the feature’s deadline back by about a month.

   Next time: Track how estimates are drifting every week, so a slip shows up early instead of at the deadline.

4. Release

   Cut on purpose

   Even with the extra month, we still had to cut some things that should have made it in, and the release went out with more bugs than I would have liked.

   Next time: Decide what to cut early and on purpose, instead of late and under pressure.

Footage from our Android market tests in Australia and the Philippines, recorded by a player (buzzrot on YouTube). Game footage © Electronic Arts.

This game is about how misinformation, deliberate and accidental, shapes the way we understand history. At its heart is one question: what happened on the night of March 5, 1770? Carleton professors Austin Mason and Serena Zabin created it, and students in their Fall 2019 course, The Boston Massacre in 3D: Mapping, Modeling and Serious Gaming, helped build it. I was one of them. Players piece together testimonies ahead of the soldiers’ trial, then decide whether to support the prosecution or the defense. The team has stopped developing the game, and its site keeps the work available.

How the game plays

• Find the witnessPlayers look for Jane Crothers, a barmaid who saw the shooting
• Examine the evidenceThey study Paul Revere’s print “The Bloody Massacre” under a magnifying glass
• Weigh what people sayResidents tell their stories, and some share playable flashbacks. Players decide how far to trust them
• Write a letter homeThey explain their own interpretation of the evidence

Area

What I did

Research and mockup

Looked at how other video games design their maps, then mocked up ours and chose the icons and fonts.

Map interface

Designed how the map looks, from the typography to the icons and legend, and built it in Unity. Players can resize it and switch layers and icons on and off.

Interaction

Made the icons clickable, with a banner that names each person on hover. Wrote the script that shows and hides icons from the legend, and connected the journal to the map so players can move between them.

Museum partner

Designed to be installed in the Old State House Museum in Boston.

The tour follows African-American life in Westfield from the colonial era of enslavement through Reconstruction, Jim Crow and the civil rights era. Along the way you pass burial grounds, churches, a funeral home, a community center, and the former homes of Zora Neale Hurston and Langston Hughes. A companion timeline puts national events next to local ones. The Westfield 300 committee published it as a booklet and as an online tour.

Area

What I did

Online tour

Researched, designed and launched the tour as an online exhibit on Clio.

Research

Researched the town’s history as a student historian on the committee.

Timeline

Chaired the research and production of the companion timeline.

Oral history

For the Westfield Historical Society, collected oral history interviews and digital media about how the town was living through COVID-19.

Internship program

Founded and directed a summer program where I mentored six high school students in historical research and digital storytelling.

Centering Spenser is led by Professor Thomas Herron of East Carolina University, and his team at the university’s Multimedia Center built the castle model. The project asks how Spenser’s role as a colonial settler in Ireland shaped his writing. In Fall 2020 I took Ireland: Land, Conflict, and Memory at Carleton. Its professor, Susannah Ottaway, is one of the project’s main collaborators, and she invited her students to suggest additions to the model and give honest feedback. The project later received an NEH grant to grow.

Area

What I did

Scavenger hunt

With three other students, designed a digital scavenger hunt based on Spenser’s A View of the Present State of Ireland. It sends players to objects around the castle to learn about his role as a colonizer, and we built it entirely from objects already in the model.

Timeline

As a research assistant, created an interactive timeline of Spenser’s life for the project website. I drew on what I learned in Professor Ottaway’s class on early modern Irish history, plus my own research on Spenser, to show how his life connected to the events and culture of his time.

Writing

Wrote the Carleton ITS blog post about the class project.

This work left me with questions I still ask in product work: who is this for, how do you stay accurate and still make it easy to approach, and how do you keep something fun while it teaches.