Free Software Has A Design Debt Problem

And that's not going to go away (without effort).

Because design is really, really hard. It means putting yourself in the shoes of others and seeing not only what they see, but what they don't.

So trained designers have methods and processes they use to manage that task as best as possible.

The ability to make generalised statements about "users" as a class is a skill that one must earn through years and years of practice and experience. Practice and experience that the free/libre/open source software space has way, way, way too little of.

And until that changes, I strongly believe that FOSS has a hard ceiling on widespread adoption.

You Are Not The Average User

"A designer is not the average user" is one of those phrases at the core of good design. For developers, this goes double.

Software designed by developers tends towards being a tangle of UI elements and functionality. Which at best are copying the surface-level look of a popular design trend. And which the programmer somehow insists is perfectly logical.

And a lot of this comes down to the way programmers will begin a project by designing data structures and programming interfaces.

Which means that, when a developers design a program, it's core functionality fits to what makes sense to computers (and programmers). Not what makes sense to users.

A problem that ranges from difficult to entirely impossible to fix.

You Cannot Make It First And Design It Later. You have to start with good design. Otherwise you'll, at best, get mediocre design.

So when I say FOSS has "Design Debt", what I mean is that the space of FOSS software has a significant negative balance of design quality. One that will, even with significant concentrated effort, take years or even decades to get even.

What I Think You Can Do About It

Given the individualised nature of FOSS, I want to focus my suggestions on what an individual can undertake to directly improve things.

If you are a developer, read "The Design Of Everyday Things" for one. And start looking for sources on user experience design and human interface design. Share those resources with the people in your surroundings and try to build understanding of design for yourself to share with others.

You can also go out and find the people in the FOSS space that are already pushing for better design. And amplify their voices.

If you are a maintainer, you can write a design guideline for your repository. And especially: hold contributions to it, just like your code quality standards.

A good starting point is the Gnome Human Interface Guidelines. But if you disagree with those, modify it, or write your own. But make sure you yourself have a clear idea of what "good design" means for your project.

And finally, even if you are only a user and happen to have friends that are self-described "not technical people": Ask if you can do over-the-shoulder tests with them.

Proper Design Testing For Beginners

The rules are simple:

Write down, on paper, the end result of a relatively short task that represents what your tool is for.
Put them in front of the program's initial startup screen, don't do anything else.
Ask them to achieve the goal on the paper, an say all of their thoughts out loud.
You then Shut UP and observe.

Depending on the test this should take between 30 minutes to an hour.

And will quite often be the most frustrating 30-60 minute experience of your life (if you know you know). But even still, it is of utmost importance that You Shut The Fuck Up And Watch.

Write down what you notice, whether that's bugs, unexpected decisions, or especially things that the user does "wrong". Ask if you can record the user during the test so you can review footage.

Then at the end perform an interview. Ask questions about what you noticed, or to fill in a form you prepared beforehand.

Important: Don't get defensive, no matter how much you like the tool, especially if it's something you made yourself. If you disagree, just don't write it down.

I can guarantee that following this process, even just once, will result in a whole heap of new issues you can throw at the repository.

If you are a maintainer, it might be worth putting out a call for your community to do this. A kind of "testing drive". And it might also be useful to add a standard repeatable "test report" issue template for others to report on their results.

After all, the open source community has one major advantage: It is huge, and it is willing to share.

It also has one major disadvantage: it is insular. And I strongly believe that the way we can solve the latter is by using the former.

Almost everyone good with computers has a whole load of friends and family who are completely allergic to computers. Those perspective are extremely valuable.

Finally, If you are a designer trying to work in open source spaces:

Thank you,
Keep doing as you're doing, I trust you on this more than me, which brings me to
If you have any feedback about this post, please tell me by sending me a message at my comment box. (You don't need to make an account, just type in the box and hit send).

I'm open to feedback on any part of this piece. But I'd especially appreciate any resources like links or books to recommend. As well as other actions people can take individually.