Collaborating Skeptically
Dear UOCD student,
This class is titled User-Oriented Collaborative Design, and prior to this module, I always placed the most emphasis on the first word. Learn about your users, listen to what your users say, invent a product your users want, and above all, your greatest asset is the superior domain knowledge your users possess. In reality, the third word is just as important as the first. Yes, it is important to listen to your users, but it is also important to disagree with them, debate them, probe them to back up their statements, and engage with them collaboratively, not subserviently. Only with that sort of back-and-forth interaction is it possible to truly explore their needs, wants, and desires accurately enough to produce a truly effective solution.
When I approached my first co-design session, I came in armed with an idea. In order to address the core problem that teachers couldn’t quickly communicate spills and emergencies to the custodial staff, we proposed the addition of buttons in each room labelled simply “call a custodian”. By pushing the button, a teacher could be instantly connected to the nearest custodian to get efficient help. When we presented the idea to Water Bottle, one of our users, he liked it! Good job us! UOCD done! </sarcasm>
But as I continued to probe Water Bottle farther, something strange started to happen. No matter what alterations we considered, from a speaker grill to a touchscreen, his response never changed from a tentative “that would be nice”. He seemed sincere, he legitimately thought it would be a good idea, but none of my alterations were having any effect on the value he thought it would bring to his team of custodians. To dig deeper, I shifted to more detailed questions, probing how he would use the system, who would benefit most, and why it would be different from the current status quo.
As a result of those questions, it became apparent that the interface I considered most critical and had been spending so much time trying to optimize, the device mounted on the classroom wall, wasn’t really a concern for him. In fact, the entire problem I thought I was solving was secondary to his bigger issue of maintaining communication within his own custodial staff. Once we figured this out, the conversation shifted dramatically, and for the better. Armed with this new problem, in the heat of co-design, we rapidly mutated the idea we came with, shrinking the importance of the buttons and instead focusing on the information he cared most about tracking throughout the building. Eventually, we found ourselves in a completely different place than we started, having used my confusion to expose a deeper truth about him and his life, and converted that truth into a new idea that (with some minor tweaks) stayed with us through our design review.
-
Taking feedback at face value is dangerous because it can obscure the other, more valuable meaning it contains. Often, feedback on an idea is most valuable because it reveals a deeper truth about the problem the idea was born from, and presenting a bad idea is sometimes the only way to get at that truth.
-
It is unwise to shoot for generating “good ideas” too early. Rarely will a first-generation idea actually be a good solution in the lives of your users, but that doesn’t mean a first-generation idea can’t be useful. A useful idea is one that leads to good ideas, or helps extract information from your users. Even though the button is no longer with us, and BuildingView will likely die soon as well, they have served their purpose in leading us to newer, better things.
-
Collaborative design requires skeptical design, simply agreeing with everything your user says isn’t going to make anything useful happen. Dig deeper, ask why, and inspect the answers critically, and your users could learn as much about themselves as you do.
Eric Miller
source document: UOCD: Phase 2 reflection