SLOTH: A model about user’s unreasonable expectations of systems design

One of my favourite subjects during my MSc (also one of my top grades), was Human Factors in Systems Design. Therefore I shouldn’t act surprised that this subject is so present at my current work as the central focus in our process of designing and developing software.

While I consider having a user-centred design approach a fundamental aspect of successful software, involving users can also lead to problems. These problems can be easily managed though, as long as we recognise them. With that in mind, I came up with the SLOTH model, which aims to identify some fundamental issues of involving end-users in systems design.

Background

When I was designing a Dynamics CRM 2011 solution for a customer back in 2011, I was quick to involve the sales team to gather their requirements. One particular user was making so many fancy and elaborate requests, that his manager intervened:

– 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!

– Actually, that isn’t right at all. If any monkey could use it, I would have hired a monkey instead of you.

This interaction really stuck with me. So when I got to study Human Factors in Systems Design a few years later, this interaction came back to mind, and I came up with the following model to identify user’s unreasonable expectations of systems: SLOTH.

SLOTH

The SLOTH mnemonic stands for:

Simple, Lightning-fast, Omniscient, Trendy, Holly Grail

The model helps us identify user’s unreasonable expectations of systems, which I assert to be guided by laziness instead of the pursuit of 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: We all want fast systems but it is frivolous to expect immediate outputs in certain circumstances. For example, working on analytical software performing complex queries and calculations isn’t the same as working on Windows Notepad.

Omniscient: The application is supposed to cover every single scenario and foresee every single output without user intervention or interpretation of the output. Knowledge workers often fail to understand that they are hired for their expertise in a domain, and not their use of an application.

Trendy: The system has to be slick, beautiful and exciting. Users want constant visual stimulus, sometimes in detriment to their work, failing to understand that the latest trend in systems design isn’t necessarily suited to all systems.

Holy Grail: Users want to use just one application to do all of their work. For example, the overuse of Excel as an attempt to create an enterprise business intelligence system, or overly-customising a Customer Relationship Management (CRM) platform as an attempt to create an Enterprise Resource Planning (ERP) system.

Closing thoughts

There is nothing wrong in designing systems that simplify our life. Who would rather calculate an entire balance sheet with pen and paper rather than using a spreadsheet? The problem is when users try to come up with requirements that are mainly about being lazy, instead of requirements that are mainly about increasing productivity.

Thanks to my former lecturer Martin Stacey, who provided me with some feedback on this model.