One of the joys of building the new Basecamp was using the new Basecamp to quickly iterate on a design problem. Because I’m in Colorado and the rest of the team lives elsewhere, we rely on a combination of tools to share files and work through ideas. And while we might have used Campfire in the past, we now use Basecamp messages to quickly work through ideas and keep the conversation focused.
During one design session, I worked with Jason and Ryan on a particularly thorny problem on the calendar: notifying people about a new event.
When we build large features like the Basecamp calendar, we like to get a prototype up and running as soon as possible. This allows us to use the feature early and often, helping us identify problems and fix them. Sometimes, building a working prototype means standing up pieces that are “good enough” and moving on.
For event notifications, we grabbed an existing design pattern (for calendar permissions) and roughed it in. With other parts of the calendar still up in the air, we added a “good enough” stamp of approval and focused our attention elsewhere. As time went on, though, we started to feel the pain. This solution wasn’t going to cut it.
The Wrong Metaphor
There were two main problems with this design: 1) The text fields made it seem like you could tell anyone about an event, even if they couldn’t see the particular calendar and 2) We were forcing people to type names for every event, which felt like work.
Sure, by using an existing design pattern, we were able to build something quickly. But the cost was that we weren’t really thinking through the problem. As it turns out, it was the wrong metaphor altogether. We weren’t granting permission here, we were notifying people about an event and setting a follow-up reminder. Time to sleep on it.
The next morning, a solution became more clear. We needed to offer a few quick notification options (me, everyone) and a way to choose specific people:
Those shortcuts made it easier to notify yourself or everyone on the calendar about an event, but what if you wanted to tell just a few people? It felt like a lot of interface to include more text fields on a dialog with loads of radio buttons, date fields, and buttons. Maybe we could tab the dialog? Could we toggle it in some way? What if we slid the contents sideways? I quickly mocked up an idea and dropped it into our Basecamp thread:
We were onto something, but it didn’t feel quite right. The freeform text fields still required that you remember who can see the calendar in the first place. We soon realized we were avoiding a better solution because the dialog was so small. By sliding the UI over, though, we’d freed up space to use checkboxes for everyone on the calendar:
That felt better. You could quickly send notifications to people with minimal effort. Plus, if you didn’t need that functionality, the complexity was tucked out of the way until you do.
We continued to iterate from there, but we hashed through the core thinking in about 24 hours of back and forth in a single Basecamp thread. These sessions are fast, interactive, and fun. Everyone can see the designs as they are dropped into the conversation, leave a comment, and offer suggestions. When the idea feels like it has legs, we build it and start the feedback cycle all over again.