Recently my team has been working on core improvements for Basecamp. We planned to move quickly on a range of projects, and we wanted to make sure everyone at the company stayed in the loop. Plus, our company is full of smart folks who know the product inside and out, and we were hoping to use that hive mind to our advantage.

That’s easy when you have 5 or 10 people, but it’s challenging with 45. We had to share a lot of info and avoid pestering everyone in the process, so we began experimenting with a few new ways of working. Some of ‘em worked, others…kind of worked. Here are a handful of the strategies we tried the hard way.

Make screencasts for easier reviews.

No matter how many times you’ve done it, asking people for feedback is a harrowing ordeal. They’re busy working on something else, and you’re requesting their precious time and attention.

We wondered: what’s the most effortless way to communicate what we’re working on? Long written messages or storyboards take a lot of time to wade through. So instead of that, we started making 3-5 minute screencast demo videos for each project-in-progress. We share these videos with everyone at the company and ask them to comment. They’re friendly and easy to watch.

In each demo, we talk about the motivation behind the project and what we’re trying to accomplish. We explain how our solution addresses those things. We also mention weak spots or details we’re not sure about.

Here’s an example:

These videos helped quell broad questions like “why are we even doing this?” because they demonstrate that we’ve thought through the big picture stuff. As a result, the criticism we receive is more specific and actionable.

Sidenote: if you do this, you’ll have to get comfortable recording screencasts. After about 5 of them, you get the hang of it. The first step is accepting that yes, your voice is weird, and your face is kind of weird too, and wow, you’re not good at this at all, are you?

Work in the open.

A few years ago, Ryan wrote about designing in the open. We took that to its logical extreme and left our work wide open for anyone in the company to see at any time. That meant having our ongoing projects (in Basecamp) visible to everyone, and sending out weekly status updates about our work in progress. We call these heartbeats.

For feedback purposes, the heartbeats proved more successful than the open project. The open project is like a dirty workroom — people feel bad wandering in and criticizing what you’re doing while you’re doing it. (Plus we’re a remote company, so the workroom is full of people who aren’t wearing pants.)

That said, it’s still nice to let people peek if they’re curious about what’s going on. It also leaves a chance for the occasional helpful comment you might not have expected.

Seek out people who have different perspectives.

Getting the truth isn’t always as easy as mass-emailing people. You might actually have to talk to them. Sorry, fellow introverts!

We’ve made a concerted effort to chat with people outside our immediate development team, like our customer support people, data analyst, QA folks, and anyone else in the company who might look at the problem from a different angle. Sometimes they don’t speak up on their own, but if you reach out personally, they’ll almost certainly mention things you never considered.

Decode vague comments.

How many times have you heard (or said) stuff like this?

"This one looks more readable." 
"I like how this one is clean and simple." 
"This version makes your eyes jump to the important part of the page." 
"This seems like it’s the most usable." 
"This solution might be too noisy." 

This feedback isn’t necessarily bad, it’s just incomplete. Words like clean, usable, and noisy don’t have much meaning. They roughly suggest something about hierarchy, contrast, and spacing.

When we get feedback like that, we dig deeper and ask for clarification. If something looks more readable, why? What about the design is better? More whitespace? Typeface pairings?

Once you unravel the real issues, you’ll know which direction to go. You’ll also get better at offering suggestions to others. Instead of saying, “hey this design looks bad and weird,” you’ll say, “this doesn’t fit in well with our usual styling.” Details like that give your colleague a hint about what they need to improve.

Emotionally separate yourself from your work during critiques.

If you’re working on a project you care about, you’re invested. Sharing your work puts your ass on the line, and hearing a negative reaction will sting. (Admittedly, it’s even harder in front of the whole company. Your ass is on all the lines.)

But the only way to make something great is to recognize that it might not be great yet. Your goal is to find the best solution, not to measure your personal self-worth by it.

Furthermore, most people are reluctant to tell you what they really think. Got negative feedback? Cool! You just succeeded at finding the truth. That’s a win in itself.

When it’s time to share and evaluate what you’ve done, try to put your emotions and sweat equity aside. If you can manage this, you’ll be able to debate the ideas logically instead of emotionally.

When nobody responds, you probably haven’t nailed it.

We noticed that people rally around an obviously good or bad solution. If a solution is strong, you’ll hear about a few minor nitpicks, usually interspersed with an excessive quantity of happy emojis. If it’s clearly bad, a few honest folks will call it out (with not so many emojis.)

When the team is indecisive, or worse—silent—there might be bigger underlying issues at stake. The best way to move forward is to get the whole team together and air it out. Get on the phone, or Skype, or have a meeting and chat in person.

We did this with a project that wasn’t going so well. We were creatively stuck, but we’d been trying to work through it individually. When we reconvened as a group, everyone had a chance to voice their concerns and agree on what to do next.

Make the call.

What happens when everyone disagrees? You might have multiple viable ways to proceed and no definitive answer on any of them.

Now it’s up to you to weigh everything you heard. How much time do you have left to make changes? Which solution do you feel strongly about? Does someone else feel strongly when you don’t? Is there a compromise version, or another option you haven’t considered yet?

The answers here are always different, but one thing remains the same: it’s up to you. It’s tempting to pawn off these decisions to other people, or wait for a consensus to appear, but it’s better to choose a direction than to keep spinning your wheels trying to please the group. Making the call has the side effect of drawing out people who were on the fence — if it’s the wrong call for some reason, they’ll speak up before it’s too late!

Don’t be embarrassed when things don’t work out.

Not every project is an immediate success…or even an eventual success. Out of our last 10 projects, 2 didn’t go smoothly. The first one shipped after we took a break and regrouped. We shelved the second one entirely, because we tried numerous approaches and there was no clear path forward.

Admitting defeat doesn’t feel great, but it’s far better than trudging ahead with a design that simply isn’t working. Who wants to ship and support something like that?

Return the favor.

Try offering thoughtful critiques of others’ work. Be kind, honest, and specific. It’s surprisingly difficult to do!

If you’ve been in the game for a while, mentor the younguns. Help them improve and share the feedback love. Teach them to screencast so they’ll get used to their weird voices and faces too (eventually.)