Table of Contents
I've been part of the KDE VDG ("Visual Design Team") for many years, though I'm not very active there anymore. Nonetheless, as a quick metric, I've written more than 16 thousand messages in the VDG chat, and I'm still somewhat in the loop as far as design goes.
I've never been part of the GNOME Design team, though. That said, Tobias Bernard has recently held a talk called "GNOME Design: A Report From The Trenches", which gives us some insights into them. I have also done some further research, and I'll do my best to accurately represent their processes.
Design Teams
Let's start with the teams themselves.
Over the GNOME side of things, there's a Design team. According to Tobias, it's currently composed of five to ten people ("depending on how you count them"), with a mix of full-time employees and volunteers, and it has been somewhat stable over time.
As a rough explanation of how the Design team operates within the larger context of GNOME, Tobias explains that at the core there are the modules, such as the desktop and the apps, then there are other contributors on the outside, and other teams that coordinate specific areas. If a change that affects the UX is required, the Design team is involved in some way, and "everyone understands that to be the case" - which, believe me, is noteworthy.
Simple enough. On the KDE side of things, we have the Visual Design Group or VDG. It's been around for various years, and - akin to the three-body problem - it has stable eras (with various active contributors) and chaotic eras (when the situation is not as good).
I think we're currently in a Chaotic Era. There's no one that's specific to the VDG, and all those working within it are application developers that somewhat re-invent themselves as designers too, out of need. Formally, around thirty people are subscribed to the group, but it doesn't feel like so. We certainly don't have anyone working fulltime on it.
Due to this bad state of things - in my opinion - a second design team has formed within KDE, and it's called KDE Next. I did a video about the project a few months ago. They describe themselves as
a designer-led effort to revamp KDE's Plasma desktop. We share mockups, ideas, designs, thoughts, etc. We also work on icons, design systems, and much more.
Plasma Next has one to two regularly active members and a few more occasional ones. They're still all volunteers, which limits the amount of available time they have. De facto, the team is driven forward by Andy, who's the only designer-only regularly active person in KDE right now. Which isn't great.
Now, it's easy to make fun of KDE, saying things like "you can see there's no design team!", but that wouldn't be very honest. This situation is somewhat recent, and just a few years ago the Visual Design Team was much more active, and great design work was done. Some of the people who were in the VDG are still active KDE contributors, though they interact in other spaces.
Matrix and Gitlab
Both GNOME and KDE heavily use Matrix and Gitlab for internal communication within the two teams.
But GNOME does it better. The Design team's Gitlab has dozens of projects, ranging from apps and system mockups to resources helpful for creating mockups to sounds, icon references, and more.
These work as a somewhat centralized source of design information and references; there's a place to see how other designs intended components, and from which developers can take inspiration.
And, though I wouldn't exactly call it a complete design system, there's also SVG files with templates of various design elements, plus icon templates, and more.
The GNOME Design team also holds monthly calls to discuss the status quo, and - even better - the notes for each call are stored in a design-calls folder within the - you guessed it - same GitLab team.
By contrast, the KDE VDG GitLab project only holds two projects, Issues and Device Assets.
The former is used for Design discussions, and it details a precise decision-making process. For each issue, there's a facilitator assigned by the team, and there's a discussion for three weeks. At the end of that, a decision is taken either by consensus or by voting (still through the facilitator).
That said, I haven't personally seen this process much in action. Most of the issues are currently hanging: from proposed redesigns, user requests, and so on; only a few are actively in discussion.
The "Device Assets" repository, on the other hand, is completely empty. Whops!
As mentioned, both projects also use Matrix as the official communication channel. That said, it's worth noting that KDE's VDG is also bridged to Telegram, which might make it a bit easier to join if you already have an account there. It sure helped me a lot to get involved.
Design Apps
I've briefly mentioned mockups. Which applications are used to create them? As far as I understood it, both KDE and GNOME are in the same boat here, so I'll make a general overview here.
Currently, there's no clear standard to design applications in the free and open-source world. One appealing option, which is the one I usually go for myself, is Inkscape.
Indeed, you can see that the mockup files provided by GNOME are SVGs, and they also offer inkscape tutorial resources (it does not seem very up-to-date, but still).
However, Inkscape is not the correct tool to do application design. You can't easily add standard elements, such as drop shadows and correct borders, nor a proper way to have templates, and so much more. It's not a Figma alternative.
Then, there's Figma. It's used by some people and designers; as an example, both Manuel and Andy use it, on the KDE side of things. It's the status quo for this type of things, but it's also proprietary, and we would all prefer to avoid it.
Finally, there's Penpot. They're an open-source alternative to Figma, and they're developing quickly; both KDE and (to the best of my knowledge) GNOME are trying to move to it over time, but they still lack many of the necessary resources to replace a tool like Figma. However, the team is very reactive, and they're collaborating with the KDE Next project to address those missing features.
If you want more details specifically about KDE Next and Penpot, I've talked more about it in my video about KDE Next specifically, but you can also go check Andy's youtube channel for more.
Guidelines
Both KDE and GNOME have something called Human Interface Guidelines. These are supposed to contain some reference information on how to develop designs for their respective ecosystems. Cool.
KDE's guidelines have been recently rewritten by Nate Graham, and has been then further developed by many others.
It begins with some "philosophical" instructions (what makes a KDE app a KDE app, how to be simple by default but powerful when needed); then, the categories you'd expect: layout and navigation, displaying content, getting input, communicating status changes, text and labels, icons, and accessibility.
If you were wondering what makes a KDE app a KDE app, it's allowing for diverse workflows and adapting to preferences, and not being afraid to grow to cover multiple different usecases. Keep these sentences in mind, as you'll see that the GNOME guidelines have a somewhat different take on them.
You can have some fun going through these sections; as one example, the KDE guidelines recommend against distinguishing between "Basic" and "Advanced" in an app's UI. This is because the word "Advanced" communicates nothing about what might be inside that section, and the distinction between "Basic" and "Advanced" depends on the opinion of the user.
GNOME's guidelines also begin with design principles. These are: Design For People (and thus, accommodating different physical abilities, cultures, and device form factors); also, Make It Simple: "resist the pull to try and make an app that suits all people in all situations. Focus on one situation, one type of experience", and "The best apps do one thing and do it well". This seems radically different from KDE's principles.
GNOME's guidelines also include tools and resources. The former include applications to find icons, select text styles, preview app icons and symbolic icons, and a reference app for the color palette. There's also a GTK inspector (like the web browsers ones, but for GNOME apps), and a demo application for libadwaita. Ah, and the above-mentioned app SVG templates.
The rest of the guidelines (that is, most of them) are divided between a subsection called "guidelines" (yes), "patterns" and "references". Unsurprisingly, the patterns very closely reference libadwaita, the library that GNOME uses to build applications. They also have very nice graphical elements to indicate the various chapters.
App Ecosystem
Let's talk (third-party) app ecosystem. Though this topic isn't strictly about design, its quality is often a direct consequence of it. Are available APIs easy enough for new developers to start using? Do they have sensible designs out of the box? Are developers able to build more complex apps with it?
This will be the topic of another video, but quickly: KDE offers a library of application components called "Kirigami". These include front-end UI elements from pages, to buttons, actions, drawers, cards, form layouts, inline messages, and so on; but it also includes spacing, colors, typography, and so on.
Similarly, GNOME offers a set of components called Libadwaita. This also comes with a variety of UI elements, which are often direct implementations of their human interface guidelines. Libadwaita thus makes it real easy to create third-party apps following the GNOME design.
So far, I feel like GNOME is somewhat winning this battle, featuring a wider selection of applications with consistent design. They've also started an initiative, called GNOME Circle, which is used to give direct feedback to third-party app developers to steer them toward the GNOME way to do things, and rewarding them with more resources.
Telemetry
Finally, to do design, it's often very useful to have some data about how users interact with a certain system. This is called telemetry, and proprietary applications have no trouble inserting it everywhere; open-source projects, less so.
KDE has an opt-in telemetry system called KUserFeedback. User-wise, it's a slider (again, off by default) that lets you choose how much to share with KDE, and provides a list of exactly what is being shared.
Developer David Edmunson shared a few conclusions that were obtained thanks to these data. As an example, one time a developer claimed that "no one is using a screen smaller than 1024x768", but was then quickly proved wrong by the data. Similarly, "no one still uses only OpenGL2" was disproven by a 5% that were.
It also allowed KDE to track the usage of X11 vs Wayland; as you know, Plasma 6 recently switched from the former to the latter. Did the user agree with this, or had to switch back? Well, overall, the percentage of Wayland users is only at 45%, though it's increasing over time:
However, if we filter for Plasma 6 users, we see that only 20% decided to change the default from Wayland back to X11.
There are a few criticisms of this method too. One that I have myself is that the VDG does not really use it, or only uses it extremely rarely. For privacy, only a few members have access to the data (as an example, I don't).
Secondly, it's really hard to add new data to be tracked; to the users who already opted-in, what should happen? Should they be automatically opted-in to the new tracking too (which wouldn't be honest towards them)? Should they have to go back to settings to change the setting? Should they be notified and asked upon upgrading? It's not clear.
GNOME had a few more mixed feelings about telemetry. A while ago, they published a script called gnome-info-collect that users could intentionally download and launch on their systems to share - as a one-time favor - some data to GNOME. Two and a half thousand people did so.
Turns out, most of the people who run the script use Fedora (Arch is a distant second) and use a Lenovo computer. Half use the Online account's features, mostly to connect to Google. 93% have Flatpak installed, and 73% use Firefox as their default browser. Also, only less than 17% did not have any extension installed.
They also looked for which extensions were installed, and which apps the user had on their systems. The most common ones were GIMP, VLC, and Steam.
Overall, this feels like a very interesting exercise in data collection, and one that might even result more useful compared to KDE's current telemetry system. However, for it to continue to provide feedback, it would have to be run once in a while. There are benefits and issues on both sides, I would say.
Conclusions
Overall, I'm not completely happy about the status of the KDE design team, and I think we have something to learn from GNOME in this aspect. I hope that we will be able to attract more design-first contributors, and maybe the Plasma Next initiative by Andy, who's also working on better Figma / Penpot design kits, might help that.
