This is the talk I gave at the Open Source Design Devroom at FOSDEM 2017
You can see the slides at
https://belenbarrospena.github.io/fosdem2017
You can see more information in the FOSDEM website
https://fosdem.org/2017/schedule/event/osd_beyond_fancy_logo/
What follows is the talk script.
=============================
Hello everybody,
Thanks for coming to this talk about design beyond logos. My name is Belén, and I design software for a living.
Designing software is not a single thing. It's a set. A set of activities. These are they:
- Exploring user needs, problems and context
- Producing content
- Deciding on the system structure and behaviour
- Determining the navigation mechanism and interface components
- Designing how the interface looks like, its layout and graphic design
Designers of software are not a single thing either: we are also a set. We are a set of roles:
- User researchers
- Content editors
- Information architects
- Interaction designers
- Visual designers
Some people will tell you there are things missing from this list, things like user experience designers, service designers and design strategists. But I personally believe this list is a good compromise between what actually happens when you make software and design industry bullshit.
It is important to clarify that the above is not a list of people: it is a list of ROLES. And the roles can be performed by a single person, or by different people. For example, in my job I play the roles of user researcher, information architect and interaction designer.
This is how the set of design activities maps to the set of design roles:
- User researchers explore user needs, problems and context
- Content editors and information architects produce content
- Information architects and interaction designers decide on the system structure and behaviour
- Interaction designers determine the navigation mechanism and interface components
- Visual designers design how the interface looks like: its layout and graphic design
Five years ago, when I first got involved in FOSS, something quite extraordinary called my attention: the bulk of the people calling themselves designers seemed to be spending all their time on a single design role. Can you guess which one it was? Visual design. All design effort seemed to be going into establishing how the interface should look like, its layout and graphic design.
Today, five years later ... things are still the same.
Why aren't FOSS projects paying attention to their users' context and needs? To the content and navigation of their websites? To the structure and behaviour of their applications?
You might look at me sternly now and say: that is not true, Belén. We do pay attention to our users' needs and context, and to the content, navigation, structure and behaviour of our software. And I will reply: no, we don't. And you will reply in turn: yes we do. And like this until the end of time.
To break down the tie, I must provide you with evidence. And to find it, I turned to the Open Source Design jobs board. This jobs board aims to match FOSS projects with designers. If a FOSS project needs some design work done, they submit this form, their "job" is published on a public list, and that way designers can find it and volunteer to help.
If FOSS projects were paying equal attention to all design activities, we would expect to find similar numbers of jobs for the different design roles. But is this what's actually happening? Let's see.
Between February 2015 and January 2017 the jobs board received 61 jobs. The titles used in the jobs do not necessarily match our role classification, so I went through the job descriptions and extracted the role implicit in them.
Of the 61 jobs, 6 of them were actually asking for front-end developers. "Front-end developer" is not one of the design roles in our list, so I took those out.
Of the remaining 55, 38 were unequivocally asking for help establishing how the interface should look like, its layout and graphic design, which is what visual designers do.
For an additional 14 I quite couldn't make up my mind about the main role they were requesting. This was because they were being purposefully vague. Or because they were sending very mixed signals.
I could only find 3 jobs where the emphasis was clearly not on the visual design role.
I found 13 instances of language connected to the non-visual design roles:
3 jobs mentioned the word "usability". 2 jobs mentioned "information architecture" 1 job mentioned "human computer interaction" 1 job mentioned "user research" 1 job mentioned "usability test" 1 job mentioned "user testing" 1 job mentioned "interaction design" 1 job mentioned "content strategy" 1 job mentioned "human factors" 1 job mentioned "user centered design"
But these 13 instances happened only across 6 jobs. A single job was responsible for 7 of them.
By contrast, 33 jobs included the word "logo".
27 jobs had specified a role that unequivocally referred to a visual designer:
Logo designer 19 Icon designer 5 Brand / Identity designer 1 Graphic designer 1 Visual designer 1
1 job asked for an interaction designer. No jobs asked for a user researcher, a content editor or an information architect.
If we accept that the jobs submitted to the jobs board are somehow representative of the design situation across the FOSS universe, we must conclude that FOSS is paying very little attention to user research, content production, information architecture and interaction design. FOSS projects are mainly worrying about how they look like, and very particularly about their logos.
If FOSS projects were a person, he would come across as quite vain.
But is FOSS really like Justin Bieber? Well, I really don't think so. But then, why is FOSS not paying any attention to users, content, structure, navigation and behaviour? Why is FOSS not investing any effort on the non-visual aspects of design?
This is a difficult question, and I honestly don't have the answer. Finding it is a job that we need to undertake together, as a community.
But I suspect that the answer to this question might be in some way connected to another question: Why should we invest on the non-visual aspects of software design in the first place? And this one, I think (I think) I may be able to answer.
But in my answer I will not talk to you about return on investment, or user engagement metrics, or market share, or brand awareness. Those are the things designers use to answer this question in commercial software settings. But those things don't translate particularly well to the free and open source software context.
I am going to tell you a story instead. It's a story about a logo, but it has nothing to do with software: it has to do with yoga.
Two weeks ago I came back from India. I spent 4 months there, in a city in the southern state of Karnataka called Mysore. I went to Mysore to study yoga in a very famous school: the K. Pattabhi Jois Ashtanga Yoga Institute.
Mr. Pattabhi Jois passed away in 2009. His family now runs the school, and let me tell you: they are doing pretty well. Their school is incredibly expensive, is completely full, and it has also diversified into new lines of business, like yoga apparel. The Jois family now sells things like yoga pants, and t-shirts, and bags, and they also make cotton rugs.
You see: ashtanga yoga is a sweaty practice, so if you do it on a standard yoga mat, it gets slippery. To stop you from slippering on your own sweat (how disgusting), you put a thick cotton towel on top of your mat: a rug like this one.
When the Jois family launched their yoga apparel brand, they asked one of their students, who was a visual designer, to make them a logo. And the visual designer came up with this. He took inspiration from the Tripundra, a sacred mark of Shaiva Hindus that Mr. Pattabhi Jois often wore.
The Jois family loved the logo, and they quickly proceeded to print it on labels, and stick the labels to all their products: their pants, their t-shirts, their bags and, of course, they also stitched it to their cotton rugs.
Only when they put the logo on the cotton rugs, and students started to turn up to class with those rugs, they realised they had a problem. When stepping onto their rugs, students were putting their feet over the sacred Tripundra symbol represented in the logo.
In Hinduism, feet are considered dirty, and stepping on a sacred symbol is one of the most offensive things anybody can do. And there you had all those hundreds of yoga students stomping all over the venerated Jois family symbol.
You might be wondering: why is she telling us all this? Well, because this is exactly the kind of thing that happens when you do visual design only. By removing the non-visual design roles you are basically removing the people who are responsible for user-centered design. You are removing the people who are skilled at thinking of software from the perspective of the people who use it. You are removing the people that can help you spot and prevent problems in your software before you build it. You are removing the designers who can help you figure out that putting the sacred Tripundra on a yoga rug is really not a good idea.
Once you have stitched the Tripundra on the rugs, your only choice is forcing a workaround on your users. In the case of the Jois school, students were forced to remove the label from their rugs and were denied entry to the school until they did so.
The Jois family command great respect from students, and they were all willing to remove the pretty label from their brand new cotton rugs. Unfortunately, we do not command the same respect from the users of our software. We are in no position to enforce workarounds on them. Our users will vote with their feet and abandon our software instead.
So this is why we need to invest in the non-visual aspects of design: because they happen to be the user-centered aspects of design. They are the kind of design that will help us build software that make sense to the people who use it. They are the kind of design that will help us engage users not as passive recipients of the technologies we make, or as bug reporters, but as equal partners in the process of making free and open source software.
Without this partnership with users, without this true shift to user centered approaches, free and open source software will never see widespread adoption, will never stand a chance against commercial software.
We know making software in a user-centered way is not easy. Heck, we do it for a living! We know it's bloody hard. But you don't have to do it alone. The Open Source Design community is willing to help.
So if you are a developer who wants to bring user-centered approaches to a FOSS project; or you are a designer who wants to contribute beyond making logos and colour palettes, reach out: we want to hear from you.