The Basecamp calendar

Kicking off the project

We kicked off the project back in December with a series of sketches on the chalkboard. We then uploaded those sketches to Basecamp so those who weren’t in the initial kick off session could see what was discussed/sketched.

Interacting with the UI

Here’s a thread that starts off with a screencast showing how the UI would work. We often share screencasts when designing UIs so people don’t have to imagine an interaction. The fewer abstractions the better. A screencast is direct and direct is better.

Creating a new calendar

Here’s a meaty discussion with ideas, screenshots, copywriting tweaks, and sketches relating to the UI for creating a new calendar. You’ll see how most discussions about design include a design. Design discussions always benefit from show and tell.

All the discussions in one place

One of the great things about the all new Basecamp is that it keeps all the discussions about a project on a single page. It doesn’t matter if the discussion starts as a message, or a comment on a to-do, or a new design idea, or an event on the calendar – if there’s discussion about it it shows up in the Discussions area. In this project there were 116 separate discussions in all.

1. Do you set time restrictions for your design process or give yourself deadlines for design tasks? If you do not set deadlines, how do you keep working on a feature without going off on tangents.

2. Do you track time for completed Design tasks/projects?I’m assuming you do not, and if you don not how do you improve the time requirements and resources spent on future projects.

DHH

on 05 Jul 12

Pierre, Backpack is still around for existing customers. We’re just not accepting new ones since we’re not actively developing the application any more (but we committed to maintaining it). The new Basecamp has supplanted Backpack for us internally.

Lukas, some times we have time scopes for projects. Like, this should be done in two weeks. But they’re often quite loose. The protection against going off on a tangent is the motivation to ship.

We do not track time on a detailed scale. But we’ll occasionally do a retrospective where we discuss whether a certain feature was worth the, say, 3 weeks we spent on it. But again, it’s a fuzzy process, not based on time sheets (no one likes filling those out).

Eric

on 05 Jul 12

I’m loving these posts. It’s like taking a class in application design.

Thought you’d want to know, there’s a typo under Kicking off the project, second sentence.

@DHH Thanks. So basically existing customers should stick with it if it fit their needs, and potential customers should look at the new Basecamp. Makes sense.

cbmeeks

on 05 Jul 12

@DHH that was a good explanation on time tracking. Wished we lived by there here. We have to track our entire day, down to 15 minute intervals from a task list that is over 2000 tasks long. IE, project meetings, level 2 support, etc.

DHH

Being able to get a peak at how you use basecamp has given us incredible insight into how we can better use it ourselves. Thank you so much for this!

I was wondering what significance the tilde represents at the beginning of a few to-do items in this project?

Thanks again!

DHH

on 08 Jul 12

Casimir, we use tilde to mean “nice to have but optional”.

Zach

on 09 Jul 12

Thanks for the great post. Love the discussions around UI details. My question is: Do you also use new Basecamp as a bug tracker? For example, let’s say that after you released the calendar you discovered that people were actually quite confused by your solution to calendar sharing. What’s your process for logging that as a possible optimization and then discussing possible changes? Do you go back to the original thread and take it from there? Or do you have a special project for “Basecamp UX optimizations”.

This is something we struggle with at my company, so would be interested to see how you handle the discussion post-release.