Deck Familiar – An iOS App With a Curious Origin

Deck Familiar

Deck Familiar – An iOS App With a Curious Origin

A curios way to build an app!


Development Strategy User Experience

Industry

Entertainment

Timeline

6 months

Technology

Swift, iOS, React Native, Vercel, Next.js

Deck Familiar – An iOS App With a Curious Origin

Captive Users at Game Night

Six months of raw requirements from people who are mad you just mopped the floor with them. “I want to be able to mark games with an asterisk for when people have shady wins like this…”

Requirements often go through a cycle of doing a user survey, having a project manager create tickets, architecture reviews, designs, and then finally a developer makes the feature or change. By the time it gets to the developer, the original words have likely been through a few filters, like the telephone game.

Our new app, Deck Familiar, got built in a different way. It’s a digital companion for Magic: The Gathering, a tabletop card game with a large following, and for its first six months, every requirement in it came from someone at that table saying it out loud, while they were using the software. Wizards of the Coast, the company that owns Magic, ships an app, but it’s focused on organized events at stores, not Saturday commander at your friend’s house. This was a gap we thought we could fill.

Now it’s got a feature list a mile long and not one of them ever hit a roadmap. What follows is more of a story about live requirements gathering than a product tour.

Requirements On-The-Fly

One of the biggest things we noticed in doing it this way was getting all of the little complaints that no one would ever report, because the annoyance was too minimal to be worthy of a message, but easy to pop off with “The hit target of this number conflicts with this other box in a very specific way when I do this…”

With the first build, a player was sitting across from me and their life total was facing me. It was upside down for him. Would that ever get filed? When three people played, sometimes it was a little better if the app was landscape instead. Would that get filed?

Live testing saw that sometimes big hits resulted in having to click a button 20+ times. We added holding down for jumping in increments of 5. Sometimes you just know what the total is and it’s easier to enter a number. New feature to tap the center of the number to bring up a number pad.

Users don’t report friction when they have already adapted to it. Mediocre UI is the devil.

I brought the app to a game store, and one of the first things I heard was “I use my own tracker because I don’t like to touch other people’s phones”. Boom. The remote feature was born. 

“The gradients are ok, but I just want to see my commander”. Another feature.

The stats brought interesting problems, too. “I will never create an account ever”. Looks like we need guest functionality!

“I’m in multiple pods”. Of course you are! Now we need separate playgroups. Those are going to need some sort of admin and grouping, so let’s add Organizations, too! Now that we have orgs, would a store be an org? Could this app be useful to a store? Is there a chance at some money here?

The Pivot

Admittedly, if you printed out all the code for all the trackers that exist out there, you may actually hit a metric ton of paper weight. But we hadn’t found one that saved our stats, which meant we had either found a real gap or we hadn’t looked hard enough. Then we did what we should have done up front, had we actually been building this for public consumption: Market research.

This was extremely eye opening. I went to one of my favorite stores armed with an iPad and a custom theme for the app that reflected their site’s look and feel. 

“Hi! I’d like to show you an app I’ve been building for scoring and recording commander games…” I was immediately cut-off “Does it connect to WPN?” I stammered “Uh, not yet…” and the person walked away saying “If it doesn’t connect to WPN, I can’t use it”.

Woof. Dogwalked out because we were already missing a crucial feature. Then we started researching the Wizards Play Network. It’s a pretty closed system, but stores have to use it to record their engagement which informs how much product they get. This was a problem we had to solve. 

That led to some old-school requirements gathering and that output was used for the launch version of the app. We talked to multiple store owners, read up on what competitors have done, and even did some guerilla Reddit research surveys.

Our solution isn’t a perfect sync with WPN, but now our app nudges people to check in and gives them a QR code to scan for quick entries. Then the store can export a file and upload to WPN. It saves users having to write down their email addresses and employees having to key them in at the end of the night. With the ability to send card links to their store and a custom theme, now we have something very appealing.

Would We Do It Again?

Yes, but not alone. Live requirements was great for the people in the room, but blind to the folks who weren’t there. No one in that first room of players could have told us what the stores needed, because none of them worked at a store watching how product gets allocated. Moving that fast meant some pretty big refactor sessions when architecture changed significantly, and that was worth it. What we won’t do is let the folks in the room define the entire audience.

You can use Deck Familiar at it’s site DeckFamiliar.com, or you can download it from the app store.

Deck Familiar – An iOS App With a Curious Origin