When Difficulty Is the Point - Part 1

17 Jul, 2026

Recently there has been a lot of discourse on expressionist games, and intentionally frustrating game texts. Reading through it, I kept noticing that words like 'difficulty' and 'friction' had multiple definitions at once: deliberate, accidental, artistic, and everything in between, with no shared way to name which was which.

It got me thinking about my own design practice: how would I actually tell these apart in my own work? So I built a tool to find out.

In this post, I'll present a four-question tool for categorising the friction in your game, what kind it is, whether it was intended, and whether it earns its place.

Part one outlines the tool itself and a real use-case at the end.

Part two (hopefully coming next week) will walk through how I've used it against my own work, with more real examples.

The Friction Heuristic Tool

The four questions at a glance

1. What aspect causes the friction?
2. Is the friction intentional?
3. Does the friction serve the work's function?
4. Can this friction be avoided?

What is it?

This tool is for evaluating friction that surfaces when interacting with a TTRPG game artefact. These artefacts could be objects like rulebooks, player handouts, or they could be more granular, like a specific resolution procedure.

This is a categorisation tool, not a tool for finding the friction, and I've included some suggested usages below.

It does not assign verdicts or make judgements as to whether the friction is justified. This is to keep the analysis focused on the point of friction only.

It also does not decide whether the game is fun. A passage or artefact can score cleanly as intentional, functional friction that is just simply not enjoyable at the table. The fun is a separate subjective judgement that this framework deliberately avoids.

I referenced a number of existing accessibility and usability references whilst building these heuristics. They include Cognitive Load Theory (Sweller 1988), Microsoft Inclusive Design (2016) and WCAG 2.2 (2023).

Current Status

At the moment, I'm calling this a working draft, and although I've used it myself with a number of design initiatives, it needs a lot more rigorous stress testing before I can call it finished. Feel free to use it, break it, call out what works or what doesn't.

I only ask that you use real-world examples when you test it. Using the framework against hypothetical scenarios won't work. It's like trying to pin down a shadow: you need substance to grab hold of something.

Why use it?

Making more intentional design decisions creates more defensible work. Being able to articulate the effort players need to interact with our work doesn't just make us better designers, but more empathetic ones as well.

There is also value in having a shared diagnostic language for discussing friction between a creator and other stakeholders, be they reviewers, playtesters, co-designers, or bloggers.

There are a number of pre-existing UX/behavioural frameworks that address friction: Nielsen's 10 Usability Heuristics (1994) is a staple in User Experience design, and aims to minimise all user-friction. Nir Eyal's Hooked model and the Fogg Behaviour Model (aka B=MAP) also treat friction as something to fix. In all three of these models, there is no room for intentional difficulty.

How to use it?

Here's some advice on how to use it effectively:

Limitation 1: As mentioned above, this tool does not find the friction. You will need a playtest or a self-review to find that first. Write a thorough note describing the pain point and then address it with the four heuristics.

Limitation 2: It cannot be used unilaterally on a third party's artefact without the author's input. It only functions properly as a structured conversation between playtester/reviewer and author.

Limitation 3: Atomic categorisation of friction points may risk flattening multifaceted issues. The tool avoids assigning weights like impact and severity (see reasons below) so the user must take care when examining each point of friction in isolation. Two individually mild friction points might compound badly when encountered in tandem.

To reduce the risk of the above, run the artefact through multiple times, once per distinct friction identified, rather than once per passage. Focus on the point of friction only. If the passage seems to be doing more than one kind of friction at once, don't try to force it into a single pass. Separate out each issue and examine them separately. This keeps each diagnosis targeted and meaningful, rather than averaging multiple points into one muddy answer.

Example:
Feedback: "The inline stats in the key description were too vague and incomplete. I had to keep flipping to the full description in the back of the book."
Breakdown: The stat block is written too tersely. The stat block requires flipping to the back to reference keywords. The stat block does not include special abilities.

Three use-cases I've tested that worked well:

1. Self-review with distance: Write your draft then deliberately set it aside for at least a week or so. When you return, re-read with fresh eyes. These will catch accidental friction that may have sat in your blindspot at the time of writing. Run anything that surfaces through the four questions.
2. Playtester/reader feedback: A third-party doesn't need to know the framework, they just need to be able to articulate what friction they encountered. The author then uses the four heuristics to analyse and diagnose what was reported.
3. A second reader in conversation with the author: The best use case I've found is a sympathetic critic who can ask the four questions of the author directly, rather than guessing from the text alone. This is similar to a Qualitative research method called peer debriefing.

The four heuristics in more detail

1. What aspect causes the friction? Format or Content?

Format: Everything about how the artefact presents information. This includes typography, contrast, layout, binding, size.

Examples:
Mörk Borg's often illegible layout and typographic choices.
Poor scan quality and lack of OCR text in some old TSR-era modules.

Content: The information that needs to be imparted onto the reader. This includes vocabulary, syntax, deliberate ambiguity, themes, structural difficulty.

Examples:
Triangle Agency's compartmentalisation and fragmentation of rules.
Gygax's often-confusing purple prose in AD&D 1e.

Certain elements might have both format and content friction. These should be categorised separately, but may need to be addressed in tandem.

Example:
Excessive bullet point usage can force readers to work harder, as the sentences are stripped of connectives and transition words that help link ideas together. This may require both rewriting the prose (content), and adjusting the layout (form).

2. Is the friction intentional?

Was this specific instance of friction a deliberate choice or an unintended effect? Note that this is not answerable from the artefact alone. A third party cannot deduce this without the creator's input. It should also be noted that this is not a judgement on whether art requires intent, only if the specific point of friction was intended. An artefact can contain both genuinely intentional friction sitting alongside unintentional friction. E.g., intentionally opaque prose might contain spelling mistakes or layout errors. These should be separately weighed against the defence of "it's art".

3. Does the friction serve the work's function?

Does this friction contribute toward the work's intended experience or would the work lose nothing if it was removed? This is useful to pose for several reasons; a creator can better triage which friction to address first. It can also help hone focus on the work's desired outcomes by evaluating whether this friction is core to the experience. Discovering unintended friction that serves the work is also an invitation to make a new, intentional decision to keep it. In which case it graduates from unintentional to intentional.

4. Can this friction be avoided?

Bypassed: A bypass exists in the same artefact, often as a partitioned section or as an opt-in rule.

Example:
Mörk Borg's included adventure, Rotblack Sludge, tempers the chaotic layouts for a more standard two-column affair. This makes it easier to scan and reference.

Substituted: A parallel version exists outside the artefact as a separate resource.

Example:
Mörk Borg freely provides a more accessible version of their ruleset for those who struggle with the original text.

If neither exists, then the friction is deemed unavoidable.

Some rejected fifth heuristics:

When refining this list, there were a few questions that didn't make the final cut, but might still be useful for additional framing. Question 3 is the most likely to be reinstated as a fifth primary heuristic, but this requires feedback and further testing.

1. Is this friction disclosed? This was meant to address whether the artefact is self-aware of its own friction, but is too similar to 'does the artefact need to explain itself' which is a subjective judgement.
2. Who encounters the friction? Considered but dropped because assigning the stakeholder who absorbs the friction cost doesn't change whether the friction is legitimate or not.
3. How frequent is the friction? This one is actually still useful once the friction is diagnosed, and might be used as a secondary triaging heuristic. It is also more objective than the Q4 below, because the author can actually go through and count the occurrences.
4. How severe is the friction? Severity is a useful metric to capture, but unlike frequency, it is a subjective weighting. Asking a reader or player to rate the level of friction risks a number of self-reporting biases like recall bias and social desirability bias. It is also difficult to design a rating scale that will be reliable at the size of the playtests you will probably be running.

Case Study:

While playtesting my Appendix N Jam entry (a solo trick-taking card RPG), I experienced friction with a couple of the procedures.

Initial friction

I was having trouble remembering the trigger for a specific rule, "you can only collect cards of the current season's suit". Its a rule that makes the game hard and sad in my kind of way. You can't stockpile whatever you like, you can only take what the season in front of you offers. It is one of the emergent themes that I am really attached to with the game.

But after playing eight games in a row, I kept breaking that exact rule. I kept grabbing off-season cards without noticing. This voided the whole round and made it hard to evaluate the ruleset. The first conclusion was, 'this rule is too annoying and I keep getting it wrong. I should remove it or change the condition to make it easier to remember'.

That initial conclusion would have likely wrecked the game, as it became much easier to win without that specific constraint.

What the heuristic did

The first two questions: What aspect causes the friction, and is it intentional?

And there are actually two frictions here:

1. The rule itself (only collect in-season).
2. Me forgetting to apply it (grabbing off-season cards).

Run each through the 2×2 (is it intentional? does it do a job?):

The rule itself is a legitimate kind of friction. It is deliberate and does essential narrative work. It is the forgetting that is the bad friction. I didn't intend it, and it brings nothing to the game. And importantly, it isn't a content problem, its a format problem. The game doesn't help you hold the state in your head while you context-switch during play. You have to remember, unaided, which season you're currently in before every single decision and under real play you often don't.

The fix

How might we assist the user in tracking the current season with a memory aid?

• Make the season impossible to miss: place the season marker (the ace) face-up on the table to provide a quick reference to the player.
• Make the season-count physical so you don't miss the game-ending fourth season: add a token track to mark each season change.
• Keep the terse rules necessary for the game length limitation.

A transferrable lesson

When I keep tripping over my own rule, name the friction before I judge it. "I keep getting this wrong" is not evidence that the rule is bad, its often evidence that the game doesn't support the rule at the table.

In part two I will walk through a few morecase studies where I applied the heuristics to games I am working on.