Red/Green vs Green/Red

Many years ago, I was writing the documentation1 for version 2 of an order management system2. It was unusual for two reasons.

Firstly, it was a genuine X11/Motif application. So, although everybody had a Windows desktop, they had to fire up Reflection X on an underpowered beige box, connect to the OMS application3 that was a pile of C with embedded SQL4 on a DEC VAX, which talked to a cluster of VAXen running the VAX-COBOL backend that did the order picking, billing, etc. Yes kids, this is how the world worked in the late 1990s when you’re a massively functionally-dysfunctional global enterprise. Don’t worry, they eventually migrated to SAP ERP, so that was an “improvement”5.

Secondly, the UI had the weirdest color scheme for action buttons, and I never could get my head around it. On the Windows side, green for OK (go), red for dangerous stuff (cancel) was the UI norm. But the OMS application had deliberately configured the Motif widgets to use red for OK and green for the cancel (the oops you are about to lose all your changes you had just spent an hour entering). It drove everybody crazy, and nobody wanted to explain why (not even the product manager), because either it was too embarrassing, or even more embarrassingly they did not know and didn’t want to admit it.

Many decades later, I finally get what the logic was: my best guess is that whoever designed it was thinking like an electrical engineer and not like a software engineer. Electrical engineers do things differently.

Let’s dive into the fascinating world of traffic lights6:

  • red = stop / danger / oops
  • amber = caution / warning
  • green = go / safe / proceed

Most people, through day-to-day life, are familiar with the traffic light model and is something they don’t need to think about: it’s been subconsciously ingested. When Xerox started to work on HCI and develop GUIs they adopted what was familiar because when something doesn’t need to be explained more than once that makes it easier to adopt and use (the reduction of friction that UX people love to talk about).

In industrial electrical engineering, which predates software engineering, they use a different color convention:

  • red = live / energized / connected => don’t touch or you will go zappy-zapp!
  • amber = attention / caution => something is happening
  • green = de-energized / open / no voltage => safe to touch/maintain

And I only learnt about this because I recently discovered Cursed Controls, which was a change from Chris Boden; both YouTube channels are really interesting if you’re into engineering with a slice of weird.

So, whoever designed that OMS was thinking like an electrical engineer completely oblivious to the fact that the software field did things differently. That nobody questioned this when they built out that software was an interesting reflection on the cultural7 and organizational dynamics8 at play.

$LastModified: 2026-07-23 07:54:18Z (Thu, 23 Jul 2026) $

  1. You think those 500 page manuals appeared by magic? No, someone had to fire up FrameMaker, write the words, do the illustrations (hundreds of screenshots that had to be annotated), and put it all together in some coherent order while trying to maintain a sense of sanity because the software was “in development” and changing every two weeks. In this case, it was also unusually formatted: none of that boring A4 Portrait, it was A5 landscape, two columns, and presented using an Information Mapping like structure and sublime typography so it didn’t suck; it combined text and visual flows to make using this less than easy to use application as usable as possible (although we all know that nobody ever reads the manual, and yet you wonder why technical writers have a tendency to go postal?). ↩︎

  2. ESICOM2, which obviously stood for Estensione Sistema Commerciale #2. Corporate comms was in English, so calling it this was a less-than-subtle indicator that it was very clearly coming from, and under the thumb, of the Italian side of the business. ↩︎

  3. It was actually a suite of discrete applications, and the plan was to roll out such exciting things as Sales Order Application (with modules like Order Processing, Order Inquiry, Order Browsing, and Order Reporting), etc. Because it was a GUI to replace the existing TUI, the GUI was schizophrenic being a mix of TUI in a GUI, and a GUI written by TUI developers. Sometimes they really tried hard to adopt the GUI way, so instead of a list of things to choose (enter 1 for Processing, 2 for Inquiry, and so on) they would throw up a bunch of Icons for you to click on… but as nobody wanted to pay for a designer to draw the icons, the developers did the best they could with paintbrush… to call it naïve art would be a disservice to naïve artists. When you got to “Frames” where the UI showed form data for entry/updating, don’t expect it to read left-right top-to-bottom, that would be far too easy. Some buttons produced selection lists, and if the list popped up in close proximity to, but not adjacent to, the button, that was considered a success. ↩︎

  4. Written by mainly French programmers, under Italian management, writing English-like SQL statements. For some reason, I was very successful in my quest to never ever see at any of that code for the sake of my eyes. ↩︎

  5. The migration from a proprietary in-house fully-customized COBOL system to SAP ERP went about as well as you can expect. ↩︎

  6. or railway signaling, which uses the same colors, came first (1840s), so when traffic lights appeared later (1860s) they used what was familiar because, as always, it was the easy and logical path to take. And here we are, many years later, and people still jump the red. ↩︎

  7. Italian management vs French hierarchy, which was a madhouse of politics atop such different cultural norms. On the positive side, being based in France the company restaurant was gourmand’s delight (and the lunchtime glass of subsidized wine was greatly appreciated by both sides). ↩︎

  8. The internal politics were so typical for the cultural background of the (Italian) management team responsible for the OMS that it really was like working in a hyper-realistic cliché. One example was a complete refusal by one of the middle-managers to proof the documentation because “it is too much to read”. The solution: print it double-sided and he was as happy as a pig in shit to review it because “Bene. Less to read now!”. Life is never simple, and the next week the department manager had a fit because somebody (that would be me) had done too many things with the photocopier and their monthly department usage count had trended upwards instead of downwards. The irony being this was the same manager who insisted I gave copies of the documentation to all the middle-managers to review, and as one in particular refused to accept a ream of paper to read, and the local printer was simplex only, the only solution was to (ab)use the corporate duplex photocopier. The Dilbert cartoon was perilously close to real-life. ↩︎