UI/UX: Myths and misconceptions

Appearances can be deceptive

The “Unix” 3D file system featured in Jurassik Park (1993) dumfounded many developers as a beautiful but impracticable one.
The “Unix” 3D file system featured in Jurassik Park (1993) dumfounded many developers as a beautiful but impracticable one.
The “Unix” 3D file system featured in Jurassik Park (1993) dumfounded many developers as a beautiful but impracticable one. It was a real (demo) SGI software though, known as FSN or “Fusion”.

It is not about aesthetics

If you’re building UI/UX based on what is considered “beautiful” or not, you’re in trouble. Someone will “like” it, someone else will not, and you might never be able to understand why, because all these terms are subjective. As a result, you won’t be able to explain and justify your choice in an understandable (objective, shareable) way.

Primary goals

So the primary goal of an UI is not to please some user’s eye but rather:

  1. ease the User’s eXperience (reduce number of clicks, etc.) so that the first objective can be fulfilled. The more the UX will be practicable, the more your UI will reach the goals you expect it to reach.

Secondary goal

This is not like saying that having your users find your UI to be “cool” or “looks nice” is not a good thing. Making users appreciate or even be proud of using something cool will probably boosts the User Experience, but atop of good usability.

Polling is risky

A common technique to get feedback on a design proposal is the poll. However in most cases it will be highly biased, because:

  1. you ask a too small panel (typically the size of your project team) to be significant. So another poll would probably yield different results if asked to a different panel.

CSS is coding

This is something very hard to admit for developers, but this is something important to acknowledge because, if not, CSS work will never be done correctly, as too technical for most designers and too clumsy for most developers.

Technically speaking

Indeed, many developers argue that CSS is not coding because when using it:

Why does it matter?

That misconception would not be more worth discussing as the gender of angels if it hadn’t bad consequences on how CSS is handled is projects:

  • (Real) CSS workload is underestimated: As programming is reputed the most complicated part of a project, considering CSS as not programming is putting it in the “easy” bucket. But, as for any language, you can achieve expected results with more or less code, more or less effort, and more or less and quality. CSS coding, like any coding activity, it is not only about the what (the result in terms of appearance but also rendering performance) but also about the how: the reusability and the maintainability of the CSS code, and maintaining stylesheets correctly on big projects is one of the toughest task I ever did. I requires a lot or rigor.
    The consequence is that it is far from being a negligible task in terms of time (if you don’t want to write a mess, but it will be even more costly to maintain a mess). Even when using an off-the-shelf design system, it can be very difficult to make it do something out of its tracks. So book that time correctly, don’t underestimate it.

It should come first

No development starts with absolute abstractions out of thin air, as all of them aim to fit a use case. Provided this software is aimed for humans, every such a use case implies an UI to convey its inputs and outputs in an efficient and convenient manner (UX).

Written by

Software engineer for three decades, I would like to share my memory. Also author of https://rr0.medium.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store