“Design by committee” is rarely fun or productive. We’re in the middle of redesigning a small but critical service for our students and faculty. The goal is to make it simpler, more elegant, and require less decision-making on behalf of the user. Let’s just give them what they want.
The service is also used heavily by back-office staff, which presents a challenge. Then there are other staff who might want to promote other helpful services, albeit with good intentions, within the context of the one that we’re trying to simplify.
In the spirit of agile development, we always try to identify product owners and make them responsible for setting direction and prioritizing the backlog. In this case, we have not pinned down a clear product owner. To complicate matters, we have many stakeholders, but none solely looking out for the interests of the primary customers.
After sending out the first demo of the newly designed service and exchanging a few comments via email, some concerned staff wisely suggested that we meet. I asked for interested parties from among the stakeholders and got positive responses. I scheduled the meeting for the next day and I decided to run it myself. Like many organizations, we have a culture of less than effective meetings. I’m likely as guilty as the next person. Thanks to our history of agile planning sessions, Kanban work, and agile process study, I knew we could do better, though I didn’t know specifically how to run a good design meeting.
I did know that I wanted it focused, simple, pain-free, and even fun if possible. What does one call such a meeting? Google eventually led me to the magic words “design critique”. And from there I found Jake Knapp’s excellent article “9 rules for running productive design critiques“. In his article, Jake cites Scott Berkun’s essay, “#23 – How to run a design critique“. I was familiar with Berkun from his project management book, Making Things Happen. Berkun’s essay is certainly worth reading, but I owe Knapp for his succinct, last-minute inspiration and guidance.
As I only had 10 minutes before I’d have to sprint 4 blocks to the meeting, I skimmed Knapp’s article. By the time I got to Rule #6, Write It Before You Say It, I had a pretty good idea of how I wanted this to go down. It struck me that the principles of running a design critique don’t differ much from the composition of any good meeting: establishing some shared vision, stating the goals of what you want to accomplish together, making sure everyone gets a chance to be heard, engaging in focused, respectful discussion, making some decisions, leaving with some tasks, and laying a plan for the next meeting. I’d attempted bits and pieces of those and certainly recognized when they were missing.
That said, there are a couple of Knapp’s rules that I might consider more specific to the design process, such as identifying the design owner and avoiding pitching a design in the meeting. Rule #8, Don’t Design In The Meeting might not seem design-centric at first, but real estate developers, project managers, and financiers wouldn’t attempt to draw up blueprints during a meeting or give the engineer pointers about structural capacity… would they?
So I walked hastily to my meeting, armed with at least the beginnings of a plan. I talked a little about why the redesign. I broadly laid out my goals. I gave everyone 3 extra-large Post-Its and 5 minutes to write three critiques, concerns, or advantages of the current design. We discussed. We grouped and prioritized. Then we compared those against the redesign demo. I came away with design tasks. A couple of others went away with usability study tasks. It was productive. And it went well. Heck, it was even a little fun.
Next time, I’ll do some things differently. I’ll lay out my goals more specifically. I’ll ask more questions up front to make sure that we’re on the same page (even though I got a clear sense that everyone ultimately was wiling to prioritize the customer’s needs over their own. We have some cool people like that). I’ll be clearer about the need to prioritize the tasks, and maybe employ some dot voting. I’ll wrap up quicker and get confirmation that everyone feels heard and feels good about what we accomplished. Next time it will be better, and that’s iterative and incremental.
More Power Later 