The Solforge Redesign project was done as a form of service design for an application that I believed had problems that I could solve. This redesign was not used by Stoneblade Entertainment, or for their Solforge application, and is entirely created on my own for portfolio purposes.
After playing the game for many weeks, and researching the system structure and competitor structure, I identified multiple interface issues that I could improve. The image shown above is my final redesign of the primary screen using assets extracted from images I took of the Solforge application.
The image above is my redesign of the Play Menu for the Solforge application. The column on the left is all of the current games the player has open, as well as the tutorial and the game creation function. The right column are competitive categories for drafting and constructed play. The intent is the keep casual play and competitive play separate, but easily accessible in the same space.
Store redesign for the Solforge application. Organized the store into two categories, individual cards and packs/bundles. This allows for the developers to place new sales of individual cards in one location, as well as keeping their bundle sales separate from the individual cards. The amount of currency the player has on their account is also visible in every menu, but is especially useful in the Store menu.
The Deck Builder is where I discovered the majority of the problems with the current application. Above is my redesign of the Deck Builder, and below is the reworking of the filter system. The problems with the Deck Builder revolved around a lack of information about the cards while browsing, requiring the user to physically rotate the device 90 degrees to view the card viewer and deck builder, and the card viewer and deck builder being separate interfaces. Having the viewer and builder in separate screens causes confusion for players trying to navigate and add cards to their deck.
The filter was not changed much from the original, instead was reoriented to fit a horizontal scheme instead of the vertical one previously used.
My primary goal was to remove the rotational device requirement for the application, because it removes the user from the experience and can cause conflict and irritation with the device. While the irritation is focused on the rotation of the device, the conflict is created from the application itself, and can be easily solved by accepting the horizontal scheme that is already implemented everywhere else in the application.