Role

I've been a member of Raid Guild, a decentralized collective of web3 designers and developers, for years. Between 2021 and 2025 I worked as a UX researcher and UI designer across many of its client raids. The guild builds its own tools the way it builds for clients: shaped around the practices it already runs on, rather than bent to fit a generic product. Dungeon Master, the CRM the guild runs its client work through, is one of those tools. This study follows what happened when the research the guild does for its clients was turned on a tool of its own.

From November 2022 to May 2023 I co-led a UX audit of Dungeon Master. The guild had stopped using it, and no one could say why. A fellow raider and I ran workshops and test interviews with the Clerics who manage the guild's clients. We mapped where the tool caused friction and turned what we found into a prioritized backlog.

The guild built its next release from that backlog. Version 2.2 shipped between November 2023 and April 2024 and changed four things:

• a dashboard that works for every member, including those with no raids yet;
• a visible raid party, with a Hunter beside the Cleric and a way to signal interest;
• a record when a raid ships: a required retrospective and a portfolio entry;
• profiles that members keep themselves.

Each of those four changes was my recommendation, and I was directly involved in the UX and UI work that followed. A later raid party of designers and developers turned them into screens and shipped them. Two engineers in our own raid party moved the tool onto a new backend while the audit ran. Two pieces of stewardship followed:

• The design system. In 2023 I co-proposed consolidating the guild's design assets into one library shared between design and code.
• The documentation. In 2024, as the guild's handbook maintainer, I audited the handbook and wrote the Cleric standard operating procedure. It documents how Clerics run a raid through Dungeon Master.

---

Problem

A tool built for the guild, and no one using it

Members take on client engagements as "raids". Every member carries a class, and the people on a raid take on roles:

Role or class	In the guild
Cleric	Manages the client relationship
Hunter	Brings the work in
Jester	Facilitates guild meetings
Archer	Designs
Warrior	Builds the frontend
Paladin	Builds the backend

Dungeon Master speaks the same language: a raid moves from awaiting to preparing to raiding, and ends shipped or lost.

Dungeon Master's first version replaced the Airtable base the guild had used to run raids. Only members holding shares in the guild's DAOs could sign in. It was stable and it worked. The proposal that funded our audit was blunt about what happened next: the tool "is currently not being used, but we lack clarity as to precisely why this is."

That gap mattered because the guild's work runs through a pipeline that's easy to lose track of. A client fills in a consultation request, and the guild decides whether to take it. If it does, a Cleric and a Hunter take it on, and a raid party forms. The raid then moves toward shipping while payments are held and released through an escrow contract.

The proposal named four problems:

• The consultation queue. Requests "need to be carefully tracked to form raid parties" and to keep the guild updated on friction, which the guild calls Moloch sightings.
• Clerics. They needed their work and data aligned so that raids "don't slip through the cracks".
• Updates. The guild needed a way to share a raid's status in meetings and asynchronously, "without requiring a specialized role/access".
• Knowledge. The guild had more knowledge to share than it could spread transparently.

The proposal also made an assumption we would test: members needed basic documentation and training before they could use Dungeon Master at all. Our job was to find out why the tool wasn't being used, and what the next version should change.

---

Research

Two maps of the same tool

We designed the research around two maps of Dungeon Master:

• The light map: the tool the guild needed. We worked through interviews, affinity mapping and user stories toward a sitemap of a speculative Dungeon Master. That sitemap was drawn from how the guild actually works, not from what had already been built.
• The dark map: the tool as it was. We tested version 1.5 with the people who used it, and mapped where it caused friction.

Comparing the two would show where the existing build diverged from the guild's real needs. That divergence, rather than anyone's feature wishlist, would scope the next version.

We started from four kinds of user. Each needed something different from the same tool:

• Clerics running client relationships;
• Jesters facilitating guild meetings;
• members looking something up;
• members trying to update a raid's status.

Workshops before interviews

The proposal assumed people couldn't use a tool nobody had shown them. So before we interviewed anyone, we ran workshops with the Clerics: educational sessions that walked through what Dungeon Master already did. The workshops also gave us the data we built the test script from.

We then held scripted test interviews on version 1.5 with Clerics, to reveal friction points or confirm the ones we suspected.

Following the red routes

We focused the testing on red routes: the few paths through the tool that matter most and are used most often. In Dungeon Master, those routes run along the raid pipeline: finding a consultation, turning it into a raid, forming a party, updating a status. Along each route we marked the pain points and bugs people ran into. Those marks became the dark map: a friction sitemap of the existing build, alongside user flows for the core tasks.

Some friction was structural and visible to anyone who opened the tool:

• the home screen was still a placeholder;
• raids and consultations shared one grid;
• members and applications shared another.

The raid card is one finding followed through to a change; it's traced under Design decisions.

From friction to backlog

The synthesis set the two maps side by side. Its aim was a finite build strategy: not an open-ended list of requests, but a scoped set of changes the guild could plan and budget for. The differences between the maps became a prioritized backlog. It named what the next version had to change, in what order, and why. The backlog was handed to the guild in May 2023.

---

Design decisions

While the audit ran, the guild's developers rebuilt Dungeon Master as version 2 on the new backend. The rebuild changed the tool's structure:

• consultations and applications got their own lists instead of sharing a grid;
• a first dashboard replaced the placeholder;
• the tool moved onto the guild's own design system.

Later releases brought the guild's proposals, accounting and escrow into the same tool. Access changed too: instead of holding DAO shares, a member signs in with a wallet the guild has listed.

The UX and UI changes came after, in version 2.2, and fell into four groups. Each was my recommendation in the audit's backlog; a later raid party turned them into screens and shipped them.

A dashboard and raid cards that start with the work

The Clerics' problem was raids slipping through the cracks. Version 2.2 reworked the rebuild's first dashboard:

• One dashboard for everyone: it works the same for a member with no raids yet as for one deep in the pipeline.
• Interest from the dashboard: members can signal interest in raids and consultations without leaving it.

Today it opens on the member's own active and past raids, then pending consultations and the newest raids.

The raid list got the same treatment:

• Raid cards: their information architecture was reworked so each card carries what someone scanning the list needs: status, the raid party, the roles still needed, and the last update.
• Lists: counts became clearer, and whole cards became clickable.
• Members list: it now opens on who is actively raiding.

Putting the party and the latest update on the card shows the line from finding to change most clearly. On a version 1.5 card, a Cleric had to open each raid to see who was on it and what had last happened. That made the pipeline harder to scan. With both on the card, a Cleric can scan it from the list.

A visible raid party

The party is where a raid comes together, and version 2.2 made it legible:

• Hunter: a Hunter role now sits beside the Cleric, so the person who brought the work in stays attached to it.
• Roles required: these show as "Recruiting" and are clearer to add and remove.
• Signal interest: members can signal interest in a raid or a consultation, so a Cleric can see who might join before asking around.
• Role badges: these gained tooltips, so the guild's fantasy class names explain themselves.

Shipping that leaves a record

Before version 2.2, marking a raid shipped was a status change on its own. Shipping now leaves a record:

• The retrospective: marking a raid shipped requires a retrospective link before the status will change.
• The portfolio: the tool prompts for a portfolio record, and that record appears on the raid's page.
• Asset links: links to a raid's assets became first-class.

Profiles members keep themselves

A shared tool stays current only if its members can keep it current. Members can now edit their own profiles: their skills, their bio and whether they're raiding. More of each raid and consultation became editable, and the raid edit form was reworked.

A shared visual language

Version 2 was built on the guild's design system, a component library the guild's apps share. By 2023 that system had drifted from its design source. Our proposal to consolidate it put the problems plainly:

• "The Figma is a nightmare."
• The coded component library (Storybook) was "not conducive to design iteration".
• The existing component styles had drifted out of line with one another.

The proposal was to clean up the Figma file, standardize colors, type and components, and synchronize the Figma library with the coded one. It would also document the process, so any raider could update the guild's assets after us. Two other members carried out the synchronization. A one-way flow from Figma to the coded library was enough, and the handbook was updated to explain it. The proposal closed as completed in November 2023, as the version 2.2 work got under way.

---

Outcome

The guild turned the backlog into its next release. A later raid party shipped the changes in three milestones, between November 2023 and April 2024. The second milestone went live in January 2024: from then on, everyone could edit raid fields and signal interest on raids. All four groups of changes above trace back to the audit we ran. The same release also brought escrow deposits and milestone releases into each raid's update feed.

The proposal had also asked for documentation of the existing product, and that thread took longer to close. In 2024, as the guild's handbook maintainer and brand steward, I audited the handbook. I wrote the Cleric standard operating procedure, which explains how a Cleric takes a consultation through Dungeon Master to a shipped raid. I also added a glossary of raid statuses and a guide to setting up a raid's escrow. That was the documentation the proposal had asked for.

These changes increased adoption, and the work was a clear success. It ran as one chain: from a proposal that admitted nobody used the tool, through an audit of why, to the dashboard, the raid party, the shipping record and the profiles the guild built from it.

What I took from it is that a tool's failure to get used is a research question, not a verdict on the people who built it. The first version worked. What it lacked was a fit with the routes the guild actually takes through its work, and mapping both the needed tool and the existing one is what showed where they parted. A guild that shapes its tools around how it works also has to check, from time to time, that the tools still match the work. The audit was that check, run with the same research the guild offers its clients.