Open Design: Mozilla London

On Wednesday night Mozilla London hosted an event on Open Design. I wasn’t there, but thankfully they live-streamed the entire event, which was fun for me as I got to confuse people as to whether I was in the room! The videos will be up shortly, but in the interim here are my notes (also check out the detailed twitter conversation from the evening).

Over the course of the night, a number of recurring themes (and a couple of dichotomies!) emerged:

Not open or closed, but ajar: Tom Hulme, OpenIDEO

Perhaps my favourite phrase of the evening came from Tom Hulme of IDEO (if anyone can nail a good phrase, it’s them). He talked about designing to be ‘ajar’: most projects cannot be entirely open, but they shoudn’t be entirely closed either. I also liked his phrase of allowing ‘time and oxygen’ to incorporate serendipitous ideas.

Reasons people contribute to an open source project/online community: slide from @thulme at #DesignOpen. By @klakhani pic.twitter.com/cVHZjeLZlh

— Hadley Beeman (@hadleybeeman) April 10, 2013

While discussing Convergence and the Ubuntu community, Ivanka echoed Hulme in stressing that secrets, while necessary, are an overhead and can undermine goodwill (for example if you can’t explain to the community why the brand looks the way it does because of strategies in the process of being implemented).

Desire paths and (real life) community building: Drew Smith, Tobias & Tobias

Drew Smith of Tobias & Tobias talked about open design with communities. Continuing with the list theme of the night, he suggested the following points:

1. Choose one problem and solve it. Finding an easy win helps build good will. One example was a Tadcaster community lamenting no events for elder people. As it turned out, they still happened, it was just that no one knew about them as there were no more community papers. Easy win: create an events web page to list them all. Easy, and able to be slowly scaled up (see #4)
2. Reflect the swagger of the community and avoid identikit solutions
3. Be inclusive (consider digital literacy, availability)
4. Allow people to self-assemble. Rather than build a big solution (a big website etc), build little bits that can be built on.

It’s not a bug, it’s an idea!: Tony Santos, Mozilla

Tony Santos discussed the Mozilla advocacy system, such as how they attempt to embed designers in the dev community to both help with understanding and gather feedback. However, more interesting was how they use Bugzilla to not only track reports but get ideas, namely by mining the conversations. As one audience member pointed out, it seems a long-winded way to get inspiration, but it’s still an interesting concept for repurposing existing data (much as Tom “I’m embarrassed to admit that I’d never done a search terms dump” Hulme used search results as a means of checking for areas the Open IDEO site needed to cover).

Being a Designer in an Open Source Community: Ivanka Majic, Canonical and Leisa Reichelt

Both Ivanka and Reichelt were brought in to help design in a tech-oriented open source communities (Ivanka works at Canonical who is the main proponent of Ubuntu, and Reichelt was brought in with Mark Boulton as a consultant for Drupal 7).

Both espoused similar points:

• You need to be able to explain and advocate why a design is done in a specific way (and ensure developers have the right language to be able to question its feasiblity)
• It will affect the way you work for the better. Reichelt has adopted a lot of the strategies
• Let people do what they’re good at (be it designers doing high fidelity details or developers implementing features)

However, their experiences have been markedly different. While Ivanka has had reaonable success with having pretty much whatever was necessary developed, Leisa grappled with getting the right level of detail for communicating (what she presented was too abstract) and not getting the right information back either (namely if a feature was so problematic that it might be better canned).

"When designing the more documentation you write the more likely it is to be complete fiction" #designopen @leisa

— Tom Hulme (@thulme) April 9, 2013

One thing that perhaps wasn’t made explicit (though Leisa mentioned it later) was that how designers are brought into an open source system can have a huge impact. While Ivanja is a paid and evangelised part of the Ubuntu system, Reichelt (and her design collaborator Mark Boulton) were brought in as contractors/consultants, and arguably were in less of a leadership role. (As someone who follows the Drupal community, Drupal 7 was also something of a turning of a large ship in that not everything succeeded, and in fact some major failings of the CMS as it stands—weird hardcoded elements, bad media handling etc—are being addressed in the upcoming Drupal 8).

Jen Simmons has spoken of similar issues with the Drupal community in a recent podcast.

A taxonomy of openness? Kwantecorp

Over the night, it was repeated that openness is not the same, be it as a consultancy considering open design, doing open design as a company behind open source software, or a consultant working for an open source community.

Lison-based Kwante continued this thread. His company is not only attempting to engage with openness on a number of levels, but also try to communicate these different levels. They were as shown:

Opening up the Open Design Space through Case Studies

As someone who is sometimes critical of the lack of actual examples shown at conferences and meetups, I was heartened at how the stories from Open Design came from the coalface of successes and failures. Thanks to Mozilla for hosting the event and opening up the livestream for those further afield than London (open design and open access!).