Case Study for Solo Project - Meeplr, the Tabletop Matchmaking App
Executive Summary
This is a personal project that was completely self-defined. Meeplr solves one of the most frequent complaints about tabletop gaming - the difficulty of finding compatible people who are available at the same time as you. Within this simple matchmaking app you can find and chat with other local gamers, including people who love board games and tabletops that do not know others who do, those seeking to expand their gaming group, those that are new to an area and have not yet found a group, and those that are new to board games and tabletops in general. The latest version of Meeplr also includes a section for board game shops (that have been vetted by Meeplr staff) to advertise their stores as safe places to meet.
Research Deep Dive
Before I began to draw out solutions, I needed to ask myself who the users would be and what they needed out of such an app. I asked the following questions and with extensive research, found their answers, as follows.
Competitive Analysis
Next I would run a competitive analysis in order to figure out if there were currently any good solutions to this pain point.
These systems all had merit and their own places within the problem space, but none were truly equivalent to what I was planning.
Proto-Persona
Then, I crafted a proto-persona, Harold. His details and user goal statement are as follows.
He is also the persona that I would later use to guide my audience through the prototype as I made my final presentation of this app.
Feature Cards
My next step would be to draw out feature cards, planning what kinds of features would be necessary for a minimum viable product and how feasible each would be to implement.
Kano Analysis
These feature cards would then be used in an extensive survey, fueling a Kano analysis. This would help me figure out which features of those planned were necessary, performative, attractive, neutral, questionable, or anti-features.
As the feature chart and final result of the Kano show, all of the features planned were either performative or attractive, a good sign that I was focusing on the features that would make this app meaningful and unique.
Prototyping and Usability Testing
With the main features planned and evaluated, I started prototyping. I spent the first half of the week making the first version and testing it. In order to do so, I asked five representative users to test the prototype and think-aloud about how they felt and experienced the app in its current state. I iterated twice, each time asking new participants to use and think-aloud about the app, providing feedback and asking any clarifying questions.
Below are key screens from the final version of the app. The prototype in its entirety can be experienced by clicking here and loading the Figma file.
Final Prototype
Next Steps
This concept had overwhelmingly positive reception, and could be a viable and meaningful solution to a common and still under-served problem area. There are still plenty of things that can be improved upon, however, and to continue iterating on this project, first I would polish up the visuals and animations to make it flow more smoothly. Then I would do another round of usability testing on this version of the app, to negate any aesthetic-usability effect. In-depth interviews would continue so that I could gauge user reactions to changes, and A-B testing would be used when necessary to figure out which versions of the product are preferred. More feature cards and Kano analyses could be made in order to test out new attributes, such as the ability to further customize your meeple, view lists of other players, and decide again on people you had previously passed on. Should this app launch in the future, I would want it to go through several rounds of iteration and testing, so that I can make sure that I am delivering much more than the minimum viable product.