Last week we shared a behind the scenes look at how we used Basecamp to design the new export feature. This week we wanted to share the Basecamp project we used to design and develop the Basecamp calendar.
The Basecamp calendar
The Basecamp calendar was the last major feature we designed before releasing the all new Basecamp to the world. I wrote a bit about this in the April issue of my my monthly Inc. column.
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.
Initial concepts for adding an event
Here’s a post from Scott sharing some of his initial design ideas for the new event bubble. As you scroll down you’ll see the discussion involves feedback from a few different designers. Some feedback is purely text, some are questions, and others are design “volleys”.
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.
“Involvements”
One of the trickier parts of the calendar UI was figuring out how to add people to an event. And did adding someone to an event mean they were notified about the event or were they responsible for the event? Here’s a discussion where we started to hash this out.
To sheet or not to sheet
Since the calendar is a “global” item (not part of any specific project), we discussed if it should live flat on the background or if it should live on a white sheet like a project. This discussion ended with punting the decision down the road – we wanted to see real content on the calendar before making the final call.
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.
All 208 images, files, and movies
Here are all 208 file attachments in the calendar project. You’ll find screenshots, prototypes, screencasts, and sketches.
One “feature”, 180 completed to-dos across 29 lists
And lastly, here’s the nitty gritty – 180 completed to-dos across 29 lists.
More soon!
We have dozens of additional projects we’ll be sharing with everyone over the next few months. Stay tuned for more inside looks at how we used the all new Basecamp to make the all new Basecamp.
Pierre Chapuis
on 05 Jul 12Are you ever going to explain on this blog why you have deprecated backpack and why you have done it so silently?
Is it because you consider that it has been made redundant by this new Basecamp (especially the calendar)? Should customers try to migrate to Basecamp?
Lukas Dryja
on 05 Jul 12Great article!
I was wondering:
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 12Pierre, 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 12I’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.
Thanks for sharing your process with us!
Lukas Dryja
on 05 Jul 12Thanks for the quick reply. I do agree that filling out time sheets is a terrible idea.
Jon Buda
on 05 Jul 12Guys, this is a fantastic post. Thanks for sharing a little window into your process. Fascinating to see how much thought is put into one feature and how quick the feedback loop is.
From what I’m seeing, your general process for this is:
1. Quick, low fidelity sketch 2. HTML mockups (with basic JS) 3. Development 4. Iterate
Pierre Chapuis
on 05 Jul 12@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.
We use Axosoft. :-/
Pierre Nouaille-Degorce
on 05 Jul 12@DHH “The new Basecamp has supplanted Backpack for us internally.”
We would love to move our Backpack projects to Basecamp! But we would need a function to duplicate a project on Basecamp.
With Backpack we repeat a full set of to-do items every week: we simply duplicate a template of our full to-do list. I can’t see an equivalent function on Basecamp.
It’s useful to see how you use Basecamp internally. Thank you for sharing this with all your users.
DHH
on 06 Jul 12Pierre, we are working on templates for the new Basecamp and hope to release the feature soon!
Pierre Nouaille-Degorce
on 06 Jul 12@DHH Great news!
Casimir Loeber
on 07 Jul 12Being 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 12Casimir, we use tilde to mean “nice to have but optional”.
Zach
on 09 Jul 12Thanks 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.
medical
on 10 Jul 12The post of this blog is highly informative.I like it.
This discussion is closed.