Recently, a new team composed by extremely talented designers was formed. Their goal? Design the visual appearance of KDE 5.  Known as The Visual Design Group (VGD), they will ultimately design what will become the default look. There’re relatively newcomers on the group as well as old faces, Nuno Pinheiro the lead designer behind KDE 4’s Oxygen iconography, Plasma and desktop theme among them.

Just as exciting, perhaps even more, they’re asking the community to be more involved in the design process, you can participate and share your own thoughts, drafts and mockups at the KDE forums.

So far so good. The problem is VGD is separated from the UI and UX design. What does this mean? It means they will likely create a new widget theme, Plasma theme and iconography, but that’s it. This is a major problem, having a nice overall theme design is just half the story, in fact, is not even half the story. The default look can be changed at any moment by any user, this is KDE not Apple’s OS X, but the UI and UX design can’t be changed by an end-user.

KDE’s UX designers need constant input from visual designers

Let me start by saying one thing: I don’t think KDE should reduce the number of options available, I don’t want it to be GNOME or Pantheon or OS X. What I think is how KDE presents its options could be vastly, vastly improved. In other words, I don’t think the criticism KDE sometimes gets for being too complicated or too cluttered with “unnecessary” options is rooted on the options themselves but on how they’re presented to the user.

Good visual UX design has measurable consequences on how users approach and interact with a product. For example, a very cluttered interface overwhelms users, they feel intimidated, like they won’t be able to use it properly. The same application with the same exact options but presented in a cleaner manner doesn’t feel this way.

Consistency is also an important feature of a desktop environment, the user should be able to recycle as much as possible what he learned in one application to the next one. Otherwise you unnecessarily increase the learning curve of your DE. A consistent widget theme, Plasma theme and icon theme are not nearly enough to accomplish this. Applications needs to be designed with a specific way in mind.

This isn’t to say that developers shouldn’t deviate from the norm, the idea is to set guidelines not the law of the software land. Developers should and will deviate from the guidelines if they feel their programs are not well serviced by sticking to them. Moreover, most developers aren’t either visual designers or UX designers, having a comprehensive set of guidelines with both visual and UX elements is helpful not detrimental. That way you don’t end up with stuff that looks like this (the problem isn’t Oxygen at all):

It teaches them how to make applications users know how to interact with and feel please to look at (not just when looking at the individual icons, or widgets, but the app as a whole, remember Aristotle’s maxim: The whole is bigger than the parts).

Visual designers should be able to tell UX designers what they’re doing doesn’t look good at all, regardless of the theme, and how it could be improved.

Obviously, some applications are more complex than others. It’s relatively easy to make an image viewer feel welcoming, doing the same with something like The GIMP is an exponentially more difficult task. Which brings us to the second point.

KDE’s visual designers needs constant input from UX designers and developers

Let’s take a look at a very pretty mockup from the forum of the VDG:

It looks really nice, the problem is almost no application in the entire KDE ecosystem is quite that simple. It may be adaptable to a few of them, namely the subset consisting of simplest of them all. In other words, Visual Designers need constant input from UX designers because they need to create a visual design that looks beautiful when applied to real world applications. Making a simple window with a few buttons and no or almost no content that looks nice is easy, making a real application gorgeous is not. They need to know what are the features and UI elements that will appear the most in applications and how they will be used. Therefore, UX designers should be able to tell them when their design looks good on paper yet doesn’t look good on real world user interfaces.

UX designers and VDG shouldn’t be two teams, they should be a single team

Given that they both need constant input from each other and how both are in a position to correct each other (for different, yet valid reasons), they should form a single team. The entire visual design of KDE is a creation for which both teams are responsible, however, changing the theme is trivial, changing the UX is not. They need to be integrated since the very first day because they need to work together to achieve a coherent, good looking, consistent design and guidelines that will help other developers achieve the same.

Cooperation is obviously harder than working solo, but the end product is much better as a result. VDG is a great step forward because they recognize this, is not a single person in-charge of the visual design, is a group of people working together. Very talented people mind you, all perfectly capable of doing something like this alone. They won’t always agree, they will need to work out compromises and on top of that they’re even encouraging feedback and ideas from the community. They deserve a tip of the hat, we need to take that same ethos and apply it to the entire design of KDE. 

When both UX and visual designers work together things look more like this:

Than our two previous examples.

Note: I’m not endorsing the last concept as what should become KDE 5’s design (although it looks really nice and functional), I’m merely pointing out how superior the results are when these two groups of people work together. The last design looks pretty much as an evolution of the simple window draft informed by real world applications, the UX design of KMail was also modified by the designer to look better than it currently does, in other words, is an example of what I’m arguing.