When working on the Automation industry sector, it's very common to see equipments with a huge lack of advance in their UX/UI display design over time.

Most of them still uses the old fashioned "X"-segments display to show their data.

enter image description here

  • What are the most encountered barriers for this industry to have more powerful graphic displays, like we all have in our smartphones?

enter image description here

  • As we are growing a new generation which is much more used to technology, could we expect big changes on UX for this industry?
  • 2
    I'm not really sure. My guess is it's probably for the same reason I'm still stuck with Windows XP on my work PC. – Ajedi32 Aug 24 '15 at 14:57
  • 1
    I'd like to reference part of this answer, "people who become proficient with the Bloomberg command line interface can be extremely efficient with it (much more efficient than a point-and-click GUI would allow)". It is likely that these industry professionals are used to simple old fashioned interfaces and the cost of retraining them on new interfaces isn't worth it. Just a guess though. – DasBeasto Aug 24 '15 at 15:59
  • 1
    Probably lots of reasons...cost, habit, necessity, or (my guess) why fix what's not broken? – DA01 Aug 25 '15 at 1:55

I work for a large electronics manufacturer and the move to better displays for industrial equipment is happening, albeit slowly. As suggested above, it was often an engineer who was left to design the display too. This was usually of secondary importance to the function of the device itself. That's starting to change in our company where new products often get a UX team and a designer to upgrade the display and interface. Better, more detailed, more accurate displays are a competitive advantage, so I think we will see more of it in the future.

The other thing that will upgrade industrial displays is the Internet Of Things (IOT). Many of these devices -- metering equipment, sensors, etc. -- send data to the net. This has the effect of shifting the display from the device to the web and one of the screens we use everyday -- desktop computers, tablets and smartphones. Once the display is on those screens, it will look and behave like other sophisticated data visualization apps we have come to expect.

The device itself will probably retain a basic display to show that it is on and receiving/transmitting data, but the more detailed display will be pushed to the web. A consumer example of this is Fitbit's wristband: it has a minimal device display and a really detailed display on the web.


Mostly because of costs, and the software/hardware platform the thing is running on. A lot of the displays you see on machines, parking meters or other electronics run on rather basic hardware and software where you sometimes only have a few kB of Storage to handle everything, and it's mostly programmed in C or some language that is very close to the hardware. The architecture itself is rather old, but that also means it's already well tested, cheap to manufacture, plenty of documentation and support exists and the people working with it know potential bugs and pitfalls and how to work around them.

All of this means:

  • You simply do not have the libraries available to show fancy outputs, because most of them simply wouldn't fit into the memory available on the hardware
  • Complicated libraries and software tends to cause complicated and expensive bugs, but upgrading hardware once it is deployed is expensive, slow and sometimes complicated
  • You don't get any benefit from showing awesome dials in true colors on an LED screen, because the guy working on it only needs a plain, simple and clear reading.
  • A simple LCD screen or LED segment display is more robust towards extreme temperatures or the moisture you can encounter in some workshop. Some displays tend to fog up behind a plastic or glass shield that is meant to protect the screen from damage, rendering the output unreadable.

No manufacturer who sells industrial machinery costing 5-6 digits would upgrade the hardware and software to some new platform just to show some better graphics. These machines sell on production output, low maintenance costs and reliability and not on fancy looks and round corners like apple consumer products.

As RobC pointed out, newer and better machines do have Ethernet ports to feed live data back to a central management system. At this point you can simply write your own dashboard using existing graph libraries to display the values in any shape or color you like on a website or smartphone app :)


The main reason is not UX related.

The "displays" you are referring to in fact are not just displays. They cover a very broad variety of hardware ranging from simple PLCs with matrix LCD screens to full blown industrial PCs.

The industry chooses for these options for a number of reasons, including:

  • communication requirements with external systems (example: via a CAN bus)

  • ruggedness, safety,... (examples: guaranteed to be operating between -10 and +50 degrees Celcius with passive cooling due to dusty environment)

  • real-time computing constraints

  • low cost

  • lasts for ages

Making a comparison with an iPad is unfair, from a technical point of view. iPads are relatively cheap because of the large scale in which they are manufactured. And even then they are still too expensive for industrial application. What the industry is looking for is robust and fail free cheap systems that will not be replaced during the lifetime of the machine it belongs to. An iPad has almost the opposite specifications.

Now, looking at this from a UX point of view your question makes a huge amount of sense! Any user of any industrial system is not unfamiliar with the UX of an iPad and takes that experience (consciously or unconsciously) with him to work. And then wonders why the UX on an industrial system is so poor. No user is immune to this. The industry needs to recognize this. Failing to respond to this could mean a competitive disadvantage.


Your two examples there are very different. One indicates it's using real-time data from a piece of hardware, the other indicates using static data.

In my experience, the guy with enough knowledge of hardware (often very specialized hardware) just isn't a UI/UX/designer person. The skills to do that aren't required to accomplish the tasks he's looking to do. In addition to that, adding a more refined UI/UX layer could also add a delay. I imagine in real-time reporting you want to go for the most precise/accurate solution.

  • While that chart UI is likely static since it says "Quarterly" at top it could be made to dynamically refresh. – DasBeasto Aug 24 '15 at 15:22
  • @DasBeasto referesing quartlerly from a database is a lot different than looking at real-time RPM values from a running machine! – user5482 Aug 24 '15 at 15:32
  • I'm just saying it is possible to use the same interface for real-time RPM values, for instance the gauges in the top right could surely be used in this scenario and updated in "real-time" using technologies like Knockout/AngularJs to update constantly. – DasBeasto Aug 24 '15 at 15:37
  • "adding a more refined UI/UX layer could also add a delay. I imagine in real-time reporting you want to go for the most precise/accurate solution." - I bet this is it – Dave Haigh Aug 24 '15 at 15:54
  • There's absolutely no difference in the second example if you re-arrange it to real-time data values. – Machado Aug 24 '15 at 16:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.