We began the work process in a class focusing on computer science mixed with journalism. We were given a prompt upon class registration: create a bingo-style photo game intended for music festivals. Straightforward, right? Each of the five group members selected this prompt among others, so the passion and interest was there. Some reasons included appeal of the final product, interest in mobile development and enjoyment of music festivals.
There were very few “first steps”; very little getting to know each other or “fleshing out” – an overused trope in our group. Instead, we dove right into creating a prototype framework and developing around it. Our group of five was naturally inclined to divide and conquer, since we have two experienced developers and three non-Computer Science majors, who dedicated their time to User Experience.
Initial Ideas
The first element to be developed was a working, front-facing camera, which the developers easily created in React Native. We selected User Personas for whom this app would be best suited.
Even with our user personas, we questioned whether a free app would incentivize users to take a pause from their paid festival experience to play a game. Essentially, we were attempting to gamify something that didn’t really need to be made… less boring. Other gamification apps focused on drinking the daily recommended water or productivity and to-do lists – a music festival is inherently fun.
Nevertheless, we built out prototypes in Adobe XD that coincided with the original prompt. We selected music festivals that we were familiar with and combined a list of prompts with a bird’s’ eye map view.
We didn’t want to totally discard the bingo game mechanic – especially since that was the original prompt – so we created a second prototype to choose from.
The UX team created logos, selected fonts and paper prototyped, as the developers conducted iPhone testing and focused on learning React Native. Everything seemed to be coming together.
Bump in The Road
We knew upfront we were struggling with practicality versus big picture thinking. However, we had gotten too deep into our workflow to slow one another down. As we began step-by-step paper prototyping and presented to the rest of the class, we recognized a few gaps in the storyline. This was about three weeks into our process. All we could do was take a pause from continuing as two different camps, and come together to discuss what we thought about each of the details we had previously overlooked. Could users play with a friend? Is there an alternative social element? Would augmented reality be involved?
At first, our next steps were to conduct external research through surveying, add functionality features and keep developing! But then, we regressed back to refining our storyline.
Two of the key concerns that derailed our initial train of thought were first, an inability to clearly articulate what the incentive would be for playing this game during a paid festival experience, and second, an ambivalence to the broader structure of the game mechanic. Instead of decisiveness in regards to these topics, we shared our impulse choices during our midterm presentation. The questions and suggestions we received didn’t have much to do with what we were actually working with, but it called attention to our inability to clearly articulate what we were working towards. In the face of the class’ feedback, we became aware of the lack of continuity between all of our “big ideas” that were originally sparking so much energy and excitement in us.
So, we went back to the drawing board – figuratively and literally. We brainstormed and ensured to stay open-minded – no bad ideas. We also made sure to get help from Joe and Zach because they were able to focus our efforts in a way that we weren’t. Our discussions centered on essentially, “What’s the point?” We tried breaking down aspects of the game and making definitive choices. Would it be linear or multi-level? Would it be independent or collaborative?
Moving Forward
In essence, our project was more tightly scoped at first, which seemed like a blessing. But soon enough, we felt constrained by decisions we had not intentionally made and defeated by the setbacks. In the final weeks, we had to make choices, something we had really failed to do all along.
The developers started to work around a scavenger hunt format while the UX team worked in Adobe XD to clearly prototype. We were better at asking questions like, “Is it clear that a user clicks the arrow to go next?” “Is this layout easy to visually navigate?”
Essentially our “Photo Bingo” evolved into Find, an app that tourists and natives alike can use to go on various, themed hunts around their neighborhood. The app also allows users to create their own hunts. Whether it’s to find Chicago’s best pizza or monuments around Washington D.C., there will be a step-by-step path for you to find and follow on Find.
With this new idea, our user base became broader, our call-to-action became clearer and our app became something that could actually be made into something feasible. We learned that it’s really important to refine a design concept before even touching development software. In hindsight, these kinks should’ve been worked out week one, not three or four. But all was not lost: some of us learned React/Native programming, some of us learned Adobe XD and UX design thinking, while some of us just learned how to work in a group. Although we initially dove in head first, our ability to come out of the water and take a pause before jumping back in taught us more than any perfect end-product would have.
What did we learn?
It’s really important to refine the UX design early on before delving into development. It was a blessing and a curse to have such a narrow, specific prompt. We struggled to brainstorm productively without thinking too “big picture.” In this process, we learned it’s okay to take time to brainstorm thoroughly. At the end of the day, we worked well together – it wasn’t a matter of disagreement. We just couldn’t make concrete decisions.
