01. Research

The first step in building the Character Creator was doing the appropriate research to figure out who our users are, who we're specifically targeting, the problem we're trying to solve, and our goal for solving that problem.

Primary Research

The current users of TableRaven consisted of a mix of game masters (GMs) and players. However, we also wanted to target minority players who haven't played Pathfinder before, but were interested in doing so. We wanted to create a friendly way for new players to ease into tabletop role-playing games (TTRPGs), as well as a way for existing players to create a character easily, without having to reference multiple sources.

This allowed us to narrow down our target audience to two main personas:
1.) Users new to TTRPGs who were intimidated by the rules of the game
2.) Existing players needing a faster way to create characters.

Pain Points

Due to Branch Cut, Inc. being a startup company, funds were limited; which allowed me to get creative with some of my user research. Luckily, many of my friends and family were happy to offer their time, allowing me to pick their brain and interview them.

I interviewed 5 potential new users and 5 existing players and discovered the following pain points.
‍

Between the total of 10 participants I interviewed, there was one underlying pain point:
The amount of information involved in creating a character was overwhelming and hard to keep track of.‍

Our Goal

How can we solve this problem? We need to be able to walk users through the process of building a new character and keep track of the small details that were hard to remember, such as:
‍
• How many feats does my character get?
• How will I know how many skills to pick?
• What does Druid get? How many spells do I get?
• What in the world is a domain?

The business goal was user retention in TableRaven, as well as easily getting new users into TTRPGs.

My goal as a UX Designer was to make character creation as easy as possible, walking users through each step while providing insights into the why - all the while accommodating existing users who knew how to play the game and didn't need as much help going through the process.

Secondary Research

Secondary research involved doing a competitive analysis on our top two competitors: D&D Beyond and Roll20 - both of which had their own style of a character builder.

Because D&D Beyond's Character Builder was mentioned by 80% of existing users, I decided to create a user journey map in Figjam documenting the steps it brought the user through, information provided, and annotations regarding whether it was easy or difficult for me, as a new player, to understand.

Full view of user journey through D&D Beyond's Character Builder

Snippet of annotations and flow through D&D Beyond's Character Builder

Roadmap and Project Planning

Now that we knew our goal, we needed to scope out the project. We started with a basic roadmap of how many steps there would be, what each step would entail, and the information we would need to for each.

Basic Roadmap for Pathfinder 1e Character Creator

The roadmap allowed us to scope out the timeline of the project,. I worked with the project manager, stakeholders, front-end developer, and back-end developer to create a realistic timeline that included a private launch and full launch.

Roadmap Timeline created in Confluence

02. Ideation

Post research phase, I was ready to begin the ideation process. While my process through designing was to work on the first step to full development stage, then move on to the next step (this allowed us to test each step as we went); I followed the same process for every step: Research, Ideation, Iteration, Review, and Development.

Research

Each step required it's own fair amount of research, as I was entirely new to the game of Pathfinder. Because of this, I wanted to make sure I truly understood the information, the purpose, and how I could organize it sufficiently. One of the ways I did this was by using Confluence and Libre Office to create spreadsheets and documents detailing all of the information needed for each step. The project manager and I worked closely together and collaborated on the Confluence page. I was referencing the online source: https://www.d20pfsrd.com - while the project manager referenced the Pathfinder 1e Core Rulebook.

In the end, we had pages upon pages in Confluence documenting our research, as seen below.

Research pages for Character Creator in Confluence

Step One

Ability Scores Research

Class (Cleric) Research

Step Two

Step Two involved two of the more complex systems involved in creating a character: equipment and spells.

Before beginning the design for equipment, I first had to figure out how to organize the information. I began by using Balsamiq to create a sitemap of the categories, subcategories, and groups (if any). I reviewed this a few times with the project manager and stakeholder before coming to a decision on how to organize the information.
‍
*Note: If given a budget for user research, I would have conducted a card sorting test or tree jack test to ensure our assumptions were correct.

The final sitemap included the main categories, subcategories, and the items that would belonged within them. I created this using a spreadsheet in Confluence to make it more accessible for my team while giving the front-end developer the data he needed for each piece of equipment, and the information I needed to design the card for each category.

Snippet of Armor from equipment sitemap made in Confluence

Similar to equipment, spells had a lot of information that needed to be included on one card - all of which varied by class and spell type. In order to fully understand what elements needed to be in the design and which classes had access to which spells, I created a spreadsheet with the project manager detailing level 1 spells and their relevant information for each class.

Snippet of Spells spreadsheet made in Confluence

Step Three

Step Three was all about the final touches, what we liked to call the "flavor" of your character. This is when the user chose their alignment (which was sometimes restricted by their choices), and their languages known (which is affected by their intelligence modifier, chosen in Step One). It also provided an overview of what your character's features were; including hit points, armor class, saving throws, attacks, combat maneuver bonus, etc. These were all things that the user didn't choose but were calculated based on their choices and vital to playing the game.

Armor Class (AC) Research

Alignment Research

Design

I used a similar approach for each step in which I used pencil and paper to get down as many ideas as I could before presenting 2-3 to the project manager and stakeholder for review. Once the sketches were approved by the stakeholders and project manager, I moved onto the iteration phase.

03. Iteration

The iteration phase looked a little something like this:
mid-fidelity design -> review -> tweaks -> review -> high-fidelity design -> review -> tweaks -> review

I took the sketches I drew with pencil and paper, pasted them into Figma, and started to turn them into digital, mid-fidelity designs following brand guidelines using the style library I created.

Mid-Fidelity

Because TableRaven is a web-application and is meant to be used at a TTRPG assistant, I used a mobile-first approach in my design process.

Design Decisions

• Starting Gold:
  There are two options for choosing a character's starting gold: roll for it or take the average for that character's class. Rolling for it opens a modal that rolls digital dice for the player and explains why they're rolling the dice they are. For example, a witch rolls 3 six-sided die to roll for their starting gold. Taking the average is a set number explained in the card details. We decided to include a third-option of "My GM determined my starting gold" which opens a text modal, allowing the user to type in a custom value.

• Cards:
  The app itself already relied heavily on a card format, with the goal of being translated into widgets in the future. I reused the patterns from the already existing app and reformatted the typography and images to suit the needs of the component. Each card had a set format of name, small title (if applicable), description, and below description would be custom to the specific element.

• Categories:
  Originally, there were a total of 14 categories from the Pathfinder Core Rulebook and the SRD. Research shows that displaying more than 7 options can overwhelm a user. We broke equipment options into 3 main categories: armor and shields, weapons, goods and services; then further broke down goods and services into 8 other categories.

• Breadcrumbs:
  Due to there being so many different categories, a user could go quite deep into equipment. Users should always have a way to go back if they clicked by mistake, or return to the main screen.

High-Fidelity

After reviewing the mid-fidelity designs with the project manager, stakeholders, and front-end developer I iterated further into high-fidelity designs. I also designed the desktop version to show the responsive website and labeled each frame to communicate the actions with the developer.

Design Decisions

• Removing Bottom Navigation:
  ‍After reviewing the mid-fidelity designs with the team, we decided to remove the bottom navigation in lieu of a more website-friendly navigation. We removed the ability to skip steps, as so much of the character creation process depends on its counterparts. The front-end developer then worked his magic to allow for the browser buttons to allow for forward and backwards navigation instead of having a fixed footer. This gave us more real estate to work with on small mobile screens.

• Add to Inventory Button:
  In the previous version of equipment, we used a check mark to allow users to select certain items. However, after some research we realized that there are items that user will want multiples of, such as darts or trail rations. This prompted me to change the design to allow users to add multiples of one item. I reused a pattern that had been used previously in the app for adding and subtracting as to lessen the learning curve.

• Selectors:
  When navigating back to a certain step, users needed a way to see the previous selections they made. We did not want this to be interact-able, but a way to communicate "this was your last decision". I created a new pattern based on the brand colors and previous checkmark pattern to create a green selector placed in the top left corner of each card. When checked, it indicates to the user their last choice.

04. Review

Once the designs were finalized, I moved the Jira ticket over to "done" to communicate to the developer that it was ready for implementation. During development, I provided support to the front-end developer by answering any questions, approving any design tweaks, and iterating further on designs that got scoped down or weren't as feasible as we originally thought.

UAT and QA Testing

While we didn't have the budget to have real users test the feature, each member of the team went through and checked for bugs and design inconsistencies. I assigned each team member tasks, such as "Create an elf druid with an animal companion" or "Create a abjuration wizard". The tasks kept team members on track and allowed us to test every corner of the feature.

For each issue or inconsistency, we created a Jira ticket for the front-end developer explaining the issue with a screenshot of the problem, along with the browser we were using so he could recreate it if need be. We each used different browsers (Safari, Firefox, Chrome,) and tested on mobile, tablet, and desktop.

05. Recommendations & Lessons

This project taught me a lot about organization, the importance of information architecture, and how to accommodate multiple types of users. As I went through the design process, I found I was able to improve the usability and design more and more. It taught me the importance of user research and consistent designs.