Basecamp 3: New feature round-up

Summer is winding down, kids are back in school and the Basecamp team has a fresh batch of updates to share. Here’s a quick look at some recent improvements that are available right now in all of your projects.

Getting over the hill

Hill Charts are a completely new way to track progress and a Basecamp 3 exclusive. People everywhere are loving this unique way to see where their projects really stand and answer the hard questions that get them un-stuck. Now it’s much faster to choose which lists to track on the Hill Chart. Take a look…

Set up Hill Charts.

Profile cards

Clicking someone’s avatar in Basecamp is often the best way to get a little more information about people you’re collaborating with—especially when you work with clients, people you’ve never met, or on a team spread across time zones. Now profiles show you which company someone is a part of, their role in Basecamp (Administrator, Owner, or Client), and what time it is where they live. These details can help you track down an admin, figure out who the new person on the project is, or avoid bugging someone in the middle of the night.

Profile now cards display additional details.

Coloring folders

Now you can color folders just like you could other items in Docs & Files. Add a little personality, make something important stand out, or come up with your own color-coding system.

Coloring and organizing folders.

Project tools

Basecamp features seven distinct tools to handle every situtation in your projects from communicating to organizing to tracking work. With the latest update it’s easier than ever to choose which combination of tools to use on each project.

Managing project tools.

Improved invites

One of the best things about Basecamp is it keeps everyone on the same page so that nothing falls through the cracks. That only works, however, if the right people are involved in the project. So we’ve removed some steps, cut some complexity and streamlined the process so that getting people into your projects is easier than ever.

Inviting people is clearer and more direct.

Managing My Drafts

You write a lot in Basecamp, we get it. Drafts let you work on that post, announcement, article, or note in private until you’re ready to share it. But not everything gets published and before this update it could be a lot of work to figure out what was what or simply get rid of the ones you no longer needed. With this update, you can see all of your draft Messages and Documents, when they were last edited, and in which project they live. Not only that, but you can trash them right from the list without having to click into each one first. More info, faster edits, less pain = win!

Managing My Drafts

Jump to projects

For Basecamp pros, the Jump Menu is a speedy way to get around in Basecamp. Just hit ⌘+ J to return to something you saw recently or type a few characters to quickly filter Projects, Teams, and People. With our latest update we made it easier to jump to another project by making them pop up to the top of the list. This makes the Jump Menu hands-down the fastest way to get to a project in Basecamp.

Filtering in the Jump menu now makes jumping to another project even faster.

Thank you ❤️

We’re so grateful for all our customers and we hope these improvements make your time working more calm, effective, and enjoyable. If you’re not yet a Basecamp customer and feeling overwhelmed because your business is growing, you’re buried in email, stuff is slipping through the cracks, and communication is a struggle maybe it’s time to give us a try. You can try Basecamp completely free and unlimited for 30 days. No credit card needed to sign-up!

Real Work vs. Imaginary Work

Since we launched Hill Charts in Basecamp we’ve been fielding many interesting questions. One common question is: how do we catch more problems in the uphill phase so they don’t surprise us later?


What happens is, people think a piece of work is downhill, and then all of a sudden a problem comes out of nowhere. Especially when it comes to programming issues. “Why didn’t we catch this earlier?”

The reason often traces back to the uphill phase. An engineer looked at some work and imagined the solution in their head. “Yeah I don’t think that’ll be too hard.” They saw in their head how to do it, so they positioned the work at the top of the hill.


What happened next? After they got their hands dirty and started building, the reality turned out to be more complicated.


The problem is the uphill work was imaginary. Thinking about how you’re going to do something is not the same as rolling up your sleeves and trying.

The solution is to start at the bottom. If all of you’ve done is thought about the solution, then mark your status at the bottom left of the hill to show you haven’t built anything yet.

Start at the bottom when the solution is still imaginary

Now to move uphill, write some code to prove out the idea. Pick out the most essential steps or moving parts and write enough to validate the approach. Some teams call this “spiking” or “stubbing out” the work.

Doing real work to move uphill

You’ll still run into the unknown. But the difference is now you and the rest of the team expect that to happen because you’re still in the uphill phase. In fact all of your development work on this side of the hill is about spiking the unknowns and finding these trouble spots.

Catching the problem on the uphill side

You can’t bet on work that isn’t over the hill. So nobody will be surprised if a problem comes up on the left side. This is a healthy time to get stuck.

There could be a variety of solutions. Maybe you need to put heads together with your peers. Or get advice from someone senior. Or consider a different package or library to do what you want. Whatever the solution, everyone can see the problem as a step toward figuring out what’s going to work — what’s going to make it over the hill.

Doing work to get over the hill gives you more certainty

Having spiked out the most important parts of the problem, you can be confident that what’s left really is just a matter of execution. Sure there will be little surprises, but you’re less likely to run into something that blows the budget or breaks important assumptions.

The key point here is: imaginary work doesn’t count. Get to running code early. Or a rough interface. Or an outline of the copy. Whatever it is, the way to get uphill is to roll up your sleeves. Seek out the things that might go wrong and show evidence that the approach will cover them all. Then when you get to the top of the hill, your team can trust that the work is really going to ship as planned.

Short time horizons keep it fresh

When do we do our best work? When we’re excited about something. Excitement morphs into motivation. We do our best work when we’re motivated. A great way to stay motivated is to work on something new. No one likes being stuck on a project that never seems to end.

The typical project

Long project waveform

The typical project starts out great but then our motivation and interest wanes as time goes on. It’s natural. Staying interested in a project over a long period of time is a challenge for anyone. The longer the project the thinner the tail. You’re not going to do your best work in the tail.

The ideal series of projects

Project series waveform

When you do a series of small projects, or break a single big project into smaller individual projects, you stand a better chance at maintaining motivation and rekindling interest. When you have a pile of tiny projects you get the chance to work on something new more often. We do our best work when we’re excited about starting something new. That’s why the bulk of our projects fit into cycles that last 6-weeks or less.


Credit for the waveform concept goes to Jim Coudal.

Launch: A brand new way to work with clients in Basecamp 3

When we launched Basecamp 3, we introduced a new way for client services firms to work with their clients. We called it the Clientside. It was an entirely separate part of a Basecamp project where all client-facing communications lived. Essentially, it was a mini project within a project — a distinct space with separate tools and a different interface.

Conceptually it made sense, but practically it was inflexible and not collaborative enough. It worked well for some people, but it missed the mark for far more. We fell short of what we hoped we’d be able to create.

So we put our heads together and spent a couple months working on a complete revamp. Today we’re introducing something better.

Introducing Clients in Basecamp!

Starting today, not only can you send messages to clients, but now you can work with clients using all the same tools you already use with your team. That means you can assign clients to-dos, share files and folders, schedule events and meetings, chat around the Campfire, and even ask clients automatic check-in questions! If you can do it with your team, you can do it with your clients. And now it all happens in the same place as the rest of the project — no more separate Clientside. It’s everything you’ve been asking for.

You’re in 100% control of what clients see. Clarity and privacy is at the core of this new feature. That’s why everything in a project is now labeled as “private to our team” or “the client can see this”. Plus, to reduce anxiety and prevent “oh shit, they weren’t supposed to see that” moments, everything in a project starts off as private just to your team. When you’re ready to share something — a message, a to-do, a file — just flip the switch:



Whenever you post something new, you’ll have the option to specify if the client should be able to see it or if it’s private just to your team:

Blue+lock means private to your team, yellow+eye means visible to the client.

For example, here’s a to-do on a to-do list the client can see. It’s also assigned to Victor, your client:


And here’s a message thread about a revised headshot. The client can see it, and they’ve responded below:


And here’s an email you’ve forwarded in that you don’t want the client to see. It’s been marked private for your team only:


And finally, here’s a combination of files and folders. The client can see some folders, but not others. For clarity, only the ones they can see are labeled with the “The client sees this” tag:

They can’t see the “logo redesign folder” in top left, but they can see everything else.

Log-in or email-only — It Just Works!

We all know how hard it can be to ask a client to get used to using a new system. Even an easy system like Basecamp 3. So, Basecamp works even if your clients don’t want to learn anything new. Clients can respond to Basecamp messages right from their inbox, and new email they send you can be forwarded to Basecamp where your whole team can see them. Regardless if whether a client logs in and posts something directly to Basecamp, or they respond to a message via email, you’ll always have everything in one organized place inside the Basecamp project.

Fantastic! How do we turn it on?

  1. Go into a project, click the “Add/remove people” button. This is the same way you’d invite anyone to a project:


2. Then click the green “Add people” button and select “Invite a client to the project” from the bottom of the menu.


Now you’re off and running. Any existing content will be private, and anything new you add to the project will give you the option to mark something as private or visible to the client.

Back to the future?

If you’ve used Basecamp Classic or Basecamp 2, this new setup may ring a bell. You’d be right — it’s based on a similar approach. What’s changed is both the interface and the default privacy setting. In Classic and 2, everything in a project was visible to a client until you marked it private. Problem with that was that you could easily make a mistake and reveal something you didn’t intend to. But then it was too late. That’s why in Basecamp 3 we’ve flipped it. Everything is private by default. You have to expressly give a client permission to see something. It’s much safer this way. Less anxiety ahead.

What if we liked the Clientside?

If you’re an existing customer that used the Clientside in the past, you can continue to use it on any project in your account. It’s no longer an option for new customers, or for existing customers who’ve never used the Clientside before, but if you have, and you still prefer it, it’s all yours. You can even use the Clientside on existing projects and the new way on new projects. Further, if you relied heavily on the Approvals feature, you’ll want to continue to use the Clientside as there’s currently no equivalent feature outside the Clientside.


This is a big change, a big deal. We think you’re really going to like it. You’ll have the power and flexibility to collaborate with clients in true Basecamp style without any of the limitations imposed by the previous Clientside approach. And most importantly, you’ll always have 100% control over what messages, to-do lists, folders, files, Campfire chat, and automatic check-ins your clients can see and participate in. This way you can keep the private work private, and the shared work visible — all in the same project so everything is organized together.

Questions? Comments? Post ’em below. Thanks again for using Basecamp 3!

Getting Real: A new YouTube channel from Basecamp

Click the image above to jump to our new YouTube Channel!

For years people have been asking us how. How do you design things? How do you code things? Why do you do it this way vs. that way? How do you think about writing? How do you think about what makes it into a product and what does? How do you decide which features to build and which ones not to? How do you stay up on everything that’s going on in your business?

We’ve written about these topics for years — and we’ll keep writing about them — but we want to bring some show to the tell. So we started a new YouTube Channel called Getting Real. To start, DHH and I will be posting occasional videos of actual day-to-day work. Down the road other people at Basecamp may join in.

So far we have a dozen videos up. More are coming. Check out what we have so far and subscribe to be notified when new ones are ready to watch.

We hope you dig it! And if you have any ideas for future episodes, please post a comment below.

An Ode to Experimental Design

If you search the Internet to learn about A/B testing, you’ll find scads of articles bursting with tips for cranking your business performance into the stratosphere.

You’ll get blazing hot secrets like…

BOOST YOUR CONVERSION RATE BY 300% WITH THIS TINY TWEAK

and…

DESTROY YOUR COMPETITION USING A STATISTICALLY SIGNIFICANT SHADE OF BLUE

…and it just keeps going like that, into an overenthusiastic pit of armchair psychology and semi-authoritative pseudoscience.


As the gurus tell it, A/B testing is like Vegas slots: plunk some crap into a machine, score a handful of 🍒🍒🍒s, and voilà, Easy Bake Revenue!

With a pitch like that, who could resist? It sounds so simple. If you don’t do it, you’re obviously a fool who’s leaving money on the table.

Welp, I have a couple of hard truths for ya:

  1. It’s not as easy as it sounds, and those big gains aren’t such a sure thing.
  2. Setting out to dramatically boost some arbitrary metric (signups, conversions, revenue, whatever) is exactly the wrong way to approach a design problem.

How do I know this?

I spent most of last year testing dozens of conversion-related design ideas in Basecamp, and I found that the JACKED UP PERFORMANCE aspect is the least interesting part of the process, by far.

The most interesting part is how it can change your thinking. Testing is a ticket to ride. It energizes your adventurous spirit, introduces you to uncharted territory, and lands you in cool places you never expected to go.

Here’s what I learned, and why I’ve come to love doing experimental design.


Testing turns your designs into trash.

After running tests for a while, you’ll find yourself throwing away mountains of design work for just a handful of meaningful improvements.

Do that enough, and you’ll notice something: Maybe design isn’t such a special endeavor after all!

The truth is…a lot of design is ephemeral, malleable, disposable…garbage.

Anything you make today merely represents one moment in time. Maybe it’s your best idea now, but it’s not necessarily the best idea you’ll have in another two days or two months.

Testing makes this painfully obvious on a shorter time scale. You’ll soon become less emotionally invested in your precious creations, and more focused on the problems you care about.

Testing strengthens your gusto.

I don’t know about you, but it took me years to build up the confidence to make hard design decisions. I still struggle with it sometimes.

You have to succeed and fail a lot. You have to take criticism a lot. And you have to trust your gut and keep at it, day after day.

Experimentation is a great way to build that muscle. It’s an opportunity to try things you aren’t completely sure about, and gives you a sweet little safety net for failures.

Testing makes you thoughtful.

It can be tempting to do experiments like the lottery: throw a bunch of random shit at the wall and then declare victory when one thing performed best by random chance.

You might get lucky a few times that way, but it’s a terrible long-term approach. Without some overarching vision, you’ll be left with a gnarly mess of test results born from guesses, and no clear plan for what to do next.

The better way, of course, is to start with good ideas! Do some research, come up with educated hypotheses and concepts you believe in, then build and test them to verify your thinking instead of defining it.

Testing destroys perfectionism.

It’s so freeing to ship a bare-bones version of an idea because it’s “just a test” that you’ll either improve or throw away when it’s done.

If you thought that same design had to stick around permanently, you’d probably never launch it with a lot of known flaws or incomplete parts. You’d want to fix up every last detail and make everything perfect first.

Amazingly, those rough, imperfect tests often outperform the supposedly perfected version you already had in place. When you see that, you’ll realize your outsized attention to detail might not matter as much as you thought.

A license for imperfection is an extremely useful defense against Fussy Designer disease. We should all be vaccinated early and often.

Testing builds empathy.

This sounds counterintuitive: running an experiment is mostly a pragmatic and statistical kind of thing. How is that related to empathy?

It’s related because you’re forced to learn what happens when real human people interact with your work. Your choices all have directly measurable effects, so you can’t hide behind bullshitty designerspeak or vague justifications when the data shows you’re just flat wrong.

That means you have to get outside your insular designer bubble, stop thinking of people as numbers, and get in their shoes a bit.

When you do that, the business boosts you want will happen as a natural side effect of continually tuning your product to serve your customers’ real-life situations. Making things clearer or more efficient for your customers always pays off.

Testing helps you make space.

One tough challenge in UI design is making physical space for new things you want to do. There’s only so much room on a screen!

You might have ideas that require injecting steps into an existing UI flow, adding more screens, revising a visual hierarchy, or rearranging certain navigational elements.

Doing stuff like that is a gamble. You might be confident that your new version is better in some way, but are you sure your improvements are worth the extra steps or added complexity?

Testing lets you dip your toes in the water. You can run a short experiment and see if you’re busting your business before committing to a direction.

Testing tells the truth.

The truth is weird. Sometimes common sense wins out. Sometimes a wild idea succeeds. Sometimes a version you hated performs the best. Sometimes your favorite design turns out to be a total stinker.

Where else in the design world can you get opinion-free feedback like this? There are no Art Directors or Product Managers or App Store reviewers telling you what they think is right. It’s real human nature telling you what’s right!

It’s a fascinating, powerful, bizarre reality.


Do you use testing as part of your design process, and NOT just for improving some Haha Business metrics? I’d love to hear about that. Drop me a comment below or holler on Twitter.

New in Basecamp: Improved Schedule Cards

A more complete picture of what’s coming up

This was a classic case of “How hard could it be?” that started as a series of customer requests and bug reports. People wanted to see their events AND their dated to-dos on their Basecamp 3 Schedule cards. Totally reasonable, right? Like anything involving dates, timezones, and computers, it took more than a little wrangling… But now you can!

Let There Be To-dos
Here’s a great example from our Ops Team. Before, we only showed upcoming schedule events. That triggered a misleading message that said “Nothing’s coming up!”

Nothing’s coming up! Maybe?

Why is this misleading? If you click through to the Schedule itself, you’ll see there’s actually a to-do due tomorrow:

Surpise!

You wouldn’t have known that glancing at the Schedule card. With the changes we just added, you’ll now see something like this when you’ve got upcoming to-dos:

Voila! Just like the full Schedule

Who and When?
Another thing was missing from the previous design: It wasn’t clear exactly who was involved in an event and precisely when it was happening. That’s because we just showed the name of the event and the date on which it occurred:

What time is dinner, anyway?

Now, we show avatars for each participant and to-do assignee as well as times for events that happen at a specific time:

A lovely group and an early start.

Templates
Project Templates were also missing to-dos. That led to situations like this where the Schedule looked blank:

Nohting to see here… Or is there?

In fact, there may have been several to-dos:

The full picture

We hope this makes Schedule cards more useful for you. Stay tuned for more updates to Basecamp 3!


Got feedback or ideas to share? We’d love to hear what you think about the new features. You can contact us on Twitter or share your thoughts via our Support form.

Hard first or easy first?

Accountants have FIFO (first in first out) and LIFO (last in first out). Product designers have HFEL (hard first easy later) or EFHL (easy first hard later).

No matter the project, there are things you’re more confident about and things you’re less confident about. No brainers, maybe brainers, yes brainers. Assuming you have limited time to complete a project (we spend a maximum of 6 weeks on most projects), you have to decide how to sequence the work. Do you pick off the hard stuff first? Easy stuff first? What to do?

It depends, of course. I don’t have any answers for you, but I can share some of the things we think about when deciding what to do when.

First we get our bearings.

Does this feel like a full project? Is it probably going to take all the time we have? Lots of moving parts? Does this work touch a lot of other things, or is it mostly self-contained? Do we feel like we’ve mostly got it down, or are there some material unknowns we haven’t quite nailed down yet?

If it feels big, and full, and challenging with some significant unknowns, we almost always start with the hard stuff first. The worst thing you can do in that situation is kick big challenges down the road because you’ll inevitably run out of time. You’ll either make bad big decisions that way, or you’ll push the schedule out, or you’ll work late or work weekends. All those are big no-no’s for us, so we tackle the hard stuff first.

Sometimes we start with a quick spike. We put a few days into it and see if we’re able to make any meaningful forward process. That’ll reveal if the problem is really as big as we think it is, or we’ve been overestimating the shadow of worry its been casting. But waiting until later isn’t an option. We chip away at the big rock to see if it’s sandstone that’ll break down easy, or granite that’ll require heavy machinery.

Once we have a sense of where we’re at, we think about what we need, as a team. I don’t mean what does the team need as far as tooling or technology goes, but what do we need emotionally? Do we want to slog along without any short-term visible progress, or can we grab a quick win and start to pick up some momentum? It depends — how did the last project go? Are we coming off a high or a low? If a low, maybe we should find some quicker wins to fuel the spirit. If a win, maybe we’re already feeling good enough about ourselves to go heads down without anything material to show for a few more days. The past plays a surprisingly important role in the present.

We’re currently working on some significant improvements to the way our customers work with their clients in Basecamp 3. It’s a big project, and we’ll likely be working on it over two 6-week cycles. There are unknowns — both technical and visual — but the last time we tried to tackle this problem we ended up putting a lot of work in with nothing to show in the end. We didn’t ship what we built because we 1. didn’t finish on time, and 2. didn’t feel great about what we built, and 3. didn’t want to put more time into a bad time. Therefore, this time, we ran easy and hard in parallel. The programmers worked on a hard problem first, and the designers worked on an easy one. It was a nice way pour the concrete foundation and choose the paint colors at the same time.

On the design side of things, we often try to stay away from the details early. Details can turn into quicksand. We never want to get stuck on something early on — that’s a surefire way to burn too much time on something that’s going to change later anyway. Never ever get stuck on something you just know you’re going to change later. So when we start a design project, we typically go from very big to very small. It’s a bit different from choosing hard first or easy first, but it’s still a choice. We still have to decide where to begin.

One other thing I wanted to add, but don’t know where to put: We aim to avoid feeling like we have something to prove. That’s hero language, and we don’t do hero. We do work. We have work to do. Big and small — we’re satisfied by doing good work and getting it done in the time we give ourselves up front. Heros are only satisfied by rescuing things, doing the impossible, or saving the world. We’ll leave those antics to teams that run on fumes. We’ll run on a good night’s sleep.


I wrote this essay without reading it back — a stream of consciousness burst. I’ve had a bit of writer’s block this week, so I’m trying to bust through by just writing raw thoughts and getting my fingers moving again. I hope it was helpful. Any questions?

The presence prison

Are you chained to the green dot? Turn it off and break free.

As a general rule, nobody at Basecamp really knows where anyone else is at any given moment. Are they working? Dunno. Are they taking a break? Dunno. Are they at lunch? Dunno. Are they picking up their kid from school? Dunno. Don’t care.

The vast majority of the time, it just doesn’t matter. What matters is letting people design their own schedule around when they can do their best work.

Keep reading “The presence prison”

Which version of later do you run?

One of the reasons we work in six week cycles, is that it gives us a different definition of later.

When you work on really long projects — say 3, 6, 9 month projects — or projects that don’t have any end in sight, “we can do that later” typically means you’ll get to it eventually, as part of the current project. Long time frames give you invisible space to pack away unrealistic amounts of work. Since later is so far away, there’s no harm in kicking the can down the line. In other words, later makes a pile at the end.

Gnarly problem you can’t figure out how to solve yet? Punt it into the later pile. Design not coming together quite right? Toss it in the later pile. Taking on lots of technical debt as you go? Push it into the later pile.

But then as you near the end, you run into this big pile of stuff you said you’d eventually deal with, fix, redesign, tighten up, etc. But there rarely seems to be enough time at the end, so you either end up guiltily ignoring it entirely, or hastily patching it together with duct tape. And when you hastily patch, you often end up creating another fix-it-up project later.

But, when you work in six week cycles, or relatively short time frames, later means something else entirely. There’s no time for later. It’s now or not. Later doesn’t mean we’ll get to it at the end of this cycle. It means we’ll drop it. Later means another time, not this time. Later isn’t a obligation, it’s a maybe. Later isn’t a cage, it’s freedom. It’s not a debt to pay off, it’s an asset. There’s no pile, there’s no guilt, there’s no feeling of late nights and crunch time ahead. Later simply means not now, not soon, and not for sure.

That’s the kind of later we like.