How much, or how often, should a design idea be discussed?
One of the tough calls to make, when managing a project, is figuring out how much time should be devoted to talking things over. If you are the manager, there are two mistakes that you might make:
1.) You cut off conversation too soon, before the designer has had a chance to defend their idea, or before the client has had a chance to fully articulate their dissatisfaction, or before your programmer can explain why one option would take more time, and therefore more money. You force a decision to be made before all the facts are in. Possibly you kill the conversation just as people are warming up to what would be a brilliantly creative set of insights, if only you allowed more time.
2.) You allow the conversation to go on too long. After awhile, people begin to repeat the same points they made 4 hours before, or perhaps the day before. Your team begins to fear these conversations, which seem to be endless swamps of unproductive debate. The team craves action, decisions, movement, they want to finally be building something, but instead you keep pushing for more information, another round of opinion gathering.
It is difficult to find the right balance. I suspect we all have our preferences about what we consider the right level of conversation versus action.
Over at 37 Signals they’ve posted an extended chat that Jason Fried and Ryan Singer had about adding a new feature to Basecamp. It is useful to see how such a well known and successful team works through their design issues.
(14:42:41) Jason Fried: What are some of the pushback points we’re anticipating?
(14:43:02) Ryan Singer: “i use milestone attachments for [some crazy custom reason] and this doesn’t apply to me”
(14:43:30) Ryan Singer: possibly: “i want dates on my to-do items, not the lists themselves”
(14:44:12) Ryan Singer: i don’t think the first point is a problem
(14:44:18) Ryan Singer: there are always people who bend the interpretation
(14:44:51) Jason Fried: What if the date thing said “On or before March 14”
(14:44:59) Jason Fried: I think the ridigness of it may be a problem.
(14:45:03) Jason Fried: And this could soften that a bit
(14:45:05) Ryan Singer: a bit long, but i like that idea
(14:45:52) Ryan Singer: hm kinda long
(14:46:08) Ryan Singer: becomes harder to interpret too
I know that in such conversations I tend to defer to the designer, and I tend to want to reach a conclusion quickly. Probably because I’ve been in so many, many meetings where someone else forced the conversation to go on for many more hours than was needed, I tend to play the role of the person who is willing to reach a quick agreement. Ryan Singer reminds me of myself, in this portion of the chat, where he seems willing to go along with the “Due by” language, even though he initially disliked it. He seems eager to reach a final agreement.
(14:46:35) Jason Fried: After seeing this the issue I have is the rigidity of it.
(14:46:42) Jason Fried: This list IS DUE on this date
(14:46:45) Jason Fried: Well, not really
(14:46:57) Jason Fried: It’s part of a milestone that is due on this date.
(14:47:07) Jason Fried: So I’d like to see if we can figure out how to present that reality a bit better
(14:47:15) Ryan Singer: good point
(14:47:18) Ryan Singer: ok
(14:47:41) Jason Fried: how about
(14:47:47) Jason Fried: “Due by 14 February”
(14:47:49) Ryan Singer: “Milestone: 14 February”
(14:48:03) Ryan Singer: nice that Due by is shorter
(14:48:05) Jason Fried: Milestone may work. Ties it into the feature.
(14:48:07) Ryan Singer: shorter is better for this flag
(14:48:12) Ryan Singer: even “Milestone: 10 Feburary” is quite long
(14:48:13) Jason Fried: Due by is less rigid than “Due on”
(14:48:15) Ryan Singer: doesn’t hold together as well
(14:48:16) Ryan Singer: yeah
(14:48:37) Ryan Singer: Due by looks pretty good. screenshot coming
But Jason Fried won’t be rushed into a decision. Instead, he keeps the conversation going, even though Ryan Singer was willing to go along with “Due on”.
(14:55:14) Jason Fried: Due is good, but it’s an opinion 5 years after the fact.
(14:55:20) Jason Fried: That’s why I’m pushing back a bit.
(14:55:30) Jason Fried: We’re not introducing attachments today
(14:55:37) Jason Fried: If we were I’d feel better about it.
(14:56:15) Ryan Singer: i think if we don’t go with “Due..”
(14:56:26) Ryan Singer: it would be better to explore moving the link below the title into the list description area
(14:56:30) Ryan Singer: and actually naming the milestone or something
(14:56:41) Jason Fried: right like…
(14:56:54) Ryan Singer: like “For Ship v1 of the Home Page, 14 Feburary”
(14:56:57) Jason Fried: “This to-do list is attached to a “milestone name” which is due on 14 Feb”
(14:57:23) Jason Fried: I feel like we don’t lose anything with that direction.
(14:57:27) Jason Fried: And we gain clarity
If you read the whole transcript, you can tell these two are getting warmed up as the conversation continues – they are thinking hard about this problem, and they are getting deeper and deeper into the nuances. I relate to this chat quite a bit, as it reminds me of so many of the more productive meetings I’ve been in.
Finally, an hour goes by, and Jason Fried keeps pushing them until they arrive at what they both agree is the perfect answer:
(15:20:08) Jason Fried: In the app we say “Attach to…” so I wonder if we should repeat that here.
(15:20:18) Ryan Singer: i would rather change the language in the other places
(15:20:23) Ryan Singer: “Attached to” looks weird here
(15:20:28) Ryan Singer: and it doesn’t fit with the normal expectations of what an “attachment” is
(15:20:36) Jason Fried: K. We don’t want to change the language elsewhere so we’ll consider that one a no go.
(15:20:39) Jason Fried: Umm…
(15:20:46) Jason Fried: “Related to” works for me.
(15:20:47) Jason Fried: Cause it is.
(15:20:51) Ryan Singer: actually the edit dialog says this:
(15:20:55) Ryan Singer: “Does this list relate to a milestone?”
(15:20:58) Jason Fried: Perfect
(15:20:59) Jason Fried: Done
(15:21:02) Ryan Singer: done