Transparency in Design

For designers, transparency is really hard. Everyone knows a designer who won’t share her work until it’s ready. In an open tech environment, that’s unacceptable. Everything else is easily grokked on demand, why should design be different? After all, code is in git, READMEs are the norm, chat sessions are logged and searchable, and kanban boards give immediate insight into progress.

As a designer at an open company, here are some ways I’ve navigated the problem.

Use Open Formats

I prefer open formats over closed ones. It’s important to me that my Linux using colleagues can edit my designs just as easily as my fellow designers. SVG has been great for this and is accessible not only through your text editor of choice, but through Inkscape, or Illustrator, Sketch, etc.

When I can, I jump to CSS as quickly as possible. It’s the standard language of design on the web, and usually the intent of CSS can be quickly deciphered (“Oh, so it’s blue with an underline”).

Rough Work, Shared Generously

Sketching is the designer’s version of “commit early, commit often”. So much has been better said on the topic of sketching, so I won’t repeat it here. Prototyping is brainstorming, allowing designers to communicate their early thinking and in such a way that is beckons critique. Sketches are so raw they can be torn apart without hurt feelings.

Ideas present in sketches can be harder to defend, but the exercise of doing so forces us to think through those ideas, often out loud with colleagues around. As is often the case with prototyping, the product isn’t the goal, it’s the process.

Help Colleagues Navigate the Noise

A side effect of designing in the open, with fast iteration, and plenty of prototyping is noise. It can be difficult to decipher the stability of a design, or discern winning designs amongst variations. It’s not uncommon to go through dozens of concepts of A, B, and C ideas.

In my experience, it’s not unusual for non-designers to tune out, sometimes often to an extreme. It can be difficult to gather feedback from disinterested or fatigued stakeholders, especially if they feel as though they’ve lost track and therefore can’t make informed decisions.

I’ve gotten around this by having holding demonstrations of work at the end of sprints and privately iterating my own ideas before sharing them openly, while sharing the rejects. Typically this results in me uploading of half-baked ideas to a sort of ‘scratch’ folder, while putting concrete ideas some place else for consideration. I will often pull from the scratch folder while discussing designs, but they are designs I do not completely believe in.

Critique and Decide in the Open

Lastly, I avoid private critique sessions. Any ideas or feedback captured in private I share with all stakeholders. I have found that conversations become repetitive and consensus is harder to obtain with varied levels of understanding amongst teammates.

The drawback to open critique is that bikeshedding and design by committee can manifest faster if not caught early. This requires strong design leadership and clear roles. The positive and negative here is that by doing all critique in the open, all feedback is welcomed, but not all feedback is useful for pushing a design forward (though, it’s always useful for understanding stakeholders).

That’s it (For Now)!

This is a topic I could write about forever and it’s something that has been covered in one way or another by lots of other designers. Some of the ideas here can be applied outside of transparent environments, and most are just good practice.