Open Design for Civic Hacks

To designers and design-oriented readers: your corrections and clarifications to the content of this post will be much appreciated.

Like many posts on this blog, I’m not really qualified to write about the topic. Today's topic is open design. I’m not a designer. So, part or much of what I write here may not make sense to a designer or others deeply involved with design. But after reading two Sunlight Foundation posts related to open design, it seemed like NE Wisconsin civic hackers should know more about this topic and consider incorporating open design into projects that we work on.

So what is open design? According to Wikipedia, it is “the development of physical products, machines and systems through use of publicly shared design information.” A longer definition from the Open Design Working Group on GitHub is:

“Open Design is a design artifact project whose source documentation is made publicly available so that anyone can study, modify, distribute, make, prototype and sell the artifact based on that design. The artifact's source, the design documentation from which it is made, is available in the preferred format for making modifications to it. Ideally (but not exclusively necessary), Open Design uses readily-available components and materials, standard processes, open infrastructure, unrestricted content, and open-source design tools to maximize the ability of individuals to make and use hardware.”

The Sunlight Foundation post “What is open design?” introduces their readers to the concept and explains why Sunlight is using this approach to design.

“Open design...means sharing solutions, process and assets and gathering feedback from fellow designers, the design community and nondesigners alike...We use open source technologies to produce our tools, open source the code that we write for others to use and advocate for the same behavior from government. Open design aligns well with our organizational agenda for transparency in government. It also promotes our broader institutional expectation that an open and collaborative process will always produce better results than working in a silo...We see two facets to this type of thinking: open source design and designing in the open... 

Designing in the open means using a public platform to show your work, process and mistakes and to collect feedback and dialogue around designing the right solution. In a world where there is access to those solutions, there should be access to process as well...It exists to craft the most appropriate solution to a problem, given the goals and constraints of a project. Often, we intake those requirements at the front end of a project and then work with those constraints to deliver the best solution we can, only to encounter disruptive, but critical, feedback at the end of a project. Designing in the open attempts to disrupt that process by encouraging engagement and participation throughout the design process...”

In their second ‘open design’ post, “Learning to design in the open,” the Sunlight team explains the process they went through in trying to be more open in the design phase of all their projects. Two major issues they ran into were (1) finding the right tools for an open approach to design, and (2) determining which licenses work best for open design.

“As we began to embrace open design into our own processes, we encountered some challenges that posed big questions for the way we work. How do we make our design presence in our open source projects more visible?...How do we share our design work both internally and externally?...How do we license our design work in a way that is conducive to open design?...For context, before we decided to adopt open design, we shared our work like this: 

-- Track our design tasks and to-dos using Trello;
-- Share design files (sketches, wireframes and design comps) in Dropbox;
-- Provide feedback either in-person or on Slack; and
-- Commit code to Github. 

One of the first things we did was to migrate from Trello to Github issues for managing our design tasks...Getting our design tasks into Github issues has allowed us to accomplish a few things. First, it makes design work in the project more transparent — anyone can see our progress documented as design issues are opened, closed and commented on alongside development issues. It has also facilitated increased discussion of design problems from members outside of the design team by way of issue comments...We’re also using Waffle to manage and track progress on our design issues from all our repos in one central place, with the help of the aforementioned design label in Github...All this took some effort, but we’re now better equipped to publicly share our work. When stages of our design work are in a state ready for public critique outside of the design team, they get added to the respective project’s Github repo... 

The last matter is allowing and encouraging other people to take advantage of our design solutions that are now open. The first step in this endeavor is to license our design work in our Github repos appropriately...it seems that the best way to do this (by popular consensus) is to use an OSS license for the code in the repository, and a separate Creative Commons license for our design work... ”

For now, their approach to open source licenses seems like a reasonable starting point for NE Wisconsin civic hacks that people want to build as open rather than proprietary.

The Sunlight version of an open design toolset similarly seems like a reasonable starting point, especially for those projects that are ‘designed’ by developers. The developers doing civic hacks are usually familiar with GitHub, or if not, they’re quite willing to learn how to use it for working on civic hack projects. My only question is whether there are more effective versioning tools and file storing and sharing tools used specifically for design, in the same way that GitHub was designed as a code repository. One repository aspect that is more of a problem for designers than for developers is file size. A repository business model that works well for multiple versions of code files may not be sustainable for graphics files which are usually much larger and less modular than code files.

A new tool Sunlight is using for their open design process is Waffle, which “creates a free project management solution from your existing GitHub Issues.” Waffle might be useful for both coders and designers, so NE Wisconsin civic hackers may want to check it out.

The Hackaday post “Open Design. It Is The Way.” is referring more to the final product (open source hardware and software) being open than to the design process itself, but it is worthwhile reading if you’re interested in why you might want to spend your time and energy on an open project, rather than on a proprietary one.

It’s difficult to know whether the NE Wisconsin civic hacking community is active enough or large enough yet to benefit from formally using the open design process described by the Sunlight Foundation’s blog posts. We are already using some of the principles, as shown by Mike Putnam’s published ‘design goals’ for his Android app, “Is It Recycling Week?” and by Ross Larson’s ‘guidelines’ for his Pebble Watch recycling app.

Two steps for our region’s civic hackers to consider for moving toward the Sunlight Foundation model of open design are:

1. Use GitHub, and maybe Waffle, for an open design repository on a civic hack project.
2. Do design in the open, including the enabling, encouraging and use of community feedback.

If you’re a designer and have suggestions for incorporating open design into civic hacking projects, please share your thoughts on that. And consider participating in the informal civic hacking meetup scheduled for August 19, 2015, at the Appleton Makerspace!

*****