This is Signal vs. Noise, a weblog by 37signals about design, business, experience, simplicity, the web, culture, and more. Established 1999 in Chicago. Visit the Product Blog for more information on our products.
‘Rock Star’ is perhaps the most abused phrase in the history of job listings. Nobody should be looking for a “rock star” accountant, HR recruiter or janitor. Whomever is posting these jobs is grossly misinformed as to the nature of rock stardom. Or accounting. Or both.
Basecamp New File Uploading features in Basecamp
We’re excited to announce a batch of improvements to File Uploads in Basecamp. Now it’s easier to attach multiple files at once, we’ve improved our progress bar to show you as each file is uploaded, and you can click thumbnails to zoom image attachments without leaving the current page. These new features make it faster and easier to attach, review and discuss files in Basecamp. Here’s a demo video to show you all the improvements.
New Basecamp feature: The Daily Digest
We’re excited to announce a great improvement to Basecamp. The new Daily Digest feature makes it easier than ever to track the progress of your projects. The Daily Digest is an email that Basecamp sends you once a day. The email tells you about any to-do items or milestones that were checked off or added in the last day. Daily Digests are per-project, so you can subscribe to the projects you really care about without being distracted by any unnecessary information. Now you’ll always know day-by-day as work is completed or new work is assigned. It’s a really powerful feature.
I’ve always preferred sketching UIs with an as-thick-as-I-can-find Sharpie over a thin ballpoint pen or finely sharpened pencil.
Ballpoints and fine tips just don’t fill the page like a Sharpie does. Fine tips invite you to draw while Sharpies invite you to just to get your concepts out into big bold shapes and lines. When you sketch with a thin tip you tend to draw at a higher resolution and worry a bit too much about making things look good. Sharpies encourage you to ignore details early on.
If you sketch, try a thick Sharpie next time. You may find you’re better able to focus on the concept and less on the drawing. That’s a good thing.
Just about two weeks ago we launched the a redesign of the account chart in Basecamp. This is where people can upgrade or downgrade their accounts.
The goal was to increase overall upgrade conversions and encourage people who are on Basic plans or lower to upgrade to the Plus plan (our lowest priced full-feature plan).
Results
I’m glad to report our design hunches appear to have paid off. We’re only about two weeks in, so we don’t have a ton of data yet, but we can compare the 14 days since the upgrade with the 90 days prior to the upgrade.
Average upgrades/day: up 13%
Average Plus upgrades/day: up 33%
Average $ value increase per upgrade: up 8%
We’re thrilled with these numbers. We’ve moved the new design to the Highrise account chart as well. We’ll watch and see if we see the same improvements with Highrise as we have with Basecamp.
It’s been several weeks since I was hired here at 37signals so I thought it might be interesting to share some of my experiences so far.
Ready, set, go!
One of the best things has been how quickly I’ve been able to jump in and start contributing. The very first project I worked on was a refresh of the Account screen in Basecamp. What started as an exercise quickly escalated to a new design that we wanted to actually put into the app. So it wasn’t long before I moved from Photoshop right into the app code to integrate the new design. This required me to build on my limited experience with Ruby on Rails, setup my computer for development, learn enough Git to be dangerous, and get a feel for application structure and conventions. None of this could have happened without the patience of my co-workers and the solid development structure/process that is in place here. Here are a few general observations:
The 37signals community is huge! Every change is noticed — sometimes within minutes of being launched. Receiving instant feedback to your work is great (at least so far :)
Git has been a surprisingly nice addition to my workflow. The ability to quickly switch branches and compare my version to the original has saved me countless hours
There are new things being added to the apps constantly. It’s exciting to see all of the new features and improvements every day. It can be hard to appreciate all of this activity from outside the company, but we’re working on that
In the first ten days or so I was able to design and implement a single screen redesign, get it deployed and write it all up at Signal vs. Noise. It’s pretty great to feel like you’re contributing and making a meaningful impact so quickly.
Working remotely
One of the biggest changes for me when joining the company was working 100% remotely. 37signals is based in Chicago, but half the team works outside the office — even the Chicago crew isn’t in the office every day. So it has been great to join a company that knows how to work with a widely distributed team. As you might assume, communication is the key to making the team effective and productive. Here are a few ways we stay connected:
Campfire
I have to admit that I didn’t getCampfire before I started working here. I’d been a long time user of Basecamp and Backpack, but Campfire never clicked for me despite a couple of attempts to bring it into a team workflow. What I was surprised to see is that Campfire might be the most important app that we use.
Our “All Talk” Campfire room is where the entire team gathers each day — we all stay logged-in anytime we are “at work”. Throughout the day we post questions, share screenshots, get feedback, collaborate on copy, and troubleshoot code. Campfire also talks to our apps so we get notifications when they are updated as we develop. It also serves as a way to quickly note to the team that you’re heading to lunch or will be away from the computer for a short time. But it’s not all business. We also find time to talk about the latest gadget/news/link/app/controversy and generally have a good time. Campfire is where all the typical conversations that happen in a physical office occur, but the difference here is that everyone can hear them, anyone can pay attention to what they want to, and it’s all archived so we can search through it later.
Campfire is also used along with instant messaging for the one-on-one and sidebar conversations when we want to chat, but stay out of the noise of the All Talk room. Jumping into our Small Talk room to work through a bit of code lets me work directly with a co-worker AND allows me to save a link to that conversation for future reference. This has been immeasurably helpful for me as I dig more into the tech side of our apps. Screen sharing via iChat is another great way a couple of us can quickly work together on a tricky bit of code.
In/out
Another key part of knowing and sharing what is going on with the comapny is with Backpack’s Journal screen. The journal lets everyone on the team set their current status (e.g., “Reviewing design comps”, or “Out to lunch”) and log the last few things that they have recently completed. There is no forced structure to it, we typically just update it a couple times a day as necessary. It’s a great way to get a quick snapshot of what is going on, who is working right now, and what they’re working on.
Of course we also follow project updates in Basecamp and keep an eye on external communications by checking into our Highrise account. Everything is out there for us to keep up with as we need to or want to.
Perfect balance
At 37signals I really feel more connected and current with what is going on than in any physical workplace I’ve been a part of. It is effortless to keep up with what my co-workers are doing and how what I’m doing contributes to the whole. I’m free to keep up with projects and learn new skills as they fit my interests. We collaborate how and when it makes sense, and stay away from each other when that’s the best way to work. That makes for a really effective working environment.
In Artistic Value of Thriller [via JS], “Scorpeze” writes that many overlook Michael Jackson’s role as a songwriter and producer on his landmark albums and tend to overestimate Quincy Jones’ role. The post includes links to demos (Billie Jean, The Girl Is Mine) that MJ created for those records. Assuming they’re legit, it’s pretty amazing how close they are to the final product.
From a biz/marketing perspective, it’s also interesting to note how many risks MJ took on Thriller. There were so many things on there that people said you couldn’t do on a R&B record. But he did ‘em anyway and created the biggest selling album of all time.
people glaze over it now…but what soul/R&B figure could create a hit rock record that was embraced across the board…AND considered authentic by the rock audience?(the snobs may have been pissed off, but they werent the ones buying the records)…what soul/R&B cat was collaborating with Van Halen….and have it WORK?
it wasnt Prince….w/out Beat It, could you have a Let’s Go Crazy?
what other soul/R&B cat could get one of the Beatles on Black radio in the 80’s?
what soul/R&B cat would get Vincent Price to drop spoken word in the middle a funk/R&B cut cum horror movie?
who was else at the time was incorporating African chants and percussion at a time when everyone was whitening it up sonically(including MJ)…and who would reference Soul Makossa in the 80’s?
listen to the fact that a Black artist who was considered strictly soul/R&B decided to do a stylistic tour de force in one album when it hadnt been done before…
Thriller had:
Funk
straight R&B
Quiet Storm
MOR Pop
Rock
…all in one album by a Black aritst when such a thing was not only unheard of but frowned upon…..
futhermore, on Thriller he spoke abt teen preganancy, gang violence, challenging the social constructs of manhood, the culture of gossip, emotional blackmail, obsession, false accusations of paternity, and belief in one’s self…
fluff?
these are ARTISTIC RISKS….they could have gone horribly awry, but they didnt….he did the record HIS way….and in a rare occurence that we will only see once in a lifetime, hit the bulls-eye and pleased EVERYBODY…the effects of that had both deep positive and negative effects on his work and the entire music industry after that….
Looking back, it all seems perfectly logical. It’s easy to forget how much of a singular vision it took to pull off that unique combo of ideas.
Yesterday we pushed an update to the Basecamp global milestone view. This is the calendar-style view of all milestones on all projects over the next 3 months. The goal was to make this screen cleaner and more useful.
The old milestone calendar looked like this:
It did a great job of effectively using the space with empty days that collapsed to a very small size. This made it easy to get a good quick view of the whole picture. But it was hard to dig-in further. You couldn’t tell which project each milestone belonged to or who was responsible for completing it. The pull-down at the top right did filter by person assigned, but even in that view it was hard to see which project the milestones applied to.
So, one of the first things we knew we wanted was to add the project name and person responsible for each milestone. Each milestone now shows both without adding a lot of visual clutter. We think this instantly makes this screen more useful, but wanted to explore more ways to make it better.
When we thought about how people use this screen it became clear that the empty days could be just as important as the days that have milestones. One reason to check this global view was to find the holes — the places where new milestones could fit.
So we explored sizing each calendar day to an equal width — much like a more traditional calendar. This had the added benefit of making the whole screen more understandable simply because it looks like a traditional calendar. It is more clear what you’re looking at and what you can do here. This is the revised look with equally-sized days and some small visual tweaks:
We added a subtle visual style for the days that fall on weekends to differentiate from weekdays. It then occurred to us that some businesses operate almost exclusively on a regular Monday–Friday schedule. For them it was a waste to have almost 30% of the available space each week used to show empty weekend days. So we brought back some of the table collapsing for weekends. If there are no milestones on any weekend day in the current view they simply shrink to a minimal width, allowing more space for the weekdays. However, if any weekend day has a milestone, then weekends become full-fledged citizens again. Here’s what it looks like when weekends aren’t being used:
One more thing…
While re-working the CSS for this particular screen, we noticed that we hadn’t defined any print styles. So we spent a little time adding some CSS to our print stylesheets for the global milestones calendar. Now when you print it will look something like this:
The 37signals Job Board attracts the cream of the crop because it’s featured prominently on five industry-leading sites: Signal vs. Noise, A List Apart, Kottke.org, Coudal.com, and the Ruby on Rails site. And not just anyone reads these sites. The people who build the best of the web read these sites. People who value beautiful design, beautiful code, high standards, and doing great work. The kind of people you want to hire. Post a job (or internship) and find the right person today.
Some have doubted our advice that you should hold on to your day job and start something on the side. They argue building a business requires such persistent effort that you need to devote all your time to it to do it right.
And it’s true that building a business requires plenty of time and effort. But the idea that you need to quit your job to do it right is misguided. If you quit your job, you shift everything. You don’t gain time, you lose it. You put a shot clock on your business. You box yourself into a position where you have to profit immediately or the whole thing goes under. You’ve got to make it work now or give up forever.
Hanging on to your day job gives you a longer period of time to build your idea. It lets you give a sustained effort over time. There’s no get rich quick option. You build it slowly, one day at a time.
Yes, you need to find time to do both your side business and your normal gig. But there’s always enough time if you spend it right. Instead of watching TV or playing Grand Theft Auto, work on your idea. Instead of going to bed at 10, go to bed at 11. We’re not talking about all-nighters or 16 hour days – we’re talking about squeezing out a few extra hours a week. That’s enough time to get something going and then keep giving it gas.
Let your side business evolve into a full-time business naturally. Go for organic growth. Start as a side project. Build it slowly. Keep putting time into it. As pickup of your project grows, then you can justify devoting more resources to it. Eventually, if everything goes according to plan, you’ll be able to quit your job and devote all your time to it (if that’s what you want). But doing so right out of the gate is putting the cart before the horse.
Think how evolution happens in nature. There aren’t huge leaps. Things incrementally change. That’s the model to shoot for.
Over the years I’ve seen a lot of proposals from professional services firms. Designers, architects, lawyers, consultants, and others.
Many of them included a small price list at the end. Here’s one from a recent proposal I received from a landscape architect I’m considering hiring:
These nickel and dime items have always rubbed me the wrong way. I’m about to pay someone many thousands and they’re about to bill me $0.15 for a copy.
Plenty of people bitch about ATM fees, but these copy and print fees feel even more obscene to me. I recognize paper costs money and toner costs money and machines cost money, but come on – isn’t this just part of the cost of doing business? It feels like they’d charge for bandwidth used to email you a file if they were sophisticated enough to track it.
Further, many of these professional services get annoyed when their clients cut back budgets or say they can’t afford this or that. But then the professional services themselves pinch pennies even tighter by trying to pass the cost of a piece of paper on to their client. The disconnect couldn’t be more obvious.
I can’t recall if I’ve ever actually been billed for any of these items, but it just seems unnecessary. Perhaps they are worried about clients that require thousands of pages or hundreds of plots. If that’s the case, ok – how about saying “After 100 copies, we will bill $0.15/copy” or something like that. Absorb the routine costs and bill the excessive costs. That feels reasonable and respectful on both sides.
At the end of the day another $15 here or $36 there isn’t going to break a client’s bank, and complaining about $0.15 feels petty – and in some ways it is – but these nickel and dime fees put up a sign that says “we’re passing every little cost on to you, no matter how insignificant.” That just doesn’t seem like the right way to start a business relationship.
This post kicks off a series of posts designed to share how we use our own products for our own business. It’s something we don’t talk that much about, but it’s something a lot of people have asked about. So here goes.
PROBLEM: We didn’t have a simple, accessible-company-wide list of email newsletters we’d sent out.
We use Campaign Monitor to send out our email newsletters. While Campaign Monitor does keep a list of previous newsletters, it’s not convenient for everyone else at 37signals to log in and go through the overhead of another app just to see a list of previous newsletters. So we made a Backpack page instead. We’ve made the page public so you can see it for yourself.
Dead simple, one page, quick summaries of every newsletter, grouped by product, direct links to the HTML versions of the newsletters. The page is shared with everyone at 37signals. It’s also tagged “37signals” “Newsletter” so anyone can find it quickly if they haven’t added it to their Backpack sidebar.
Whenever Jamie sends a newsletter he takes about 60 seconds to add the link and brief description to the Backpack page. We use Backpack page dividers to group the newsletters for different products and add each newsletter as a note. The note subject is the date and the note body is a link to the newsletter plus a summary of the main points.
And that’s it. Not rocket science, but who needs rocket science? Backpack is anti-rocket science.
It’s just a shared Backpack page with a list of stuff grouped up, linked up, and summarized up. In one place all the time so everyone knows where it is.
Christopher Alexander on the beauty and sense of wholeness that comes from the irregular construction of buildings such as La Casa de los Azulejos in Mexico City. From his 1991 essay “The Perfection of Imperfection,” as cited by Richard Gabriel in Patterns of Software (1.2 MB PDF).
You’re working on some new UI and there are multiple states that could be displayed based on some conditions. How do you communicate the possible states to a programmer? You could mock them all up separately as wireframes. Or you could comment them out in your HTML mockup and then walk through them face to face, explaining each one. Both of these methods work, but they leave a gap between your intentions as a designer and the programmer’s interpretation. The best way to ensure the conditions are understood and agreed upon between both of you is to actually write them into your template using stubbed Rails helpers.
Here’s an example from Basecamp. We want to improve performance on comment threads with a very high number of comments. The idea is to paginate comments. We’d display the most recent n comments, (let’s say 50) and earlier comments could be fetched dynamically with a “show more” link. Here’s a sketch:
The template for that sketch looks like this:
<h2 class="paginated_comments_header">
<strong>These are the last 50 comments</strong> out of 160 total — <%= link_to "Show 50 more" %>
</h2>
But that’s not the end of the story. What do we display if there are no more comments to show? What if we are showing fifty out of sixty comments, so “Show 50 more” wouldn’t apply? The best way to communicate and test these conditions is to stub out some helpers. First I’ll write what I want to happen even though the helpers don’t exist:
<h2 class="paginated_comments_header">
<% if showing_all_comments? %>
<strong>Showing all 60 comments</strong>
<% else %>
<strong>These are the last 50 comments</strong> out of 60 total —
<% if more_than_one_page_of_comments_left? %>
<%= link_to "Show 50 more" %>
<% else %>
<%= link_to "Show remaining 10 comments" %>
<% end %>
<% end %>
</h2>
Look carefully at the code to see how it reflects the different edge cases mentioned above.
Next I’ll write the helpers so that the template works. Since I’m only mocking the helpers, I can just make them return “true” or “false” depending on the condition I want to demonstrate.
module CommentsHelper
...
def showing_all_comments?
false
end
def more_than_one_page_of_comments_left?
true
end
end
All I have to do to test the different states is toggle those “true” and “false” values. The code communicates directly to the programmer when and why the different parts of the template should render. When it’s time for the programmer to implement, all he or she needs to do is replace the boolean with the actual conditions.
Even if the final template is going to be implemented differently, like in Javascript instead of ERB, it’s still helpful to deliver the template in ERB with the mocked helpers because the conditions are completely nailed down. I hope this technique helps you navigate that communication gap the next time you mock a template with more than one possible state.
As the new designer at 37signals, I am working on a series of short-term projects, much like the old 37express projects and my recent Highrise contact screen exploration. The idea is to work through some long-standing areas of the apps with a fresh eye and an outsider’s perspective. It also allows us to revisit some areas that we know can be better, but for various reasons haven’t had the time to rework.
So the goal is for me to tackle one of these design challenges a week for the next 8 weeks or so. We may get sidetracked like we did on this first one, but that’s the plan for now. I’ll be looking at solutions that we can implement immediately, but also digging in to see where else the process might take us. I’ll also be documenting these explorations for all to see.
Redesigning the Basecamp Account Chart
The first exploration was of the “Account (Upgrade/Billing)” tab in Basecamp and my write-up of the process is live. Not only that, but we went ahead and implemented the final design into Basecamp. It was pretty cool to get in here, get to work, and have my design live all in the first 10 days or so as a signal.
Yesterday David and I met with Sarah and Michael for a bit to get an update on how customer support/service is going. We recently switched from using Gmail to HelpSpot and we were curious how the transition felt. Basically, how was the workflow and were we learning anything?
Why the switch?
One of the reasons we switched to HelpSpot was so we could do a better job tracking which requests and issues were top requests. Sometimes support will say “People have been having a hard time uploading files this week” but it’s hard to know what “people” means. Is it two people? 10 people? Dozens? If we made changes to the app, would we reduce support demands and customer frustration? Gmail couldn’t really give us specifics, and HelpSpot could, so we switched to HelpSpot.
Knowing but not learning
In our review yesterday we discovered that were were tracking everything in detail, but not really learning anything. Why? We were tracking for the sake of tracking, not tracking for the sake of learning. We weren’t really sure why we were tracking what we were — but we kept on doing it because, well, momentum is a powerful force. It became an exercise in seeing how organized we could get in spite of what we actually needed.
Our extensive use of categories and tags and custom fields and pulldowns could give us a whole lot of report-friendly information, but it didn’t give us any useful information. Information without insight is junk. That’s what we had. Plenty of it.
Going back to simple
So yesterday we decided to change everything. Let’s point the ship towards simple. Every mistake we’ve made as a company has been because we tried to do too much, not because we didn’t do enough. So let’s apply that lesson to how we track support requests too.
What really mattered?
Instead of neatly categorizing every request, we’d just roughly categorize them. So instead of multi-level categorizing like “Milestones > Editing > How to move milestones between projects” we’d just track the “How do move milestones between projects” part. The “Milestones” and “Editing” categories didn’t matter. We didn’t need the hierarchy or extensive organization. All that mattered was the bottom line: The question/issue.
Basically as questions/issues came in, we’d create new long tags that paraphrased the question/issue. And whenever another question/issue came in that was roughly the same as the paraphrased question, we’d tag the actual question with the paraphrased question. This way we could get a count on these paraphrased questions and see how many people were basically asking “how can I update my password” or “how do I move information between projects?”.
We could run a report that would simply give us the top 10 questions this week. Are they the same as last week’s top 10? Are we seeing a pattern? What’s up? What’s down? Now we have specifics that we can act on. In the past we’d know there were 60 questions in the “milestones” tag, but that doesn’t really give us anything to act on. But now we’d know there were 23 questions about “How do I add more than 10 milestones at a time”, 21 about “Can I move milestones between projects?”, and 16 about “Can I add times to milestones?”. Now we’ve learned something.
Obvious isn’t always obvious
Looking back at this it seems obvious. We should have done this from the start. But like many things, it’s easy to get carried away. This new tool gave us all sorts of tracking options. Categories, tags, custom fields, lookups, etc… So we got excited and confused enthusiasm with priority. We did a lot of busy work but didn’t learn anything.
So just a reminder: Know what you’re measuring. Data for the sake of data can be a fun intellectual exercise, but practicality is usually what you’re after.
LessEverything’s UI Test Results #3: Flipping “See the Tour or Try Less Accounting Free” so button is on the right improved conversions from 12.3% to 13.8%.
I don’t care how good you are at programming, finding bugs, whatever. If you’re rude, or if you speak poorly to people who don’t understand your… quirks…. you will wind up being shunted to the side. No one wants to work with someone who makes them feel beat down all the time, or someone who they simply can’t understand, or someone whose reaction to every issue is to start wailing about the end of the world.
I have a couple of technical presentations coming up that I wanted to let everyone know about. I’ll be talking about a couple of things that have been holding my interest for the past few months: Chef and Erlang.
For the first talk, I’ll be giving an overview of Chef, a tool that we’ve been using for few months to automate our system administration tasks. If you’re in or around the Raleigh, NC area tomorrow night (June 16th), come out to the Raleigh.rb meetup and join us.
The second talk will be at Erlang Factory in London next week. I’ll be talking about our use of the Erlang programming language in the Campfire poll server that we recently discussed right here on SvN. I had the good fortune to attend the first Erlang Factory in the United States at the beginning of May in Palo Alto and it was one of the best conferences I’ve been to in years. If you’re at all interested in Erlang, it would be worth your while to think about attending the conference.
So the Lakers win another NBA championship. I haven’t always been a fan, but I’ve got to admit it was really fun to watch Kobe Bryant this season. He seemed to have an almost maniacal determination to win another championship. People compare him to Michael Jordan and, while they’re both incredibly talented, you get the feeling that what really separates them from the pack is how badly they want to win.
Along those lines, a great documentary to check out is Spike Lee’s Kobe Doin’ Work (Netflix). Bryant gave the filmmaker unprecedented access to his life for one game. He’s mic’d up, 30 cameras follow him, and coach Phil Jackson lets the crew into the locker room before the game, at halftime, and after the game too. Here’s a preview:
It’s fascinating to watch even though the game was a blowout. Also, there’s a great storytelling lesson here too: Tell a story about less. See, the impulse is to go for a grand tale. In this case, it’d be to prove how great Kobe is by profiling his entire career or trailing him for an entire season. Along the way, you’d interview teammates, experts, etc. And you’d come up with a pretty generic piece.
By focusing on just a single game, Lee put a magnifying glass on how Kobe plays. Cameras trail his every move so during every timeout and every play, you get to see and hear how Kobe guides his teammates. It completely changes the way you view both the player and the game. There’s no filler or outside input. It’s just a laser focus on this one subject during this one day.
Sometimes it’s easier to get a big message across if you narrow your scope. It’s what we tried to do with our Behind the scenes at 37signals series which presented a look at one week of 37signals’ Campfire usage. Not as exciting, perhaps, but the idea was similar: To tell the big story of how integral Campfire is to us, it was best to focus on a short period of time. Sometimes the perfect way to explain a universal truth is through an individual example.
Also, if you watch the documentary, Lee is incredibly loose with how he asks his questions. It means that Kobe is really relaxed and open with his answers too. If you’re ever doing interviews, it’s something to note: Go in with stiff questions and you’ll probably get stiff answers. Go in loose and you’re more likely to get your subject to open up and admit things to you they probably wouldn’t otherwise.
This new animated YouTube logo is super distracting. How are you supposed to concentrate on a video when there’s this flashing static/rainbow thing in the corner? It’s like the site is trying to force you to go fullscreen mode now. If your branding gives customers a headache, it’s not really such great branding.
Update: Apparently it’s a one-day thing to commemorate the change of TV from analog to digital. But still…
We blame bureaucracy for being wasteful and taking too long when things like the Denver International Airport or Boston’s Big Dig arrive years overdue and billions over budget. But it’s not just huge organizations and the government that mess up planning. Everyone does. It’s the “planning fallacy.” We think we can plan, but we can’t.
Studies show it doesn’t matter whether you ask people for their realistic best guess or a hoped-for best case scenario. Either way, they give you the best case scenario. It’s true on a big scale and it’s true on a small scale too.
We just aren’t good at being realistic. We envision everything going exactly as planned. We never factor in unexpected illnesses, hard drive failures, or other Murphy’s Law-type stuff.
If you believe 100% in some big upfront advance plan, you’re just lying to yourself. There’s a good side to this too though: You’re liberated. That messy planning stage that delays things and prevents you from getting real is, in large part, a waste of time. So skip it. If you really want to know how much time/resources a project will take, start doing it.
For my first project since joining 37signals I’ve been working on an update to the venerable Account (Upgrade/Billing) screen in Basecamp. We’ll post more about that update and the process to get there soon, but I wanted to share an experience I had as part of this design.
We had decided to include a few short handwritten phrases as graphic elements. Sometimes in the perfect world of web design, elements that have an organic, handmade look can soften the message and draw the eye. These phrases enhance the message but don’t convey any hard data that is intrinsic to the upgrade decision. That makes them a good place to have a little fun and lighten things up.
So, I wanted to make them look as if they’d been casually written directly on the page. They needed to look casual and authentic so no fonts. It can be tempting to use a script or handwriting font for an application like this, but they never fool the eye. I learned a long time ago that you can’t fake it — if you want something to look handmade, make it by hand.
But what I found is that this task was a lot tougher than it sounds. I must have written and re-written some of these phrases more than 50 times trying to get just the right flow, the perfect amount of flair, and a cohesiveness with the other phrases. But “perfect” was exactly the wrong approach here. Handwriting isn’t perfect and the irregularity is where the character and charm I was going for would come from. So I settled for “good enough”, which turned out to be ideal.
So instead of carefully drawing each letter and placing them together, I practiced a few times and just wrote each one out as quickly and naturally as if I was writing in my notebook.
My fingerprints — almost literally — are going to start showing up in 37signals products in the coming weeks. I’ll be sharing more of the process as we go.
How the term “trial balloon” originated: The Montgolfiere brothers came up with a design for the hot air balloon but wanted to make sure it would really work before getting in one themselves. So they first released several unmanned trial hot air balloons. Then they sent up several farm animals to make sure the air at higher levels was safe to breathe. After that, they tried a manned expedition.
It’s a smart approach. But in the business world, a lot of people think the opposite is the way to go. They want to launch big. They want a huge PR splash right away. They want the big bang.
Too bad. You don’t need a big bang – slow evolution is what you want. Unless you absolutely must “open wide,” abandon the mass introduction strategy. Instead, launch softly.
Restaurants start off by serving friends and family before they invite the media.
Movie studios use test screenings to fine tune movies. The people behind the scenes know that until you get into the test screenings and see what people really think, you just never know.
Likewise, Jerry Seinfeld and Chris Rock try out jokes in small clubs before hitting arenas.
Authors test out material by writing magazine articles, ebooks, and/or releasing chapters online. Michael Pollan started off an article in the New York Times with these words: “Eat food. Not too much. Mostly plants.” Those same words appeared as the main theme of his book “In Defense of Food: An Eater’s Manifesto,” published a year later.
You don’t have to paint a finished picture before launching. Customers can connect the dots.
Soft launching lets you tweak and revise. You get the word out there and you gauge interest. You know what works and what doesn’t.
Plus, you get to make mistakes while you’re still in the shadows. Messing up in front of a smaller crowd means you’ll be better off when the bright lights eventually do shine upon you.
Developer/API The new 37signals API developer list
“The new 37signals API developer list is meant to be the new hub for all things 37signals API. A place where developers can discuss their experiences and challenges working with the APIs from Basecamp, Backpack, Highrise, and Campfire. We’ll try to make ourselves available as best we can to help answer questions and provide clarification on implementation”
Improving the Basecamp API
“We’ve been working behind the scenes to improve the Basecamp API. One recent change lets developers know whether the person making an API request is from a client or an internal firm.”
Highrise The Star-Ledger: Highrise is a a new breed of CRM that emphasizes simplicity
“I particularly like the description used by 37 signals, the makers of the Highrise CRM: Highrise is a great way for business to keep track of who talked to whom, what was said and what needs to happen next. The software excels in the way it blends contact management, to-do lists and other features. You look at a contacts page in Highrise, and you have a window into your communications with that person, notes from meetings, background and any tasks related to the contact.”
Backpack TUAW: “Satchel is Backpack on the iPhone done right”
“It’s worth every penny for the true Backpack fanatic. It’s gone a long way to removing the barrier for those looking to embrace Backpack as a service, but feeling a little hamstrung by the lack of a decent mobile interface. If you love Backpack, you’ll love Satchel.”
When I was first getting serious about web design I discovered Jakob Nielsen’s Alertbox and was totally inspired. There was something about the ascetic style, black verdana type, yellow header and scattershot of bold that just fascinated me. I pored over the site and stayed up late at night reworking projects with fresh inspiration and higher standards. I even found a company to work for that was as nerdy about this stuff as I was. And then somehow—I don’t know how—I just forgot about the guy.
Timelessness is a mark of mastery. And few things are healthier than being reminded of how your best work rests on the shoulders of people who inspired you through their example. So I’m glad I took some time today for a usability refresher from Mr. Nielsen.
People want to know how I started Teach For America straight out of college, and honestly, my greatest asset was my inexperience. It proved absolutely critical at many junctures. When I declared in my thesis that I would try to create this corps myself, my thesis adviser pronounced me “deranged.” When he looked at my budget of $2.5 million for the first year, he asked me if I knew how hard it was to raise $2,500, let alone two and a half million dollars. But aided by my inexperience, I was unfazed by these reactions. When school district officials literally laughed at the notion that the Me Generation — this was the label for my generation — would jump at the chance to teach in urban and rural communities, their concerns, too, went unheard. My very greatest asset was that I simply did not understand what was impossible.
I’ve been staring at a project in my backyard for a few weeks. Staring hasn’t gotten it done. So I figured I’d see what it would cost to have these guys do it.
I called them. 10 minutes later the guy came by. He was down the street on another job. We walked out back. I told him what I needed done. He looked around for 20 seconds and said $300. I said “deal.”
That’s it. No proposal. No “I’ll get back to you tomorrow”. No “Let me see how much the materials will cost and I’ll drop an estimate in your mailbox next week.”
Just $300. Deal. When can you start? Wednesday. How long will it take? A few hours for a few guys.
He knows his business. I know what my time is worth. End of transaction. It was so damn refreshing.
I know everything can’t be done like this, but often it seems like we’ve slid down a path of formality with so many things that really don’t need it. Extensive contracts, delays, red tape, precise cost estimates based on precise amounts of materials, “let me think about it and I’ll get back to you,” etc. Essential? Sometimes yes, but most of the time probably not.
I remember the tail end of our time as a web design company. When we started we did 20 page proposals. I remember pulling all nighters getting a proposal ready. Pages and pages of stuff. What a waste of time.
Towards the end we were doing one page proposals. It didn’t seem to matter. We were going to get the job or we weren’t. Over six years I never saw a connection between length and detail of proposal and winning a job.
Same thing with contracts. Sometime we hire an outside contractor or specialist to give us a hand on a project. Our contractor agreement used to be 8 pages long. Lawyers wrote it. Our current contractor agreement is one page long. I wrote it then showed it to our lawyers. They said it was fine. Done.
I know it seems like a stretch to compare lessons from a door flyer for a small landscaping job to 10 page legal contracts for 3 month long expensive web design projects. But maybe it isn’t.
You can tell a lot about a culture by the sort of person it ostracizes. David Heinemeier Hansson, 29, a successful tech entrepreneur, is something of an outcast in Silicon Valley. Here are the pronouncements that have earned him his banishment: Companies should not be ashamed to charge for their products. They should expect to be able to make money off their customers. Finally, they can’t use volume to turn losses into profits…
“Startups these days are getting all the wrong lessons,” says Hansson. “[They think] that all that matters are users, that they should take on plenty of debt from venture capital investments because something magical will come along at some point and everything will be okay. But you can’t make up something in bulk that is a losing prospect to begin with. Isn’t that self-evident?”
(Note: There are a few inaccuracies in the piece, most notably that Ruby on Rails is a 37signals product which impacts our financial success. Not so, it is an open source framework.)
Last week we had a 37signals retreat in Kohler, Wisconsin (the company that makes faucets and plumbing fixtures also has a resort). We got to catch up, plan ahead, meet the newest members of the team, took the Kohler factory tour (some pretty amazing stuff happens to get those faucets, tubs, and toilets made), dined at a cabin in the woods, made lots of trips to Sheboygan to eat at the excellent restaurants of chef Stefano Viglietti, and went canoeing.
And by the way, contrary to popular belief, this is NOT how 37signals handles feature requests…
Jason Fried, David Heinemeier Hansson, Sarah Hatter, Ryan Singer, Sam Stephenson, Jamie Dihiansan, and Michael Berger in Chicago, Matt Linderman in NYC, Mark Imbriaco in Wake Forest, North Carolina, Jeremy Kemper in Pasadena, California, Jeffrey Hardy in Ontario, Canada, Joshua Sierles in Granada, Spain, Jason Zimdars in Oklahoma City, and Mr. Jamis Buck in Caldwell, Idaho.
