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. It was a real (demo) SGI software though, known as FSN or “Fusion”.

Some years ago I stepped in my manager’s office to tell him that I decided to leave the company to do frontend development: I lacked real experience in that field and I wanted to be better at it. He replied to me that frontend development was not “real development” and that comforted me in my decision: frontend deserved to be better known.

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. drive the user toward what you want her/him to do: understand a message or some information (provide visual hints), engage actions (buy, subscribe, etc) ;
2. 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.

So what you have to focus first is usability, because a “beautiful” interface can be unusable (whereas it is easy to make a usable interface look beautiful).

Once you start to approach UX this way, making decisions becomes simpler: there are less debates because you speak of objective, ideally mesurable arguments (number of clicks, number of visual elements and possible actions, etc.).

If something is deemed “better”, you must be able to explain why with a concrete usage example. Ideally, you should be able to compare your proposal with others on a given use case, and demonstrate that your proposal is better for most use cases.

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 often asks your colleagues instead of the targeted users as it is far more easy to do and a convenient way to get approval of your management at the same time. Of course your colleagues are humans and can qualify as any application end users, but they probably do not match the personas of the design project.
2. 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:

• they can’t use imperative programming instructions ;
• it seems ill-designed and inconsistent to them.

Are blinds ill-designed or is the Family Guy not used to them?

As a result, they’re having a hard time mastering it. But liking a language or not is not what makes it a language or not.

So, let’s face it: color: red is a declarative instruction to set the color to red. It is just a different way of writing the setColor(red) imperative instruction. For sure, you won’t build a database using CSS (but you can build a calculator or even show it is Turing-complete) because it is not intended to be. It is a Domain-Specific Language (DSL) and that domain is User Interfaces (UI).

Aside of all this, one may find more traditional programming language features in the latest versions of CSS (like @import, variables, calc()ulated values) or CSS pre-processors (which include functions or loops and ifs imperative statements for instance).

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:

• CSS is not handled but workarounded: Because of the way CSS is badly considered by many developers, they fallback on pre-coded design systems (such as Bootstrap) which promise to do nice things without getting your hands dirty. But as you don’t masterize CSS, you end up doing their stuff: you don’t use Bootstrap to build you website, you adapt your website to what Bootstrap does and supports. You get limited, and fail to build a User eXperience that makes you look different from competitors.
• (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.

So if you didn’t already, learn CSS instead of dodging it. There is no easy path to do it (especially with a confusing language like CSS) but you gain a better freedom of implementation and will not be a slave of your dependencies anymore.

“People brag about sucking at CSS just like they brag about sucking at maths” told me a colleague once. How true.

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).

So as the first link of the software chain that produces added value, a User Interface is far from being some kind of lipstick you put on your app at the end of its development.

Drawing wireframes is a way of writing the requirements for your app, and this will drive all the rest: which backend API you need, what structure data should have, and so forth. If you don’t approach development from the UI, you will find yourself adapting your UI to your backend or, worse, tweaking your UI to match your backend constraints (data granularity, push/pull issues). Often exploring UI cases reveals misses in your backend design.