Do Developers Dream of Electric Sheep?

UX Pattern Development 101 for OutSystems frontends

Some time ago, I was given Steve Krug’s book — Don’t Make Me Think. Although I work as an frontend developer at OutSystems, I do appreciate reading about UI and specially UX. Not only for personal interest, but also because I believe it can improve my work!

That being said, I must admit I approached the book with low expectations. Even it’s classic status, It was originally published a long time ago and for that, I had doubts I would learn something shockingly new about usability, that wasn’t already desiccated on the numerous articles and talks I have been through.

On the left: Krug, S.(2014). On the right: MGM/Stanley Kubrick Productions — 2001: A Space Odyssey (1968).

For the most part, that ended up being the truth, but early on something happened that I wasn’t expecting. Chapter 2 — How we really use the Web — is just pure genius! It resumes perfectly, with what the author calls 3 Facts of Life, the main reasons behind usability problems on the web — when those facts aren’t considered.

And not only that, I saw myself making parallels in my head, with the same problems we have to struggle with about how other developers use the patterns we offer on Silk and OutSystems UI.

So… it’s with no shame that I will steal those facts, adapt them to OutSystems development, and present them to you. Hopefully it could help you improve the patterns you create, as sure it did help me!

Kampff Test. Warner Bros. — Blade Runner (1982).

Human Error #1 - We don’t read descriptions or documentation. We scan them.

This is true for the web, for the developers reading descriptions of a pattern or any other example really, where a human being needs to read some kind of instruction. Who never did buy something at IKEA and skipped some pages while assembling it (with disastrous consequences somewhere in the future)?

Krug gives us some reasons on why this happens. By simply changing the expression Web use for development, we can see how perfectly aligns with our reality:

  • We are always on a mission. Most (…) [development] involves trying to get something done, and usually done quickly. As a result, (…) [developers] tend to act like sharks: They have to keep moving, or they’ll die. We just don’t have the time to read any more than necessary.” (Krug, S., p. 22)
  • We know we don’t need to read everything. We scan to read only the parts that interests us and we think helps solve our problem. Anything else is irrelevant. This means that, any other information on a description that hasn’t as a purpose solving a problem, will probably never be read. Yap, “When to Use”, I’m looking at you!

Human Error #2 - We don’t make optimal choices. We satisfice.

When we are creating, as an example, a Style Guide or looking for a pattern on the widget tree, we usually assume that other developers using it will consider all available patterns and choose the best optimal option, after thorough analysing the pros and cons of each one…

I’m giving you a moment to stop laughing.

Welcome back! What really happens, is that we stick with the first functional solution we find. We just want the bloody thing to work, so that we can move on to the next problem. Krug here quotes Gary Klein, calling it the “first reasonable option, a strategy known as satisficing” (Krug, S., p.24). And he gives four main reasons for this to happen:

  • We’re usually in a hurry. Optimizing is hard. Satisficing is easier and quicker.
  • There’s not much of a penalty for guessing wrong. This is specially true for OutSystems. Trying a pattern or a bit of code is only a 1-Click Publish away. Most of the time is faster just to try something and go back, than to invest in optimizing on what we think would be the best option.
  • Weighting options may not improve our chances. This is mostly true if the environment the developer is working on isn’t really optimized for them. As an example, if the navigation or discoverability in a Style Guide is not clear enough, satisficing could sadly be more efficient.
  • Guessing is more fun. A little bit of gambling is always fun. As optimizing is so hard, satisficing is quicker, and if you get it right you think you are the greatest and just tricked the system a little bit.

Human Error #3 - We don’t figure how things work. We muddle through.

Most things aren’t being used the way they were designed. Just deal with it. This is true for sugar sticks, the brand new Website that you carefully designed or the UI Pattern, that you think has the right parameters to solve the main development’s problems.

Krug gives us some more on point reasons for this:

  • It’s not important to us. We don’t care to know and understand how most things work. As long as they work when we need them. “It’s not for lack of intelligence, but for lack of caring. It’s just not important to us.” (Krug, S., p.26)
  • If we find something that works, we stick to it. As soon as we find something that works to solve our problem, we stick to it. We only change it if something stumbles upon us, that evidently improves what we have.

OutSystems actually deals very well with these points. Being an low-code platform, one of his major selling points it’s the fact that you don’t need to understand what every code is actually doing, you just need it to work! Nevertheless, this still can be a problem, and takes us to Human Error #4.

Human Error #4 - We don’t look for the new. We look for mirrors.

This last point I didn’t steal from Krug, it’s a bonus one, that I think off myself (wow, amazing).

At some point in my youth I really was into Cinema, and started going through a whole process of discovering the great masters of the 20th Century. Aside from Stanley Kubrick, the one that probably impressed me the most, was his russian counterpart — Andrei Tarkovsky. On his most famous movie — Solyaris — there’s a character that said something that really got into me:

“We don’t need other Worlds. We need a mirror. Man needs Man.”
Dr. Snaut, in Solyaris (1971)

The character was referring to space exploration and the possibility of finding other species. The fact is we are ok about finding alien cultures, as long as they aren’t too different from ourselves. What we really want is a reflection of our Civilization, that fills the void that we are feeling alone in the Universe, without becoming a major inconvenience.

Phew!… This is getting deep. Let’s quickly move on!

Taking this to our reality, we always look for familiarity on things and try to solve the problems the way we always solved them. If we as developers use a pattern to solve a specific issue, it’s very unlikely that we will look for a new one, even if as it happens would work even better for the situation.

This last point has been a real motivation for us at OutSystems, as our main thrive while making a new framework — OutSystems UI — was to make it evidently better than SILK UI, which most developers are already used to. We are constantly trying to break the desire for mirrors.

Baseline results

To end the article, let’s recap the four Human Errors defined:

  • We don’t read descriptions or documentation. We scan them.
  • We don’t make optimal choices. We satisfice.
  • We don’t figure how things work. We muddle through.
  • We don’t look for the new. We look for mirrors.

Obviously, this isn’t a formula, but I do believe that having some of these topics on the back of your mind, will impact the way you develop. Probably, these points might seem obvious for you, but I find them important to gain self-aware when developing for others.

As Don Norman enfatizes, “…many of our beliefs about how people behave — including beliefs about ourselves — are wrong” (p. 44). I’m reading his books now, so expect more on this topic in the future (hopefully, before 2049…).

Meanwhile…Keep it simple. Keep it short. Keep it obvious.

…Keep it obvious, he said. Warner Bros. — Blade Runner (1982).


KRUG, Steve (2014) — “Don’t Make Me Think — Revisited. A Common Sense Approach to Web Usability”. New Riders, USA.

NORMAN, Donald (2013) — “The Design Of Everyday Things”. Revised and Expanded Edition. The MIT Press.