Role: Product Designer
Collaborating with: Full Stack Development Team
Challenge: Build a suite of features for Magic the Gathering players.
Solution: Enable users to build and share decks keeping gameplay information easily accessible.Building for Magic the Gathering
At the time, our platform could identify Magic the Gathering and Pokémon cards, but as a partnership in the Magic the Gathering space grew, the business’s priorities shifted from features that could be used by all collectors of trading card game or sports cards, to features that would be of high value to the MtG audience that used their cards in gameplay.
Filter Enhancements
When first designing the filter pattern, we were only working with baseball cards but I leveraged some common patterns that I was confident could grow with us as we added different types of cards and filters. This enabled us to add MtG data without having to modify too much of the Front-End experience.
Even though the front end followed the same pattern, our team had to rework the card data tables in our database to accommodate all these new fields. Our first iteration of filters only handled data fields that existed across all the card categories (like card year), but because MtG had so many data fields that were useful to a player, this was a good time for us to enhance the filter capability.
I had a lengthy discussion at the time about AND or OR filtering with the lead developer on the task and a team member who was an avid MtG player. Though we saw some gameplay-specific scenarios that would be supported by AND filtering, OR filtering was more broadly useful. AND filtering also required more back end work to accomplish and we just didn’t have the bandwidth at the time to enable the user to do both. Though we ended up tabling the work, the conversation helped us both better understand the use cases for filtering and our own capacity for making it possible down the line.
Grouped List View
I had recently created a List View that could be used across all card types to enable value information estimate data to be surfaced earlier. As I considered the different views that might be useful to someone preparing a deck for gameplay, I saw a common pattern of a grouped view in other MtG tools.
This allowed us to provide another level of information to the user without having to modify the card tiles. Should the MtG audience continue to grow, I would expect that a MtG-specific tile would be even more useful to the experienced users.
Sharing Decks
Enabling the user to share their deck was not only a feature that would be useful to our users, but it would also help them become advocates for our product and grow our user base. My focus for this feature was to remove as much friction as possible in the experience. Unsurprisingly for startup life, we were working towards a tight deadline, so the phased approach was a familiar friend in getting a version of sharing that could grow. I relied on the user’s own view of their Deck as a baseline for the shared view to leverage the components we already had and to ensure that the experience felt cohesive for users familiar with the platform.
One feature that was important to the business was the ability to compare the user’s own deck to the shared one they were viewing. The hope was this would drive users to purchase cards through a partner vendor.
I created a couple options for this experience. The first maintained a cleaner default view with the ability to see the comparison in page, while the other showcased the comparison in an overlay.