Jagex has a Quality of Life team. Cyber security needs one too
Nathan Chadwick · · 8 min read
TLDRRead the short version
- Jagex runs a dedicated Quality of Life (QoL) effort for Old School RuneScape. It exists to revisit shipped features, fix the small annoyances, and prioritise by what players actually ask for.
- In the Poll 77 blog, the team admitted Poll 76 was too slow, rebuilt a dedicated QoL team, and committed to a regular cadence of 15 to 25 changes every six to eight weeks.
- Software and security rarely do this. Features and controls ship, the friction stays, and users quietly build workarounds that are worse than the problem.
- Security has proof it works when it happens. Microsoft reworked Recall after backlash, and dropped periodic password expiry from its baselines because the evidence said it did more harm than good.
- Security needs a standing QoL function: an owner, a backlog, friction metrics, a release cadence, public mistakes, and the willingness to revert.
A game that goes back and fixes things#
I play Old School RuneScape. One of the things I respect most about Jagex is something that rarely gets a headline: they go back.
Not just to ship the next big expansion. They revisit what is already live and ask a boring but important question: is this still annoying people for no good reason?
That work has a name in the community and inside the studio: Quality of Life, or QoL. A bank tab that takes three clicks when it should take one. A menu that forces a confirmation every time. A reward shop that is technically fair and practically miserable. None of these are exciting content. All of them decide whether the game feels respectful of your time.
What Jagex actually does#
I did not want to write this from memory, so I went and read the posts.
In the Poll 77 and The Future of QoL blog, the Old School team does something most companies would avoid. They open with a mistake:
- They admit Poll 76 was not delivered within a reasonable timeframe, because the people working on it were reassigned to higher priority projects.
- They say they are rebuilding a dedicated team for QoL work, with developers focused purely on QoL updates and bug fixes, while another group works on larger features.
- They commit to a rhythm: ideally a QoL poll every six to eight weeks, with around 15 to 25 changes in each, both polled and unpolled.
- They add a survey alongside each poll so players can say which changes matter most to them, and what part of the game to look at next.
The same post shows them changing their minds in public. Players pushed back on a proposed Lumbridge Elite Diary requirement because it made no real difference. The team replied that they had focused too heavily on staying close to the original design, and changed the approach. On the Stale Baguette, they found they had read the Sandwich Lady's code wrong, corrected the drop rate they had pitched, and adjusted another question to match.
That is a product team treating its own work as something that can be wrong and can be improved.
The part I think is smart: not everything is a vote#
Jagex also has a polling charter that says what they will and will not put to a vote. Big new content and changes that significantly affect players get polled. Bug fixes, UI improvements, accessibility changes and quality of life enhancements generally do not.
Their own polling changes post is even more interesting. They note that fewer than 6% of active members actually vote in polls, and that with a 75% pass mark it only takes a small slice of voters to block something most people wanted. So they lowered the threshold to 70%. They also say that when players have had significant objections to minimal changes after going live, they have been able to revert them without fuss or disruption.
Read that again, because it is the whole model:
- Ship small improvements without ceremony.
- Listen to the people who use the thing.
- Do not confuse the loudest voices with everyone.
- Make reverting cheap.
- Keep a team whose job is to do this.
Now look at the rest of the software industry#
Most software does not work like this. A feature ships, the launch announcement goes out, the team moves on to the next roadmap item, and the friction just sits there. Users complain on forums, in support tickets, or not at all. The complaint becomes a known issue. The known issue becomes the way it is.
Games get away with this less than business software because players can leave and tell everyone why. Enterprise software has a captive audience. The person using it did not choose it, and the person who bought it is not the person who suffers it.
Nowhere is that gap more expensive than in cyber security.
Security is the worst offender, and the stakes are highest#
Security controls are almost always built by people who will never use them eight hours a day, and sold to people who will never have to. The result is predictable:
- A sign-in flow that makes people re-authenticate so often they approve prompts without reading them
- A policy that blocks a legitimate workflow and offers no path except a ticket and a two day wait
- A tool with alerts so noisy that analysts learn to ignore the category
- A "secure" file sharing process so awkward that staff send the document from personal email instead
- Exception requests that pile up because nobody owns the job of fixing the rule
Every one of those is a quality of life defect, and in security, a QoL defect is a security defect. People route around friction. The workaround is the shadow IT, the shared password, the screenshot in a chat, the disabled agent. I wrote about this from the identity side in Conditional access patterns that survive real users, and the point stands: a control that real users cannot live with is not a control, it is a countdown to an exception.
It also feeds the problem I covered in Identity risk is rising: why ITDR belongs in every security programme. Helpdesk resets, MFA re-enrolment and approval fatigue are all places where bad usability and attacker opportunity meet.
Proof that going back works#
The encouraging part is that when the security industry does go back and fix things, it works, and nobody regrets it.
Periodic password expiry. For decades the standard advice was to force password changes every 30, 60 or 90 days. People responded by adding a number to the end. In 2019, Microsoft removed periodic expiry from its security baseline, calling it an ancient and obsolete mitigation of very low value and pointing at banned password lists and MFA instead. NIST's current SP 800-63B-4 now says verifiers should not require subscribers to change passwords periodically, and should force a change when there is evidence of compromise. That is a security control being retired because the evidence said it made things worse, and the whole industry is better for it.
Windows Recall. Microsoft announced Recall for Copilot+ PCs, got heavy criticism over privacy and security, and then changed course before it shipped. It became opt-in and off by default, required Windows Hello, added proof of presence, and put "just in time" decryption behind Windows Hello Enhanced Sign-in Security. It was delayed to go through the Insider programme first. You can argue about whether it should have been designed that way to begin with, and I would. But the loop of feedback, rework and a better default is exactly what I am asking for, and it should be the norm rather than the exception.
Neither of these was a failure of security. Both were security getting better because someone was willing to admit the first version was not good enough.
What a security QoL function looks like#
Jagex does not do this by accident. They have people whose job it is. Security teams, and the vendors who sell to them, should copy the structure.
1. Give it an owner and a backlog. A named person or small team whose measure of success is reduced friction and reduced exceptions, not just new controls shipped. If it is everyone's job it is nobody's job.
2. Measure friction like you measure risk. Track the numbers that show where people are suffering: helpdesk tickets by category, MFA resets, time to approve an access request, number of standing exceptions, how often a policy is overridden, how many alerts are closed without action. These are your equivalent of the Jagex community asking for the same fix for years.
3. Look at behaviour, not just complaints. Jagex noticed that fewer than 6% of players vote. The same is true of users and complaints. Most people will never file a ticket about a clunky control. They will just stop using it properly. Telemetry and workarounds tell you more than a survey does.
4. Ship small fixes on a cadence. Do not wait for a major version or an annual policy review. A rhythm of small, boring improvements every few weeks does more for real security than one big project every two years.
5. Treat integrity changes differently from usability changes. Jagex does not poll bug fixes or game integrity changes. In the same way, you should not run a vote on whether to keep phishing-resistant MFA. But how that MFA is rolled out, how recovery works, how often a trusted device is challenged: that is a QoL conversation, and users should be in it.
6. Review old controls on purpose. Every control should have a reason and a review date. If you cannot say what threat it stops, or you can show it does more harm than good, like password rotation, retire it. Removing a bad control is a security win.
7. Make reverting normal. If a change causes a spike in tickets or a wave of workarounds, roll it back or adjust quickly, and say so. Being wrong for a week is cheap. Being wrong for five years because nobody wanted to admit it is not.
8. Be honest in public. The most persuasive thing in the Poll 77 blog is the first section where the team says they got something wrong. Security teams that publish what they changed and why earn far more trust than ones who announce each new rule as if it was handed down.
For vendors as well as internal teams#
This is not only about in-house IT. Security vendors need QoL teams too. If your product needs a consultant to configure, produces thousands of alerts that nobody can triage, or makes admins click through the same warning every day, that is not a customer problem, it is a roadmap problem. The vendors that win the next few years will be the ones who treat usability as a security feature, and who keep going back to their old releases to improve them.
The point#
A game studio understood something that a lot of the software industry has not: shipping a feature is the beginning of the work, not the end. People who use your product every day will tell you exactly what is wrong with it if you give them a way, and a dedicated team to act on it.
Cyber security needs the same humility. Fewer controls that look good in an audit and more controls that people can actually live with. A team whose job is to make the secure path the easy path, and to go back and fix it when it is not.
Jagex calls it Quality of Life. In security I would call it making the safe thing the easy thing, and it deserves a department of its own.