Wedding Hunt
A digital game experience that help guests feel welcomed and connected while in town for the wedding
Project Type
Designing a location-based game - CareerFoundry Bootcamp
My Role
Product designer, UX designer
Skills Developed
Location-Based app design
Style Guide / Design System development
Axure - Complex prototyping
Adobe XD - Visual design
Long-form Case Study writing
SUMMARY
Couples about to be married face many challenges. They must make many decisions about the wedding experience and are often financially and relationally stressed. And guests from out-of-town can feel nervous, wondering if they'll know anyone, or if they'll even get a moment with the future spouses. I designed a "social" scavenger-hunt game to help guests feel welcomed and invited into the celebration.
Things I didn't know before this project:
-
Importance of "Vuja de" (opposite of deja vu)
-
Identifying Assumptions: projecting my needs onto others
-
Keeping a "decision journal" actually SAVES time
-
Identifying (and overcoming) my design process challenges
-
The importance of "User-Testing" a User Test
-
Pro/Cons of Axure RP and Adobe XD
THE ASK
Design a social scavenger hunt game for real objects and locations in an area
As I reviewed the options for my main course project, when I saw "design a city exploring scavenger hunt game" I was thrilled! As a kid I loved playing outdoor games like Kick-the-can or Hide-and-seek. Something about having other people seek me out resonates with my soul. I was all in.
The project brief listed the objective (in bold, above) and a number of design constraints, so I used a UX Design Requirement gathering process. Here was my current understanding of the problem:
The Problem:
People new to a city need an area-exploring game because they want to have fun learning about their city while meeting people.
DISCOVERY
Learning about the location-based game space
Before I could brainstorm possible solutions, I needed to learn more about existing products and users. I started by Googling "scavenger hunt" which lead me to various downloadable scavenger hunts and a few online scavenger hunt building platforms. Some clicking around led me to the term "location-based game", which led to "Geocaching" and "Pokemon Go!".
There appeared to be a pretty massive appetite for games like this, with Geocaching.com stating that to date, over 3 million geocaches have been hidden in 191 countries, and each one is found about 25 times a year. This is certain: there are a lot of folks out there hunting for these things.
There are roughly 75 million geocache "finds" every year.
Ideating a Solution
After looking at a number of games in the location-based game space, I imaged gaming scenarios that would solve the problem statement. After discussing my ideas with my coach, Tasha, we decided I should move forward with my Fox and Hound idea:
Fox and Hound:
A city-exploring game where a fox sets the path, leaving behind clues and riddles for hounds to solve to stay on the path.
OK, so my proposed game sounded fun to me, but what makes up a successful solution in this space? And what might drive someone to make a game for other people?
Finding the key ingredients of successful location-based games
Examining Existing Solutions
Digging deeper, I did a full Marketing and UX analysis of 2 companies I came across during my googling: an online Scavenger hunt platform called Goosechase.com and the eponymous Geocaching.com.
.jpg)
.jpg)
Support the needs of game builders AND game players
The analysis (and 15 page report!) took considerable time and effort, but proved a great value. It helped clarify what groups of users these products supported, and how their needs changed over time.
Successful location-based games support the needs of builders and players, and support them before, during, and after a game session.
Requirements -> Needs -> Stories
The project brief listed a number of required aspects that I my solution would need to have, for example, a game list page that shows current games in users’ areas, games they’re invited to, and allows users to create new games. Transfering that into user stories forced me to account for the different types of game sessions my platform would support and to start to consider the different ways user might want to engage a game session:
Game scenarios:
-
scheduled or play-anytime
-
public or private
-
played individually or with a group
USER RESEARCH
Listening and learning from actual game builders and players
Learning Goals
Players:
What aspects draw people to location-based games?
How and where do they like to play them?
Builders:
What motivates game builders?
What is fun or frustrating about building a game?
Surveys and Interviews
The "games" survey I made with Google Forms
Analyzing hours of interview recordings
Research Findings
The numbers:
-
players are common
-
builders are rare
Players most liked:
-
playing games with other people
-
being able to get outdoors
Builders were motivated by:
-
other people's enjoyment of the game
-
their own enjoyment of the game
Builders were frustrated by:
-
how long it takes
-
not having a template to start from
-
anxiety from the process of running a game for other people
"I couldn't find the exact game I wanted, so I built it myself."
- Game Builder
REFINING THE PROBLEM
Designing for a specific use case: Weddings
During a chat with my project Mentor, Kay reiterated the benefits of designing for a specific situation, for a specific purpose. As we imagined different situations and reasons people would build a scavenger hunt game, Kay said "I see people making a game for their wedding guests to play." We both loved the idea!
Validating The "Wedding Hunt" Idea
I needed to validate this idea with prospective users, and as luck would have it, I noticed my 4 neighbors, all twenty-something, two of whom had just gotten married last month sitting outside chatting - time for some guerilla testing! I walked down and described the wedding scavenger hunt idea. Before I could ask, my neighbor said, "I totally would have used it at my wedding."
"If this game had been available, I totally would have used it at my wedding."
- My Neighbor
Others nodded approvingly. That was proof enough for me. I ran back upstairs and updated the problem statement.
The Wedding Problem:
Wedding Couples need a way for guests to feel invited and connected - with other guests, to their wedding story, and to the town they are visiting so that they feel, and become, part of the celebration.
Research Redo?
Now that the problem and solution had been re-focused, I wondered if my discovery work was still relevant. I believe UX deliverables (personas, problem statements, etc.) are valuable to the degree that they keep the needs of our users in focus while moving us from conceptual idea to tangible solution.
So who were the core users and early adopters my product would support? People who love games and happened to be getting married soon! My game building research was still directly applicable, and while further research on the wedding component was needed, it would compliment my current understanding, not replace it.
THE USERS
Meet the builder: "Best Man" Mike
I had already made 2 personas, Andrea the player and Mike the builder. So I imagined what it would be like if two game players got married. It was easy to imagine that "Future Spouse Andrea" would want the same fun, inclusive, social experience for her wedding guests.
And it not a stretch that the "Best Man Mike" would offer to make a game for the wedding. A wedding-focused, scavenger hunt game could solve their problem!
Personas: "Future Spouses" and "Best Man"
P.S.
I want to give a big shout out to the team at Equallywed.com! I totally appreciate your curated list of more inclusive, less hetero-normative wedding terms like "future spouse" and "wedding suite". With better language comes better understanding, so thank you for resourcing me with a little of both :)
REFINING THE SOLUTION
A beast: The Wedding Hunt sitemap
A developer I worked with once said "Building a thing is easy. Building a thing that lets other people build a thing is hard." As I worked on task flows and a site map, I started to realize what he meant by that. The Wedding Hunt Site Map would have 3 distinct areas: a Marketing area, a Builder area, and a Player area:
Organizing and Refining with Card Sorts
To help builders and players efficiently complete tasks, I did 2 open card sort activities using Optimal Workshop. After listing all the tasks each group would be doing, I uploaded them, and 5 testers grouped them as they saw fit.
For the builders, the suggested groups were: Review, Watch, Build, Invite. I added pages and structure suggested by the sort:
Interestingly, the suggested groupings also reflected the chronological nature of this process: first making a game, then inviting the players, then holding the event, then seeing the results. It made sense that to me to introduce the chronological aspect into onboarding, navigation structures etc. and to keep users informed what stage they are at in the overall process.
PERSONAL GROWTH
Overcoming my struggles
Learning to Sketch like Nobody's watchin'
For me, one of the most challenging points of this bootcamp was when I starting sketching out ideas. Having grown up in a very judgemental environment, I learned to be hypervigilant about what other people thought about me and my actions. As an adult, I've learned to recognize my value (therapists are the real deal, can I get an Amen!?) but as I started to sketch, I often froze, insecure about what I was drawing, worried about what people would think about them, what they would think about me. I second-guessed signing up for this bootcamp.
Finding Resources
I might never have finished this project if it weren't for the supportive people and resources around me: my wife and family with their positivity and undying support, my CareerFoundry coach Tasha with her encouragement and helpful critiques, and folks like Tom and David Kelley, creating resources like Creative Confidence, y'all helped to normalize what I was feeling and encouraged me to keep following my passion.
The Kelleys' gook is one of many great resources for "feeling fake" newbies like me.
Teasing Ideas onto Paper: Crazy 8's Technique
A technique I found quite helpful was "Crazy 8s", which forced me to draw out 8 solution ideas in 8 minutes. I found myself playing with ideas visually on paper - I simply didn't have time to second guess myself!
For instance, I wanted the Couple's Homepage to be a central hub, to help the Future Couple understand and manage the game process. Crazy 8's helped me generate the Info Panel design to present info and options in an actionable AND situationally adaptive way:
PROTOTYPING
Navigating from concept to concrete
When planning out any app, there are a number of different user flows that need to be supported, and the Wedding Hunt app was no exception. But to highlight my process of moving from sketches to hi-fidelity prototypes, let's follow one flow: Adding a question/activity to the Wedding Hunt.
Speeding up the Build: Customizable Templates
Best Man Mike hated how long it took to make a game, and it can be much easier to start with a template, then customize it to your needs. So I guessed he'd appreciate a "Question Library", a repository of customizable question and activity templates can be easily added to a game. But how would that process work?
First, I diagramed the flow, which listed the screens I'd need to make:
Then I used Crazy 8's to generate ideas for individual screens:
Then linked screens together in a paper prototype:
From Paper to Adobe XD
After researching digital design tools, Adobe's XD seemed like a good choice: I could create everything from lo-fi wireframes to clickable hi-fi prototypes.
Low-fidelity wireframe of Question Library made with Adobe XD
Learning Curve: XD's Artboard
My expectation was that I could make a prototype with XD that would function just like the app would. For instance, when the game-builder chooses an activity from the "Library" and adds it to the game, that activity card should now be displayed in the "Our Game" area. I created 2 artboards to display the change:
To create a clickable prototype of just the "add a mission" process, I had to make 14 artboards. This seemed like a lot of work, but copy/paste made it pretty quick, so boom, I had prototyped my first process with XD.
USABILITY TESTING
Uncovering Problems
To gain experience with a formal Usability Study process, and to get some early-stage user feedback on my prototype, I conducted a 5-participant usability study on 3 flows I had prototyped. Because of the Sars-CoV-2 pandemic, the study was conducted remotely using Zoom.
Users Were Confused
The testers seemed excited about the idea of the Wedding Hunt App, and the study successfully exposed a number of usability problems with the prototypes. However, as I re-watched the recordings of the test sessions, I noticed that every participant showed some confusion during the tests; some were confused often.
Testers were MOST confused by:
-
Components with filler content
-
Builder and Player tasks in same session
I needed to:
-
add real content into the activity cards
-
improve the onboarding process
-
repeat the study
Participants just didn't have the same understanding I did about my prototype. It's obvious (now) that my test participants needed more visual and contextual cues to help them understand what they were looking at.
What the participants saw
What I thought they saw
At the time of my usability study, I hadn't yet written out actual Wedding Hunt missions. The prototype's mission library didn't have completed "mission cards", just filler "ipsum lorem" cards. This was fine for me, as I was literally dreaming about this project. But testers had no idea what those little blue lines were supposed to be. It was a painful lesson.
Creating Shared Understanding
Before rerunning the test, I wrote out example missions and created onboarding sequences for each role.
Before
After
Builder Role Onboarding
PROTYPING PIVOTS
Pros/Cons of Adobe XD
Adobe XD Pro: Visual Design
Up to this point, I was focusing on how to make the builder side of the prototype work the way I wanted. But it's got to be pretty too, right? With zero background in graphic design, I realized I had been avoiding that whole aspect of the design. My screens weren't in the least part "wedding-y". I googled around for inspiration and found some pics from Mandy Moore's wedding:
The colors felt beautiful, elegant - exactly what I wanted for the app.
I wondered what my prototype might look like if I pulled actual colors from this photo, and injected them into my prototype?
+
=
Adobe XD really made this process easy, and I loved the result. I showed it to the team and got positive feedback. (Thanks, Mandy, much appreciated!) Also, these images proved to be quite portable, and I was able to easily download or port them into other tools.
I got really into it at this point, using Frontify to create a Style Guide and Design System with a section dedicated to visual imagery:
Adobe XD Con: Programing Interactivity
Here is the rub with prototyping in XD: each additional layer of prototype complexity increases the needed artboards exponentially.
For example, for the Version 2 prototype above, where a tester can add 1 of 3 possible missions to the game, I had to make create 23 artboards and 57 interactions:
Axure to the rescue
Finding an Easier Way
I needed a better way to create a complex prototype; some googling showed how users had used XD's Component State feature, but I couldn't find a way to have a click on one artboard affect a change on a different artboard.
So I googled "complex prototyping tool" and found Axure. The feature set seemed perfect for what I needed!
Axure Prototypes:
-
have pages with functioning components, not visual facades
-
can store user data, any page can access
-
respond dynamically and conditionally to user action or events
Focusing on the Player
As I played around with Axure, I realized I might be able to build an actual functioning version of this game where players could answer questions, score points, maybe even submit photos and complete missions! If Axure could help me create a joyful prototype experience, I could do much more realistic user testing, as well as communicate the true benefit of the app in a powerful and accessible way.
I shifted my focus on the building out the player side of the prototype, and as I created screens and features, its personality began to emerge. The "player onboarding" screens let guests know what to expect:
Players could actually play the game. They can choose and complete missions, even see their score increase as they play!
Is I added in content simulating other users' posts and comments. Prototype testers can browse the recent activity, even see their posts show up there as after they complete each "mission".
Try it out!
Imagine you just arrived in White Bear Lake MN, the day before Tim and Andrea's wedding...
Click here and join the Wedding Hunt!
-PB
LOOKING BACK
Reflections
User Testing Never Stops
Since building the player side of the game, I've user-tested it formally and informally, almost continually. The AxShare mobile app let's me try the newest versions right on my phone - being able to put a prototype in someone's hand is priceless.
My sons, my wife, my neighbors have all tried it out, and being able to watch their faces as they play is incredibly informative; a smile, or a wrinkled brow is a gift, an opportunity for me to ask what they are seeing, what they are feeling at a specific point.
Embrace Ambiguity
As I was taught different aspects of design while working on this project, I'd find myself totally immersed in one aspect of design at a time, perhaps product architecture and structure, or visual design and feel. I often felt idealistic and at odds with my decisions from the past week.
I've grown in my ability to hold differences; different goals, different opinions, different perspectives; simply allow them to exist.
Little Steps Build Momentum
The longer I used a prototyping tool or process, momentum built up. My productivity increased as my effort decreased. For instance, from the start of the project, it was 3 months before I had the first version of the digital prototype.
Near the end of the project, I tested multiple versions daily. Users could see and feel what it's like to actually use the thing - in my humble opinion, it finally feel like a real thing.
As I stopped worrying about how to build something, I was free to imagine what might be possible; I experimented with adding elements of surprise like "celebration pop-ups". I still giggle when remembering my son, playing this new version in the back seat as I drove him to school, shouting, "I made the leaderboard!"
Adding in Some Delight
LOOKING FORWARD
What's Next?
Get out of the office
As I reflected on the project, it occured to me that I never tested this out in the field. I mean, how are you gonna build a location-based game, without going "on location"?! Like, I had no idea what it was like to go to a city for a wedding, and have this game to play. I would love to role play that out.
Crash Some Weddings
Pivoting mid-project was challenging, and exciting. But it left some pretty big research stones unturned: I wanted to learn more about the joys and stresses of planning a wedding, how might this app, or something else improve the lives of future couples and their guests? Many learning opportunities here.
Start Fresh
After spending a year on a project, or on anything for that matter, I'd get pretty attached. Yet the further I went in this project, and as the little wins added up - fixing a broken prototype feature or learning something about myself - I felt confidence grow, not in what I had learned or made, but in what I could learn next, or what new challenge was around the corner.
I feel more safe... to let go of what I have made, to challenge what I think I know. Maybe that was the goal the whole time. :)
Thanks for reading this :) You can learn a little more about me here.
-PB