Bonfire - Digital tool for D&D
Dungeons & Dragons gives players an incredible amount of freedom to create characters that are completely their own. That freedom also comes with a lot to keep track of. Abilities, skills, attacks, equipment, features, resources, conditions, spells and everything that changes along the way eventually have to live somewhere. Character sheets solve this by collecting it all in one place, while digital tools can go even further by connecting characters directly to rules and source material. But having everything available doesn't necessarily make everything easy to use.
Bonfire is my exploration of what a digital D&D character companion could look like if it started with the player and their character.
Reading time: 8-9 min.
D&D UX
Interaction Design
Information Architecture
What matters now?
What can we simplify?
Rules or data?
How might we reduce the effort of managing a D&D character without reducing the flexibility that makes those characters unique?
A D&D character starts relatively manageable, but rarely stays that way.
As campaigns progress, players accumulate new abilities, equipment, features, resources, conditions and spells. Some information changes constantly, some is situational, and some depends entirely on information elsewhere on the character. Players need the right information at the right moment, while their attention is already on everything happening around the table.
Cognitive load
D&D already asks players to process a significant amount of information. During play, attention is divided between listening to the DM, interacting with other players, planning actions, remembering rules and managing the character.
Digital tools can reduce manual work, but dense interfaces can simply replace physical clutter with information clutter.
Weak Information Hierarchy
HP, attacks and resources may be critical during combat, while languages or personality traits aren't. During exploration, skills and inventory may suddenly become more relevant. When information is primarily organized by where it belongs, rather than when it becomes useful, players can spend time searching the information.
Feature complexity
Character creation, progression, source books, campaigns, inventory, spells, rules references and other functionality can all exist within the same ecosystem. Individually these features are useful. Together, they create another system the player has to understand and navigate.
Dense Character Creation Experience
The complexity begins before the first session. Race, class, abilities, proficiencies, background, equipment, features and spells introduce a large number of interconnected decisions. Guided digital builders can help navigate them, but that guidance can also become friction for experienced players.
Rather than immediately redesigning a character sheet, I started by deconstructing the character underneath it.
D&D asks players to keep track of a lot, so I started by deconstructing the character itself to figure out what information it contains, where it comes from, and how it behaves.
How much D&D can I actually put in Bonfire?
Deconstructing a character introduced a slightly inconvenient question: Can I actually put all of this D&D stuff into Bonfire?
Classes, races, spells, features and their descriptions all come from somewhere. So before casually filling a prototype with D&D content, I took a small detour into the wonderfully exciting world of licensing. Luckily, D&D has the System Reference Document (SRD). For the 2014 version of fifth edition SRD 5.1 makes a selection of D&D's rules content available under Creative Commons.
Great! So I can just build Bonfire around the SRD?
Well… sort of. The SRD isn't all of D&D. It's a selection of material that can be used openly. The characters people actually bring to the table can contain options from other books, supplements, third-party material and homebrew that fall outside what Bonfire could simply package into the product.
The licensing rabbit hole revealed something more useful than what I could and couldn't use. Maybe Bonfire doesn't need to own the rules at all. If a player creates a Warlock with Pact of the Tome, Bonfire doesn't need to define either, it only needs to represent them.
The same should be true for something completely homebrewed. The player provides the character information. The source provides the rules behind it. Bonfire provides the structure connecting it all together.
Defining the Player
Having played D&D for more than five years across campaigns and one-shots, I've shared the table with players ranging from complete newcomers to experienced TTRPG players who seemingly know every rule by heart. Despite those differences, one observation has remained surprisingly consistent: D&D asks players to keep track of a lot. New players can become overwhelmed because they don't yet understand what everything means.
Experienced players generally understand the information, but still search for abilities, forget situational features, lose track of resources or look up rules they have encountered before. Experience doesn't necessarily remove complexity. It changes the player's relationship with it. For the first iteration, I narrowed the audience to experienced D&D players. This deliberately removed learning D&D from the immediate design challenge and allowed me to focus on accessing and managing D&D character information.
Deconstructing the Character
With the scope narrowed, I stopped trying to map everything in D&D and started deconstructing what actually makes up a character.
If a Warlock became a Bard, their class would change, but they might still have 24 HP, 17 Charisma, 14 Dexterity and 30 ft. movement. Those values belong to the character independently of the class describing them.
That distinction began revealing different responsibilities: some information is chosen by the player, some comes from external rules, some can be derived, some changes during play, and some only makes sense through its relationships.
Instead of seeing the character sheet as a collection of fields, I started seeing the character as a data model. The first model captured the familiar pieces, but it was still an assumption. So I started putting characters through it.
Stress Testing the Character Model
The initial deconstruction was still an assumption. So rather than designing from it immediately, I challenged the model using characters with increasing mechanical complexity. I started with a Fighter to establish a baseline and test fundamental relationships between abilities, skills, attacks, equipment, features and resources. From there, a Warlock introduced spellcasting, limited resources and mechanics that crossed several categories. A spell could also be an attack, while a feature could grant an item, which in turn could grant additional spells.
Finally, a Wizard let me focus more closely on spellcasting itself. Prepared spells, spell slots, rituals and the spellbook introduced another layer: the information didn't just have relationships, it could have state depending on its relationship with the character.
Each character built on the previous one, exposing where the model held up, where it needed to expand and which relationships would eventually need to be represented by Bonfire.
Synthesis
I brought the observations from the three characters together and stopped organizing information by where it traditionally appears on a character sheet. Instead, I looked at how it behaves.
Six layers emerged: Input, Source, Derived / Constant, Dependencies, State, Cross-context.
- Important information doesn't always need manual input.
- Bonfire can represent a choice without owning the rules behind it.
- Character information frequently depends on something elsewhere.
- The same information can appear where it's useful without becoming duplicate data.
- Information can change while the underlying character remains the same.
- Automate what Bonfire reliably understands and keep the rest flexible.
From understanding to interaction
The synthesis clarified what Bonfire needed to handle, but not where everything should live. Some information didn't need one permanent place at all. A longsword could be both an item and an attack. Second Wind could be a feature, action and tracked resource. A spell could become an attack.
Rather than forcing these relationships back into rigid categories, I moved toward exploring how players might interact with them. The research had given me enough understanding to make a first design assumption, turn it into something tangible and test whether that structure actually worked.
Sketching
The deconstruction and stress tests had already given me a working assumption of how a character could be structured.
Identity, abilities, skills, state, proficiencies, attacks, features, resources, spells and equipment gave me the building blocks, while the synthesis showed that those blocks couldn't always be treated as isolated categories. Information could be derived, depend on something elsewhere, change state or surface across several contexts.
I translated the synthesis into a set of questions to sketch against:
- How might Bonfire reduce input without reducing what players can see?
- How might information surface across contexts without being duplicated?
- How might Bonfire automate what it understands while keeping everything else flexible?
I started with the relationships that had challenged the model. What happens when a longsword is both an item and an attack? Can Second Wind combine its feature, action and remaining uses? How should a spell communicate whether it's prepared and usable?
Exploring these interactions gradually introduced hierarchy: what needed to stay immediately accessible, what could sit deeper, and what needed to surface across both. The sketches became the bridge between the character model and my first assumption of Bonfire's information architecture.
Wireframing the assumptions
At this point, I had two things to work from. The character model gave me an understanding of what information was needed to represent and how that information related. The sketches gave me an initial assumption of how players might access and interact with it. Together, they formed the basis for Bonfire's first information architecture.
Rather than treating that structure as something already validated, I treated it as a design hypothesis. I moved into low-fidelity wireframes to bring the individual ideas together into a complete character experience, establishing navigation, hierarchy and the relationship between information.
The focus was still on structure rather than visual design:
- What should Alex see first?
- What information needs to remain accessible while moving through the character?
- How quickly can changing states such as HP and resources be updated?
- Where should cross-context information surface?
- How does the player move between viewing their character and changing it?
The wireframe was the first time the deconstructed character model became something that could actually be navigated and used. And importantly, it gave me something tangible to put in front of another player.
Usability Testing
With the wireframe interactive, I tested the first design hypothesis with five experienced D&D players. I gave each participant a series of familiar situations and asked them to navigate the prototype while thinking aloud.
The tasks covered checking an ability or skill, finding an attack, casting a spell, checking a proficiency, taking damage and changing character information.
The goal wasn't simply to see whether participants could complete each task, but to observe where they expected information to be, what they wanted immediate access to, and where the structure interrupted their existing understanding of their character.
Iterating the interaction model
Participants generally understood the information and could find what they needed. The bigger opportunities were in how they interacted with it.
The Character Sheet / Profile Card split reflected my own structural thinking more than the players’ mental model. Testing also showed a difference between information that changes constantly, like HP and resources, and information that is edited more deliberately. This gave me three directions:
- One character, one navigation structure.
- Separate playing from editing.
- Keep changing state close to where it’s used.
I consolidated the Character Sheet and Profile Card into one experience, while separating interaction into three modes:
Normal View - For playing
Information is optimized for reference and interaction without exposing unnecessary editing controls.
Quick Edit - For the things that change constantly
HP, temporary HP, hit dice and other immediate character state can be adjusted without turning the entire sheet into a form.
Page Edit - For deliberately changing the character
When the player wants to modify the underlying information on a page, they enter a dedicated editing state where the interface can prioritize inputs rather than play.
Opening up the visual language
The usability test exposed something beyond navigation. While participants could find what they needed, parts of the wireframe felt text-heavy, compressed and difficult to scan. The structure was becoming clearer, but it needed room to breathe.
Looking back at other digital TTRPG tools, I noticed how often they lean into the genre visually: dark interfaces, parchment, ornamental typography, textures and fantasy-inspired decoration.
Bonfire had started from a different problem. I was trying to reduce cognitive load, strengthen hierarchy and make complex character information easier to scan. Adding another layer of visual detail risked competing with that. So I started questioning one of the genre's most obvious conventions:
What would Bonfire look like if I stripped most of the fantasy away?
Expanding the solution space
Through an inspiration board, I explored generous spacing, simple surfaces, rounded typography and clear controls. This led to a deliberately restrained visual direction where hierarchy could come from spacing and typography rather than decoration. Most importantly, information and interaction needed to feel different. With Normal View, Quick Edit and Page Edit switching between reading and changing information, players shouldn't have to inspect an element to understand whether it can be edited.
That meant exploring the states of even simple components: What does an input look like when it's empty, focused or filled? Stripping away traditional fantasy styling also created room for a smaller, more deliberate kind of personality. Important actions could feel almost physical which is slightly exaggerated, visibly pressable and satisfying to interact with.
Final Prototype
The character model established what Bonfire needed to represent. Testing reshaped how players interacted with it, while the visual exploration established how those interactions should communicate themselves. Together, they became one character experience built around three modes: Normal view, Quick Edit, Page Edit.
Usability Testing 2
With the interaction model and visual language now combined in a high-fidelity prototype, I returned to usability testing. This time, the focus wasn't on discovering a new structure. I wanted to see whether the changes made after the first test actually addressed the friction I'd observed. Participants were again given familiar D&D scenarios and asked to complete them without being introduced to Bonfire's interaction modes beforehand.
Can players distinguish between viewing and editing?
Do Normal, Quick and Page Edit communicate their purpose without explanation?
Can changing state happen without interrupting play?
Taking damage, changing temporary HP, spending resources, etc.
Is information easier to scan?
Did spacing, hierarchy and the lighter visual language address the text-heavy/dense feeling from the wireframe?
Does cross-context information behave naturally?
Can players access attacks, spells, items and features according to what they're trying to do rather than needing to understand the underlying data structure?
What the test revealed
Bonfire's lighter structure was perceived as less overwhelming than D&D Beyond, particularly when adding custom items and homebrew content. The freedom to simply enter what mattered was appreciated, but also revealed a trade-off: without a rules-heavy system behind it, Bonfire can't automatically account for effects such as an item changing an ability score.
Normal View, Quick Edit and Page Edit initially felt unfamiliar, but changing information quickly became straightforward once understood. Quick Edit and the visualization of temporary HP worked particularly well, while the navigation between the three modes could benefit from clearer affordances.
The lighter and more spacious interface was perceived as sleek, simple and less overstimulating. Some text was still considered too small, however, raising accessibility as an area for further exploration. The participant also questioned the prominence of information such as Alignment and Hit Dice, reinforcing that what feels important can depend on both the player and the context.
A lighter character companion focused on flexibility, context and reducing the effort of managing a character.
What began as a character-sheet redesign became an exploration of the structure underneath a D&D character. Deconstructing and testing that structure shaped Bonfire into a lighter character companion focused on flexibility, context and reducing the effort of managing a character.
Bonfire keeps frequently changing state accessible while allowing deeper information to surface when relevant. Reliable relationships can be derived to reduce unnecessary input, without trying to automate every part of the character.
Testing suggested that this simpler approach could also create more freedom around custom and homebrew content, where players aren't limited to what Bonfire already understands. That freedom comes with a trade-off. Without a comprehensive rules engine, some consequences remain the player's responsibility. The goal became finding the right balance between assistance and flexibility.
Looking back
Bonfire changed what I considered “simple.” Simplifying an interface doesn't mean simplifying the information behind it. Understanding that complexity became the prerequisite for deciding what Bonfire could safely hide, derive, connect or surface elsewhere. Simplicity became less about removing information and more about reducing the attention the interface asks from the player.
Simplicity became less about removing information and more about reducing the attention the interface asks from the player. What started as a character-sheet redesign became an exploration of how an interface can carry some of D&D's complexity without taking away the flexibility that makes characters personal.
Looking forward
Bonfire is still a concept, and a high-fidelity prototype can only take the interaction so far. The next step would be a lightweight functional prototype covering one complete journey: creating a character, entering the sheet and using it during play. That would allow the interactions to behave for real rather than being simulated in Figma and, more importantly, allow Bonfire to be tested at the table.
Final testing also opened directions worth exploring further, including personalization, accessibility and whether the underlying model could adapt to other TTRPG systems. But before expanding Bonfire, I'd want to prove its core idea where it matters most:
At the table, with a character, during actual play.
