Last week David and Ryan were working together on a new Basecamp feature that provides a link to a milestone on a to-do list if that list had a related milestone. We’ve always displayed a link to the list on the milestones screen, but we didn’t display a link to the milestone on the to-do list.
After David and Ryan made it work, Ryan wanted to run the implementation by me for a visual review. We ended up making some minor changes to the implementation based on this review and we wanted to share the quick iterative process we used to get there. Ryan and I often work this way either via IM or Campfire.
While the position of the implementation changed, the biggest change was the wording. I think this is a great example of how words can make or break a feature.
Here is the relevant part of the chat transcript with inline images from that conversation (some parts were removed since they weren’t relevant to this post). You’ll see we spent just under an hour on this:
(14:35:37) Ryan Singer:
(14:36:07) Ryan Singer: screenshot i just sent shows milestone dates on a to-do list
(14:36:09) Ryan Singer: the feature is done and working
(14:36:12) Ryan Singer: look good to you?
(14:36:29) Ryan Singer: the date links to the attached milestone perma
(14:40:27) Jason Fried: checking in a sec, sorry
(14:41:14) Jason Fried: Looks good. Have you thought about the use case implications so we’re covered?
(14:41:38) Jason Fried: Like, quick thinking here…
(14:41:49) Jason Fried: If there are 5 lists attached to a milestone…
(14:41:57) Jason Fried: This would say they are all done on the same day
(14:42:04) Jason Fried: all due, that was
(14:42:10) Ryan Singer: each list would be due on the same day, yep
(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
(14:46:22) Ryan Singer:
(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
(14:48:46) Jason Fried: I don’t know if it’s obvious how much softer it is than “on” but it’s better
(14:48:49) Ryan Singer:
(14:49:12) Jason Fried: not as clear as I’d like it, but clearer.
(14:49:16) Jason Fried: May be the best option
(14:49:26) Jason Fried: Still wonder if we can do a little better
(14:50:09) Ryan Singer: different idea, could kill the text label entirely
(14:50:12) Ryan Singer: just “14 Feburary” after the title
(14:50:30) Ryan Singer: not as clear, but more room for interpretation too
(14:50:32) Jason Fried: I think that’s less clear
(14:50:36) Jason Fried: And too grey
(14:50:41) Ryan Singer: yeah k
(14:50:42) Jason Fried: grey area, that is
(14:50:51) Jason Fried: Big compromise that doesn’t really work for anyone
(14:51:32) Ryan Singer:
(14:52:49) Jason Fried: eh
(14:52:52) Jason Fried: not really feeling that one
(14:52:59) Ryan Singer: due by is the best so far
(14:53:09) Ryan Singer: also clearest
(14:53:10) Jason Fried: This could work…
(14:53:15) Jason Fried: “re: Milestone on 10 Feb”
(14:53:34) Jason Fried: My only concern with “due” is that it’s pretty confident.
(14:54:02) Jason Fried: “re: Milestone date” injects some flexibility, but maybe it’s too grey area.
(14:54:26) Jason Fried: (gonna keep all these mocks and this IM conversation for an SvN post)
(14:54:37) Ryan Singer: good thing about “due” is it makes an opinion about what associating w/ a milestone means
(14:54:53) Ryan Singer: heh i also have a post created already full of the step by step of mocking and coding the link too
(14:55:05) Jason Fried: awesome.
(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
(14:57:52) Ryan Singer: i don’t think we’re missign clarity with Due. we just might be makign the wrong assumption for certain people
(14:57:53) Jason Fried: Could give it a little calendar icon treatment too just to reinforce the milestone-ness of it.
(14:58:01) Ryan Singer: don’t want to get too loud with it
(14:58:03) Ryan Singer: otherwise it’ll dominate the list
(14:58:11) Jason Fried: It won’t dominate if it’s small and grey
(14:58:18) Jason Fried: I think we can definnitely make it look great
(14:58:23) Jason Fried: “Due” is a pretty strong assumption
(14:58:38) Jason Fried: The milestone is due, but this list isn’t really due.
(14:58:43) Jason Fried: BTW: I think this addition is great!
(14:58:54) Jason Fried: I just want to make sure we package it up correctly.
(14:59:01) Jason Fried: Subtlety has a lot of meaning here.
(14:59:10) Ryan Singer: i wish i knew better how our customers are using this feature
(14:59:41) Ryan Singer: i’m not sure how much it would change our approach
(14:59:52) Ryan Singer: i just don’t like to go with the generic option simply because we don’t know what to do
(14:59:56) Jason Fried: I think “This to-do list is attached to a “milestone name” which is due on 14 Feb” below the name of the to-do is totally workable and a nice solution.
(15:00:01) Ryan Singer: i’ll try that
(15:00:03) Ryan Singer: and we’ll see how it feels
(15:00:16) Jason Fried: I think it’s generic but clear.
(15:00:21) Jason Fried: And that’s better than generic and murky
(15:00:34) Jason Fried: “This is a list that is attached to a milestone that is due on this date”
(15:00:45) Jason Fried: Generic (in a good way) and clear (in a good way)
(15:00:47) Ryan Singer: i’ll play with it
(15:00:49) Jason Fried: k coo
(15:15:50) Ryan Singer:
(15:17:07) Jason Fried: “See milestone” is a bit too action oriented to me. Are we really saying “see this” or just that you should “know this” ?
(15:17:29) Jason Fried: So I wonder if we can run with something like…
(15:17:36) Ryan Singer: i’m looking for short
(15:17:41) Jason Fried: “Related to”
(15:17:44) Ryan Singer: “This to-do is attached…” is too long
(15:17:56) Jason Fried: “Attached to”
(15:18:22) Jason Fried: “See milestone” asks you to do something and it takes you away from this page.
(15:18:34) Jason Fried: A statement of what it is seems like it may work better.
(15:18:47) Ryan Singer: i like how it includes the word “milestone”
(15:18:52) Jason Fried: Yeah I agree
(15:18:56) Ryan Singer: could do “For milestone:”
(15:18:58) Jason Fried: “Related to milestone: Blah blah blah”
(15:19:05) Jason Fried: “For milestone” could work.
(15:19:18) Ryan Singer: “related to” sounds like we don’t know what this feature is for
(15:19:23) Jason Fried: K.
(15:19:32) Ryan Singer: it does look pretty good tho
(15:19:44) Ryan Singer:
(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
(15:21:13) Ryan Singer: i’ll see how this plays when there is a list description
(15:21:16) Jason Fried: k coo.
(15:21:17) Ryan Singer: otherwise we’re close i think
(15:21:19) Jason Fried: Yes.
(15:21:26) Jason Fried: And I think it will be appreciated.
(15:21:32) Jason Fried: At least there’s a reciprocation now.
(15:21:35) Ryan Singer: yeah. nice little “integration” feature
(15:21:40) Jason Fried: Before only Milestones listed other stuff.
(15:21:42) Jason Fried: Yeah
(15:21:45) Ryan Singer: has a flattening effect too
(15:21:48) Jason Fried: Does
(15:21:48) Ryan Singer: more access to more data from more places
(15:21:51) Jason Fried: Agree
(15:21:52) Jason Fried: I like it.
(15:27:36) Jason Fried: A good lesson… I think these changes add all the value of the original vision, but make clearer and more palatable for more people.
(15:27:46) Ryan Singer: agree
(15:27:49) Jason Fried: Small tweaks too. Mostly words, a little positioning.
(15:30:32) Jason Fried: When are we planning on deploying this?
(15:30:48) Ryan Singer: we can deploy as soon as we feel it’s done. there is no underlying code change. only templates
(15:30:58) Jason Fried: k coo
Eitan Shay
on 24 Mar 09in two words: “k coo.” ! in more than two words: i liked the thought process, the dynamics, the discussion, and the result! coo! :)
kadavy
on 24 Mar 09Very interesting to see that process. I might have lost my cool discussing something so seemingly inconsequential for an hour. Good that the conversation was focused and egalitarian though.
Mr. Darcy Murphy
on 24 Mar 09An entire hour discussing the finer points of a minor but important feature. It’s stuff like this that made me so disappointed when I heard “Don’t spend too much time on it,” for jobs that would take at least a week, regardless if I finessed it or not.
I’m sure someone will complain about this being obsessive, but I can tell you that, whether this is ultimately the right choice or not, concerning yourself with the details is worth it. If it’s not right, it’s not right. Period. Assuming that the mistake will take care of itself and is a non-issue is foolhardy.
Jeff Mackey
on 24 Mar 09I’ve said it before and I’ll say it again: I love this type of post on SvN. Keep ‘em coming.
I find this snippet interesting:
Was this referencing the fact that the new feature was in the wild and you wanted to enhance it, but weren’t sure how or why?
Do you guys have an overall calendar somewhere where you keep track of when a new feature/change is introduced and implemented in your products (like this relatively new to-do’s are linked to milestone feature)?
I only ask because I don’t recall seeing an official announcement about the feature, and just recently noticed it while deep into a project. I love it, by the way. Just curious if there’s a tipping point between a minor feature tweak and new functionality.
Adam
on 24 Mar 09Awesome, I love the attention to detail people have about things, it makes me realise my own “failings” but I’m in the same situation as Mr Darcy Murphy above.
Everytime I’m told something like this or “keep bashing it out”, a little bit of me dies inside. Sadly the people I work with don’t notice the details and won’t allow the time to attention. :( I get this feeling of “sh*t I need to hurry up and get on with this” and made to feel pressured.
Anyway, slightly OT there. good effort guys!
Mark Weiss
on 24 Mar 09It was really cool to see the way Ryan and Jason interacted on the creation of this new feature. The whole conversation was focused on creating something that would be useful and have meaning to the user.
Sure it might seem lame to have an hour long conversation over something like this. But, these little features/tweaks really can add up.
Thanks for sharing.
Chris
on 24 Mar 09Attention to detail is important, but I question whether IM is a very useful medium for the conversation. I have this kind of conversation every day, but usually it takes about three minutes face-to-face. Then again, I’m admittedly anti-IM in general for that very reason (it’s usually inefficient).
kadavy
on 24 Mar 09Having an hour long conversation about something like this when you are judicious about adding new features: okay.
Having an hour long conversation about something like this when you are not judicious about adding new features: annoying.
This brings back memories of having equally tedious conversations at startups that had little to no users. Another case where this is annoying.
So, this conversation is appropriate because 37signals 1) is judicious in adding new features, and 2) has TONS of users, and thus, it counts.
JF
on 24 Mar 09I’m a little surprised by the reactions that an hour seems to be a long time to spend on this detail.
This detail makes or breaks the feature. It may be the most important part of this entire feature. It’s the experience that matters most here.
An hour spent on execution and implementation and placement and copywriting is bargain.
Bill
on 24 Mar 09I really enjoy posts like this. They reveal the magic behind the scenes at 37S. As a developer, it’s really cool to see how you guys handle decisions like this, and even better, it helps me understand how to work with my own team more effectively.
Keep up the good work, guys!
Reuben
on 24 Mar 09This is a great post. I just had a conversation similar to this about text placement on a new feature on our site, and I agree that it is important. Just willy-nilly adding things without some careful thought and before you know it, you have a completely unusable, unreadable or unclear product.
matt
on 24 Mar 09@JF: “I’m a little surprised by the reactions that an hour seems to be a long time to spend on this detail.
This detail makes or breaks the feature. It may be the most important part of this entire feature. It’s the experience that matters most here.
An hour spent on execution and implementation and placement and copywriting is bargain.”
I think it’s because of what is often spoken about on by 37s. Things like “don’t sweat the details…perfect is the opposite of good…just get a draft out there and iterate on it.”
Don’t get me wrong. I think putting some thought into something before throwing it at the wall makes a lot of sense.
JF
on 24 Mar 09I think it’s because of what is often spoken about on by 37s. Things like “don’t sweat the details…perfect is the opposite of good…just get a draft out there and iterate on it.”
We’ve never said don’t sweat the details. We sweat the details until we’re drenched.
But it’s about timing. You don’t want to sweat the details too early on. You definitely want to sweat them at the end. It’s like finishing a piece of furniture. You buff it and sand it and polish it… You don’t do that up front, you do it at the end.
richallum
on 24 Mar 09Works for me. Thought from one of the screenshots that we were getting private milestones which would be really good.
Marc
on 24 Mar 09“I’m a little surprised by the reactions that an hour seems to be a long time to spend on this detail.”
That could possibly be because we don’t all get the luxury of spending this time in our day jobs.
This is a great post though. Love the way there is real team work going on here.
JF
on 24 Mar 09That could possibly be because we don’t all get the luxury of spending this time in our day jobs.
I bet you do, you just have to spend it on other things. The secret to productivity is spending your time on the right things. So much time is wasted on things that don’t matter.
I recognize it’s not easy when the boss tells you to do something that doesn’t matter—I don’t have a solution for that ;)
Andy Kant
on 24 Mar 09Very interesting to see the thought process on making a seemingly simple feature addition.
Keep up the decisions series, I love reading about the rationale that goes into the small details of your apps.
bob
on 25 Mar 09why don’tyou ask your users, many of whom are designers, to give you ideas?
Bob
on 25 Mar 09Oops I meant svn readers
kadavy
on 25 Mar 09@JF I’m likely completely missing something here, but I fail to see how this “makes or breaks” this feature.
I see very little consequential difference between the first iteration and the last. I agree that the last one is better, but I don’t see “make or break.” Maybe you can elaborate?
For a product used as much as Basecamp is, you may be right that an hour is a bargain. If this were a first release of an unproven product, I would say it was major overkill.
steve
on 25 Mar 09Just curious, where were you two guys located during this chat? I have to think this would have been faster to hash over sitting next to each other looking at the same screen. Or even on the phone looking at one person’s shared screen. A transcript is great for posterity, but most of us share ideas more quickly by talking about them rather than writing about them. I bet a verbal/shared screen discussion would have led to more iterations and a faster overall turnaround time.
JF
on 25 Mar 09Steve: Ryan was at his house and I was at mine.
In general we still prefer to iterate over IM or Campfire. We find that having some distance helps us think quietly about things. Plus it’s harder to think clearly when someone’s standing over your shoulder.
But of course you should work the way you feel most comfortable. We’re just sharing how we work best.
kadavy
on 25 Mar 09I’m in total agreement with the notion that distance helps one think quietly and that it’s harder to think clearly when being hovered over. I find that in physical space meetings, people will often turn unprocessed internal thoughts into spoken words – that then somehow become directives – whether the ideas are any good or not. This is one of the main reasons to not have any local clients :)
Chance
on 25 Mar 09These are the types of decisions that constantly go through my head when designing. It’s nice to have someone to bounce ideas off. Many people find these smallish details boring or unimportant, but I find them to be a fun puzzle to solve.
RS
on 25 Mar 09We want our UI to be immediately obvious and give people the right understanding with no process of interpretation or figuring-out. And if one feature is ambiguous, it affects the whole app because the app is a summation of clear points and unclear points. Each unclear experience takes the whole experience down a notch. In our experience, the key factor for clarity is copywriting.
In this case, if we had said “Due by” it could imply that the date is actually a property of the list. Usually when something has a property, you edit that thing to change the property. So imagine a customer sees a to-do list that is “Due by 14 Jun” and they want to change that date. Do they click on “Due by 14 Jun” to view the associated milestone and edit that date? Maybe not. It’s easy to imagine that the customer would edit the to-do list because the date looks like a property of the list. Such a person would discover that there isn’t any date property on the list form. It’s unlikely they would understand that the date is being carried over through the related milestone. That’s a situation full of ambiguity and opportunities for mistakes, and it rests on the fact that “this to-do list is due by…” implies the list has a due date when it doesn’t really. And that implication came from the copywriting.
So one problem with “Due by” was that it over-interpreted or “read too much into” the assocation with the milestone (see 14:58:38 in the chat). Another problem was that the “due date” language wasn’t reflected anywhere else in the to-do UI (see the lead up to 15:20:51 in the chat). These two together could ‘break’ the feature because they created a confusing idea about what the due date was and they set up wrong expectations about how to set or change the date. Confusion + wrong expectations = customers hit dead ends and lose trust.
In the end we chose “Related to: [Milestone name and date]” because it clearly stated the facts on the ground and used the same language as the to-do list edit form. “Related to:” doesn’t over-interpret or over-suggest, and it even gives a clue to some functionality that is available in the to-do list’s edit state by repeating the same key words.
Hope that clarifies how we saw the ‘make or break’ impact of the copywriting in this example.
kadavy
on 26 Mar 09@RS WOW, thanks for the extensive explanation. I see what you mean after a couple more passes on the conversation.
Thanks so much for illustrating this you guys. After working at a couple of startups where I just knew some of the conversations we were having were way too nitpicky (and were ultimately going to contribute to the demise of the organization), I find prioritization of “battles” to be fascinating.
Identifying what “makes or breaks” a product, and what is just meddling can “make or break” an organization.
Nirav Mehta
on 26 Mar 09I really liked the feature. And I’ve spent such time building PlannerX a lot!
But I did not really like the link below the list description. I would prefer the link to be right after list name, above the description. This would make it clear that the list is attached to a milestone. The longer description coming after “related to” is fine and can be easily read.
Essentially, if we keep it right after list name, I know where to anchor my eyes when I am looking for the milestone. Keeping it after description makes me scan through description or look for a “different pattern” to figure out where milestone text begins.
Berserk
on 26 Mar 09Interesting. I’m definitely on the side of those that prefer to do this kind of thing in-person, but it is interesting to see it done this way.
Since you seem to disagree with Joel Spolsky it would also be interesting to see your take on his latest column (on program managers and programmers and their relationship) and how it can affect this type of conversation.
RS
on 26 Mar 09To say something shortly on this topic, teams function best when people think about the work they want to accomplish and forget about hats and titles. We don’t discuss roles or structure at 37signals in the course of our daily work. Instead we look to each other as experts in different areas. There’s a shared understanding that UI and clarity come first. Since UI choices affect code choices, the UI direction comes first. From there, programmers give feedback and everyone iteratively applies their expertise to reach the best result possible.
The “trick” - if there is one - is to see each other as intelligent experts. The more we see each other’s qualities and expertise the easier it is to work together. If you do the opposite and focus on each other’s titles it’s like putting a box on people and then you’re working in an org chart instead of a living team.
Every once in a while tough calls need to be made, and seniority and merit win. For 99% of cases, it’s not necessary to have this manager/programmer push and pull. Better to see that Bob is better at UI and Norah is an infrastructure expert and Luke is great at feature implementation, and to put these layers of the cake together. Then based on whether a given feature is more on the infrastructure level or customer experience level, you make decisions about who’s expertise is appropriate to lead the decision-making.
Ben
on 27 Mar 09Since having read this article & finding it absolutely fascinating, it became apparent to me how the task edit features don’t entirely fit this preciseness of language. Most especially with the “Change” text, whereas other places throughout the site use the phrase “Edit”.
In addition, it appears that both Basecamp & Backpack use the shorter “Edit” phrase as well. Was there a concerted reasoning behind this, or something that changed in process?
Honestly, what brought my attention to this was noting that the Tasks page in Highrise appears to be tweaked a bit with a shift to the right. I even sent a nice e-mail to Sarah about the find, and where the CSS could be adjusted to bring it back inline. And she kindly (which is her absolute norm) informed me that the extra space was for the edit controls.
So all of this brought to mind this post, and I started to wonder if smaller/shorter text would allow for the removal of the padding, preserving the page layout, yet providing the same functionality.
I’d love to hear your thoughts on this now that the details are popping out at me. Thank you.
Mark Bottita
on 28 Mar 09In terms of altering the parameters of established Tasks vs other items:
Ask yourself, when altering a Task anywhere else outside of Highrise, would you say, “Hey, Snicklefritz, could you edit that Task for me? I want to go Friday instead of Thursday?”
Me thinks not. In the real world, you would say, “Hey, Snicklefritz, could you change that Task for me? I want to go Friday instead of Thursday?”
The 37s protocol for this seems appropriate in that it mirrors the way people in the real world actually talk about altering date/time-dependent tasks vs. other docs.
Ben
on 29 Mar 09Good point, Mark. I wasn’t looking at it that way, but I see what you mean. Thank you.
This discussion is closed.