Canonical
on 13 January 2011
’Appropriation’ – the taking of a product and using it for one’s own purposes, in ways unintended by the product creators – is implicitly at the core of the philosophy of opensource, because openness provides for change, adaptation and innovation.
Design specifications
Last year, I conducted several research projects to understand how developers work and how we can add design and a concern for user experience to their already very complex efforts. I’ve published some of the results already, for example, those coming out of our study of Empathy.
One of my inquiries asked how developers use design specifications. This research produced very rich results. We realized that developers’ approaches to our design specifications documents varied quite a bit, and often the documents were not made as central to the developers’ work as we had anticipated. So far, we’ve been able to characterize four different ways in which developers use our documents. These illustrate tendencies and not necessarily rigid approaches. Yet, they help us understand developers’ frame of mind when they deal with design information.
1) Some developers read meticulously specifications and try to figure out what the designer had in mind. These developers like to work closely and collaboratively with individual designers.
2) Some developers have a more organic approach to understanding specifications. They use them in combination with current conversations on chat networks about development topics and issues, and with other conversations that have taken place during past strategic meetings at UDS. They essentially make the written specifications a second resource in favor of what their colleagues and managers say about them. They fit the specifications in a dynamic broader context.
3) Yet other developers almost only look at screen representations of the specifications. They try to duplicate the visual guide that accompanies the specifications or simply to compare existing features of an application to the screen shots included in the document, trying to discern similarities and differences between them. Many of them use specifications documents as a simple reminder of past and current discussions and to get a general idea of what’s expected of them.
4) Finally, another group uses the “try and see” method. These developers implement changes as they see fit and rely on their colleagues to provide guidance once the development has been realized. Effectively, they hardly consider the written design specifications at all but like to follow their intuition.
Research, of course, doesn’t judge what people do because it appreciates that people do what they do for a reason. Furthermore, it doesn’t opine on which behaviour is the best – because people do things in a way that works for them in their situation. What research does is understand the complexity of individual situations and help designers fit seamlessly in people’s contexts and frame of mind what their products offer.
Based on these, and related, results, we have been rethinking our design specs tools and experimenting with new concepts derived from co-design principles, so that these specs become helpful to all developers and enhance their work and not represent merely an external constraint to the work they do.
This is all good. However, the issue is not restricted to our Ubuntu developers. We should not forget that, in the wider opensource community, many developers do not have access to the Canonical, or any other, design team or to anyone with solid design training. They are the developers who work on their own free time and produce amazing software. They have to wing design. Many wish they could access such skills to help beautify and enhance the user experience of their products. These contributors deserve our support.
So what?
To us, the solution appears to be ‘design appropriation’.
Our challenge: how can we create design specifications and design thinking tools that developers can ‘appropriate’, just as mobile phone users started to use their phones to text because it suited their needs even though texting was not considered by the phone first creators to be a very important feature?
How can we design for the unexpected?
Upcoming research this year will be concerned with what developers can teach us about ‘appropriation’ of design.
This represents for us a first step in the investigation of the potentiality of ‘appropriation’ for all opensource. Ultimately, appropriation should be possible not only for developers but for all end-users.
