Feedback, Fidelity, and Edge Cases
Imagine you’ve got an idea about how a feature could work and design a few mockups to help visualize it. Interactions are rudimentary, and odd scenarios haven’t been thought out yet, but that will come later. You just want to know if the concept is good.
But when you shop it around, someone asks an edge case question.
You: Here’s a mockup of a messaging system between doctors and patients. It works much like an instant messaging app. Is this an easy and safe way for doctors and patients to contact each other?
Engineer #1: Wait, how would this work if an assistant used it to answer messages on behalf of the doctor?
You: I’m not sure yet, is that a common scenario?
Engineer #1: No, but it’s possible, so we have to plan for it.
You: Ok, well we’re just discussing the basic idea right now.
Engineer #1: Oh right, let’s continue.
Engineer #2: Wait! What about searching through archived messages?
You’ve barely started to shape the idea when a coworker asks a question meant for way later. Momentum slows because someone gave feedback meant for a different design fidelity. Even worse is when it changes the mindset of others and they chime in with more edge cases. Products can quickly lose focus when the team tries to solve too many things at once.
Everyone has the potential to ask the wrong questions at the wrong fidelity. At Canfield, a few of our engineers have this tendency. To an extent, I can’t blame them. They want to know how the entire system should work before they start coding. They don’t like writing code twice, they want to get it right the first time. A noble ambition, but when they ask edge case questions too early, our meetings devolve into a series of peripheral discussions focused on small details instead of the core product experience.
What’s The Solution?
I don’t have the definitive answer, but after working with my team for a few years I’ve had some success by doing these things:
- When leading a design critique or demo, I check with the bosses beforehand to ensure I have ownership of the meeting. Essentially I reserve the talking stick.
- I write an agenda with bullet points explaining what aspects of the design we are and are not discussing. The agenda is sent with the meeting invite.
- I stand up for most of the meeting. This helps me direct discussions when I need to.
- If I sense the meeting drifting off topic, I interrupt and refer back to the agenda. Some folks can’t resist interrupting, so I interrupt their interruptions before they steal momentum.
- As the meeting progresses, I periodically announce how much time we have left in relation to how much we have left to cover. If we’re falling behind, this helps catch us up.
These are all pretty basic things, right? Doing these things means brainstorming sessions are possible. Ideas aren’t undercut before they have wings. We cover more ground on the core product experience. And edge cases are always addressed, but at the appropriate fidelity.
Further reading: