Trade Fort — A case study
Trade Fort is an app for casual and avid virtual goods traders based on the game Team Fortress 2. It offers a virtual marketplace for all kinds of commerce activities for people who want to buy and sell using the different in-game currencies and real money.
As a long time fan of Team Fortress 2 and someone who trades often, not only in this game but many games on Steam, I wanted to take up making this concept app as an exercise to attempt to make trading a better experience. The main problem I hoped to tackle was the detachment of “playing the game” experience and the “trading” experience and find a way for both of them to be a simultaneous experience with the playing the game serving as the primary experience.
Conceptualization
Discovering User Needs
For the purpose of identifying users and their needs, I interviewed 4 people I know who have been regularly playing the game for three to five years and have been trading or last traded in the past 2 months. While ideally I would have liked to interview 15–20 people, this was a side project alongside my daily routine which is why I could not accommodate many more interviews.
I interviewed the participants that represented a variety of demographics based on how frequently they trade vs how much they spend (whether real currency or virtual goods that can be easily converted into real currency). I compiled the transcripts to infer a common set of pain points for all the users that could be addressed together. After that I mapped them on a graph based on what type of users they are and if there is any relation to their needs based on their separate set of behaviours. This was the underlying basis of choosing the various functionalities of this application.
Next step was to research the existing platforms.
Researching what the users are already familiar with
In-game trade servers first :
These are usually server rooms inside the game meant for real time gameplay. Since they can have an exclusive entry barrier, people designate some servers as exclusive trading servers. While trading is the original objective intended by server owners and participants, playing the game regularly is quite possible with all communication happening using the game’s chatroom.
Compared to the trade servers, the trading website are very focused since they don’t reside in the game. Backpack.tf (one of the most popular trading website) resembles a traditional e-commerce website:
Personas
Storyboard to map out ergonomics
The main goal for the product is to be a part of the game’s experience rather than demand users to be pulled out of the game experience to view potential trade deals on items that they just saw and might forget after this session. It’s to try and enable all these trading activities when there is downtime in the game experience itself, whenever the users are at the main menu, load screens or simply in game and in a safe zone away from harm (like the spawn room).
Another important goal was for the entire app to be used by just one hand as people engrossed in the game experience might be reluctant to let go of the mouse.
User Flow
As a frequent user of these trading sites and being a part of this subsection for many years, the challenge was not to reinvent the experience. The challenge was to reduce the friction between users and the experience of trading or browsing these deals within the trading community that can be used side by side while playing the game on a mobile (or secondary) device.
Information Architecture
After analysing the user journey and identifying the macro compartments, the information architecture was so devised as to feature-wise compartmentalise the needs of various users. This directly resulted in the tab system being chosen as seen in the wireframes later.
Wireframes and Sitemap
Based on the initial ideas, I got to sketching some multiple low fidelity wireframes quickly in order to flesh out the flow and layouts. After selecting the designs and iterating on them, I reached the solution.
While there were 3 iterations to reach this solution for almost all screens, including them here for an analysis would be a tedious ask of the reader. Instead I would like to show an example of what was the design thinking to fulfill the objective.
Here are two iteration I did for the premium listing screen. While all of these feature tabs, I was hoping to include some modern design interaction where the upper tray retracts when the user starts scrolling or dynamic layouts to differentiate between classified and promoted listing. I ended up choosing neither as the app is intended to be part of the game’s experience. So it was important for it to feel, look, and function like the game. I chose a design that would strike a compromise between accessible by modern standards for portrait mode and borrowing just enough from the game so it feels like the app and the game are part of the same experience while also borrowing heavily from the familiarity of the trading websites that thousand of users already use.
Even though they are frowned upon as clunky elements, pop-ups are a huge part of the game’s existing UI and hence that was a frequently featuring elements that I used as well.
Sitemap diagram
Mockups
The game has a very industrial feel to it’s UI which dictated most of the artistic vision for the mockups including typography and colours. When the objective was to be a seamless part of the same experience, it was only natural to borrow artistically from the game.
Why an app instead of a responsive mobile website?
Researching the same set of candidates yielded the fact that the two important factors coming into play in terms of frequency of revisits were either intrinsic nature of user to keep perusing or the negotiating aspect that created the need of using this platform as a messaging tool. The frequency of revisits was not a function of how many trade deals a user does but how engaged are the traders in a deal that results in a back n’ forth communication. Messages pertaining to negotiations and notifications for the same were very valuable to the users which are best implemented in an app instead of a website, given the frequency of notifications and subsequent revisits for the duration of a single trade deal.
Conclusion
It was an important lesson to learn that the best practice to fit into an experience that already exists is to leverage the familiarity of the original experience. Expectations arise from what users are familiar with which can be a great asset for design inspiration.
In an ideal development environment, this project would be developed in an agile manner. The highest priority and highest impact features should be implemented first followed by the next set of features that can be derived from user needs and validated by quantitative data. For this process, it would be important to define what a “good” performance would be and what KPIs would best help gauge that.
This project was made using
