In the last post from our design team, we defined two facets of open design thinking: open source design and designing in the open. We’ve been experimenting with both of these ideas in our design processes to facilitate collaboration and to increase feedback and dialogue at every step along the way.

Big questions

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? It’s difficult to trace the influence of our design team in code repositories on Github. Front-end code like HTML and CSS may be the closest we get, but it simply doesn’t capture the other laborious hours spent on information architecture, user experience or visual identity. Nor does it expose the broader design solutions developed for the problems present in each project. Despite the immense amount of design effort that goes into making our open source tools and projects uniquely user-friendly, it often gets overlooked, especially in grant requirements.

How do we share our design work both internally and externally? Although we use Dropbox internally to share design projects amongst the design team, files often aren’t organized clearly for our own purposes, let alone the public. We don’t want to have to maintain duplicate versions of files (which are often massive in size) in order to share our work externally. We also need to be able to show and track changes in design files as they evolve.

How do we license our design work in a way that is conducive to open design? Licensing our work isn’t something we’ve had to do before, but it becomes a necessary conversation if we’re serious about opening up our design work and allowing other people to remix and reuse it.

Evolving our process & current solutions

We’ve put some time into addressing these things as we work toward adopting an open design ethos, which has changed our processes somewhat. Since this is new to all of us on the design team, we’ve had to try a few different things out before getting into the rhythm of our current workflow.

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.

All of these different tools split our process across several different channels, and none of them communicated with one another. Our work was not made easily accessible outside of the design team, with the exception of our code in Github.

Open tasks

One of the first things we did was to migrate from Trello to Github issues for managing our design tasks. We create issues for design tasks under their corresponding project repo on Github if they have one. For tasks that don’t fall under any particular repository (like business cards, social media graphics or TransparencyCamp signage), we create issues under a sunlightlabs/design repo. All of these issues are labeled as design, making it easy to identify which work is the design team’s responsibility.

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. Questions, conversations, notes and in-progress design work can be documented this way under each issue, made accessible for reference later.

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. This tool is open, and anyone can view what we have lined up to work on (with the exception of issues from a couple of private repos).

Open work

Aside from posting relevant in-progress design work in Github issues, we also needed a central place to share final design work. Previously we’ve tried to share wireframes or comps in Trello, Dropbox or Google Drive, but had our developers repeatedly coming back to ask for a reminder of where they lived — a problem caused by having our work strewn across too many channels. We’re now experimenting with adding our design work directly to the project’s repo on Github, under a directory called /design.

Before we did that, we first had to take a close look at how we organized our internal design files, which proved to be disruptive to our process — in a good way. It forced us to create a proper system for organizing our design files in way that would be clear both internally and externally, and address outstanding issues like naming conventions for files and versioning of files going forward.

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.

By sharing our work this way, we ensure that our developers and other team members always have the latest version of our design work in one central location. Using Github and git also inherently provides a solution for versioning of files. We’ve started committing design work to some of the projects we’re working on.

Open licenses

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.

We asked around and 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. The Creative Commons license we chose (Creative Commons Attribution 4.0 International) allows for sharing, reusing and remixing of our design work for any purpose, as long as the Sunlight Foundation is credited somewhere. It’s the same license as the one on the Sunlight Foundation website — what you’re reading right now.

An example of open licensing in practice: In this project repo, the design work is licensed under Creative Commons, while the code is licensed under MIT. Both of these are mentioned in the README for clarity.

Open invitation

We’d like to invite you to take a look at how we’ve opened up our design work thus far:

• View our design tasks on our Waffle board;
• explore the design work we’ve committed and filter through the design conversations in the Github repo where we’ve been practicing these processes; and
• browse through some of our design issues to see what our non-project specific work as Sunlight designers looks like

Moving forward

The design team still has a lot of work to do to fully embrace open design, but we’ve begun making a lot of progress by opening up our processes. We’re constantly learning, improving and refining how we share our work with the community.

We’d like to learn more from other people that seem to be doing open design well, like CFPB (whose Github repos are brimming with design discussions and collaboration) and the Open Design Foundation (who may have first coined the phrase “open design”). We’d like to explore other tools and technologies that could help to greater facilitate open design — like Github’s LFS support, which would let us version large files (think Photoshop PSDs) within our repos. Or we might try out git-annex, which would let us store files where we choose without being bound to a proprietary format (thanks to Eric Mill for the tip).

In the future, we’d like to be able to document and share even more of our work, especially that which doesn’t come in a naturally shareable format, such as design research or user testing.

This is just the beginning — we hope to eventually be as transparent with our design work and design processes as we’d like our government to be.