One of my favourite subjects during my MSc (also one of my top grades) was Human Factors in Systems Design. Naturally, it’s become a core part of my approach to software design.
I consider a user-centred design approach fundamental to building successful software. But involving users can also create problems—especially when their expectations drift into fantasy. These problems are manageable if we know what to look for. That’s why I came up with the SLOTH framework: a satirical diagnostic for spotting red flags in user demands before they derail a system.
Background
In 2011, I was designing a Dynamics CRM solution for a customer. I quickly brought the sales team in to gather their requirements. One user made so many fancy and elaborate requests that his manager eventually stepped in.
— So, what you are saying is that the CRM should be quite flexible to accommodate every scenario, yet it should remain quite intuitive for a first-time user. It should notify us of any issues, preferably before they become issues. In short, it should be so easy to use that even a monkey could use it. Right?
— That’s right!
— Then I should’ve hired a monkey instead of you.
That exchange stayed with me. Years later, when I was studying Human Factors in Systems Design, it came back to mind. That’s when I came up with SLOTH—a way to highlight users’ unreasonable expectations of systems.
SLOTH
The SLOTH mnemonic stands for:
Simple, Lightning-fast, Omniscient, Trendy, Holy Grail
SLOTH isn’t a critique of usability. Designing systems to be intuitive, responsive, and elegant is good practice. SLOTH doesn’t reject simplicity or efficiency—it targets the point where user expectations stop aiming for productivity and start demanding magic.
SLOTH helps expose unreasonable expectations in systems design—often driven more by laziness than by a genuine desire to boost productivity.
Simple: The system should be simple to the point a user does not have to think, not considering the balance between simplicity and having the flexibility to cover the required scenarios.
Lightning-Fast: Everyone wants fast systems. But it’s unrealistic to expect instant results in every situation. Working on analytical software performing complex queries and calculations isn’t the same as working on Windows Notepad.
Omniscient: Some users expect the system to handle every scenario and predict every output. They want zero need for interpretation or intervention. They forget they’re hired for their expertise—not for letting an app think for them.
Trendy: The system must look slick, exciting, and stylish. Some users want constant visual stimulation, even when it undermines usability. But not every trend in systems design fits every context.
Holy Grail: Users want a single app to do everything. That’s why Excel gets misused as a business intelligence platform. Or why CRM systems get stretched into full ERP solutions. It rarely ends well.
Rethinking Systems Design Through the Lens of SLOTH
Use SLOTH as a lens to evaluate stakeholder requests. If a requirement feels too good to be true, it probably maps to one of these traits.
There’s nothing wrong with building systems that make life easier. The problem is when easy becomes the end goal—and productivity is just collateral damage. Making life easier is fine. Designing for laziness is not. The SLOTH trap isn’t just a user flaw—it’s a design failure waiting to happen.
Thanks to my former lecturer Martin Stacey, who provided me with some feedback on this model.
Leave a Reply