My D&D spellbook website: A story of failure and recovery
I created a website to help my players at the table. Here’s how I did it.
Step 1. User research; defining the problem.
I am the game master running a campaign for five players. If my players have fun, I have fun. While they dungeon-delve and fight monsters, I observe. I notice what players enjoys in the game, and I pay attention to where the pain points are. In the case of the current campaign, a recurring problem was unfamiliarity with spells. Our group is new to fifth edition, we were unfamiliar with the spell options and spell details, and we shared a single Players Handbook. While the sorcerer and warlock characters researched the spells, combat slowed to a crawl and the other three players were bored.
As I watched the game, I wondered how I could help my players remember which spells they liked using and how to use them, thereby speeding up combat. I could have decided to purchase more copies of the Players Handbook, but I found the D&D 5e API online and realized I could create a website that listed all the spells my players needed. Creating a website is more fun than buying multiple copies of a book I already own, so that was my chosen solution.
Step 2: Coding the basic website.
I accessed all fifth edition spells via the D&D 5e API. I set up a <form> containing two select elements followed by a search button that, when clicked, showed a list of spells by name. Clicking on the name of the spell added the spell’s details to the screen underneath the spell names. Under each spell’s details I added another button, “Add to my Spellbook.”
I envisioned that when using the website, the players would select their character’s class first, then magic level, then click the button to search through the API. When the API returned the results, the players would browse through the list of spells named and, if interested, click the name to read details. After reading about the spell the player could choose to add the spell to their spellbook, meaning a copy of the spell (name and details) would be added to an area at the bottom of the page, remaining there as the player continued searching and browsing.
Step 3: User testing; user interview.
At a subsequent game session I asked my spellcasting players to try out the new website and offer feedback. I watched them look at the website, puzzled, play with it for about 60 seconds, and then close their laptops and tablets and go back to sharing the Players Handbook for the rest of the evening. I had known my website was unfinished; I learned at that moment that my website was unusable. Upon reflection, I realized that I had created the website with the assumption that my players would use spells the same way I used spells. The website worked for me, a GM. The website did not work for my players.
After this “failing fast” experience, I snagged my husband (sorcerer character) to discuss the website. I did what I should have done to begin with, instead of jumping straight into coding and testing. I asked my spouse what he, as a player, expected of a website that listed spells. How would he interact with such a website? How does he currently use the Players Handbook and its list of spells? What would he need my website to do to be useful during a game? I asked him to walk me through the process of how he would look for spells with a website rather than a book, and how he would use the results he found as he played the game. Together, we identified three things that would be necessary in the UI of such a website:
- Layout that minimized scrolling.
2. Better visibility: Immediate feedback upon user action.
3. Intuitive use of the site: Less text, especially when giving instructions.
Step 4: Sketching and coding the new layout
To reduce scrolling, I decided to use CSS grid and divide the viewport into grid areas. This allowed me to move the spellbook from beneath the search results to the right of the results. This also improved visibility, as the spells added to the spellbook were less likely to be beneath the fold. I reduced the need for scrolling further by making a spell’s details optional to view and by allowing the user to view only one spell’s details at a time. I made the UI more intuitive to use by altering the appearance of the search results. The earlier user interface I made use of a clickable list; for the new interface I changed their appearance to cards and included buttons with calls to action so no text instructions were necessary.
Step 5: Repeat user feedback; A/B testing; finishing the website
At this point I needed more input from my players, but this time I approached it smarter. I showed my husband the current layout, then showed him sketches of 3 different ways to display spell details. I asked him which he would find easiest to use. He selected the modal, which I added to the website.
The current status of the project
The second iteration of the project is complete and has passed my players’ scrutiny. They consider it usable and while not perfect, the suggested tweaks are small and may be postponed until a future iteration.
Conclusions drawn from this project
The most important requirement to any new project is understanding the intended audience. My biggest mistake with this project was originally designing the website for a GM, not a player. A design is best built around the user, not the technology. Once the intended users and their needs are clearly understood, the design and project are more likely to succeed.
Once a design is in place, further information from the users can move the project forward. However, users need more than a bare-bones interface before interacting with a product. If the design appears as though it will be difficult to use, testers will simply quit rather than take the time to figure it out just to offer feedback.
When first talking to users about their needs, questions can be general. As the project comes together, questions should be more specific. Show the users options within specific parameters, and ask about their reactions to the given options. If the design has generally met the users’ requirements, this is the point where users can give helpful information about exactly what they want and whether or not the product is useful.
Anna Abbott is a student in the Digital Media program at Utah Valley University, Orem Utah, studying Web & App Development. The following article relates to the capstone project in DGM 2760 course, Web Languages 1, and representative of the skills learned.
