How to do design reviews

This week a number of the Telescope developers have been trying to nail down a design for our frontend, such that we can make progress on our 0.6 release, and as Cindy put it, "give @humphd his dog food."

We've spent a lot of time doing code review, and studying how larger organizations do their own reviews.  As the weeks and months have ticked by, I've watched as the students have gotten more comfortable iterating on a piece of code, lost some of their hesitation for sharing their work before it's "perfect," and learned how to frame criticism as a helpful tool instead of something meant to hurt.

Now we're starting to focus on the design, UI, and UX of our app, and we're doing that in the context of our regular development flows: filing issues, creating pull requests, giving and receiving reviews, merging and shipping code.  Immediately we've hit problems.

The first thing I noticed was that design discussions in GitHub didn't move us forward.  While many of our team members could be assigned any of the bugs in our current project milestone, it's not so easy with design tasks.  We all want the final result to be good, and we're invested.  But without some sort of ownership, and ability to make choices, it's hard to even get started.

The next thing I noticed was that many of us (myself included) lack the language necessary to give effective critique of design work:  "This is too dark."  "This is too cluttered."  "I don't like such and so." If I saw our developers giving code review feedback like this, I'd be frustrated, and ask that more actionable feedback be given, such that the developer can move forward.  Surely we owe our designers the same?

I am not a designer.  I have the utmost respect and appreciation for good design, and if you'll allow me to be so bold, I also have good taste.  But these do not allow me to create good designs.  So I reached out to a few of my former Mozilla design colleagues to ask them how they handle design review.  I was interested both in how to give and receive feedback with a design.

1. Cassie McDaniel, who is now Design Director at Glitch, sent me an article she wrote for A List Apart, "Design Criticim and the Creative Process."
2. Darrin Henein, who is now Director of UX at Shopify, sent a fantastic blog post he'd written, "Practical Design Critique: how to give and receive feedback," which tries to capture his learning from working at Mozilla.

Both of these are so well thought out, and come from years of experience designing for large companies and projects.  I was going to try and summarize them, but as I read deeper into both pieces, there's no way I can do that effecitively.  There is so much great advice and perspective in these that I'd encourage you to read them in full as you have time.

As an aside, I've been lucky to work with gifted designers like Cassie and Darrin in the past, and it's such a rewarding experience.  As a programmer and writer, it's hard to describe how amazing it is working with people who are able to connect your code and text into human experiences by designing for the real world.  I hope I'll get to do it again soon.