There’s a popular book on entrepreneurship called The E-Myth which claims that bakers shouldn’t run bakeries, plumbers shouldn’t run plumbing companies, and everyone else should think about how they could turn their small business into a franchise. On the face of it, there’s a lot of good advice about how you can’t just be a good baker if you don’t have a business bone in your body and expect commercial success.

Problem is that the reverse is also often true. If you just put MBAs in place — or other professional managers without deep subject matter expertise — you’re equally likely to end up with an uninspiring business that fails to be passionate about the right things. To stay on the ball you need to know what’s a good pass and the best way to do that is to be able to make one yourself.

Many of my favorite companies are driven by people at the top who intimately know how things should be because they could make them so. The obvious example is the detail-oriented nature of Steve Jobs at Apple. But a few other examples I like are Ulrich Bez at Aston Martin who’s not only the CEO but also part of the company racing team at places like Le Mans. Or Thierry Nataf at Zenith who’s CEO and head designer of their luxury watches as well.

But what made me think about all this was Joel Spolsky’s tale of a technical review with Bill Gates back in the 90’s:

Bill Gates was amazingly technical, and he knew more about the details of his company’s software than most of the people who worked on those details day in and day out. He understood Variants and COM objects and IDispatch and why Automation is different than vtables—and why this might lead to dual interfaces. He worried about date and time functions. He didn’t meddle in software if he trusted the people who were working on it, but you couldn’t bullshit him for a minute because he was a programmer. A real, actual programmer.

For people who love what they do, whether that’s programming, design, designing watches, or building cars, that’s a great motivation to not grow your company too quickly. Enjoy the time when you can actually be a full participant in the actual activities themselves, rather than just managing them.

We recently added a support request form to Basecamp (there used to be just a direct email link). The goal of this form: To prioritize support inquiries, reduce uncertainty, and get people the answers they need faster. It also reduces the number of back and forth information-gathering emails, which ultimately makes everyone more satisfied with the support experience.

It’s worked really well so far too. But the last question in the original form was missing the mark:

We wanted to know how important the problem was and gauge the emotional state of the person writing to us. But this pulldown just didn’t cut it.

First off, it required too much reading for a pulldown menu. Who wants to process this much info when there’s a problem? Also bad: It’s a pulldown but the options aren’t mutually exclusive. Someone could very well be confused AND worried AND upset. This pulldown just muddies the waters.

So we decided to change it to an actual scale. 1 = not a big deal, 4 = I need help ASAP.

Much easier to process but it still wasn’t helping us learn whether or not this query was a top priority or not. Why? Because everyone’s problem is urgent.

For example, let’s say someone’s having trouble uploading a file. If they can’t figure out how to upload a file, they’ll say it’s urgent. If file uploading is broken, they’ll still say it’s urgent.

That’s no help to us. Of course, we’ll get back to them either way. But if file uploading is broken, we need to know that immediately so we can fix it. If it’s just confusing someone, that’s a different ballgame. We’ll still quickly resolve the issue, but it’s not a fire that has to be put out instantly.

We thought about adding in a radio button question that asked “Is something broken?” But we didn’t want to make the form any longer. (No one likes feeling interrogated while seeking help.)

So we went back to the drawing board and came up with this solution:

This gets at what we really want to know here: What kind of problem is this? We lost the subjective nature of the original “give us your emotional state” question and replaced it with a clear question with a clear answer. It’s better to ask for facts than emotions.

Now, if something’s broken, we can spot it and fix it right away. A system failure is much more important to us (and our customers) than a feature request or general feedback. This method lets us prioritize these queries accordingly, instead of treating them like they’re all the same.

Update: Per feedback on this thread, we’ve adjusted the menu to the following (more consistent language, no more “general feedback” category since “other” is close enough). Thanks for your comments.

Related: Copywriting is Interface Design [Getting Real]

Mike Rohde did another great job drawing sketchnotes at the SEED 3 Conference on June 6th, 2008 (below). Sign up to get notified when we announce the next SEED.

Continued…

I’m working on some improvements to Basecamp, specifically the screens where you manage which people have access to a project. There’s an area on our new template with checkboxes beside peoples’ names so you can check which people should be added to your project. I want to apply a class name to the label tag around the checkbox for each person. So I pulled up the template and searched for “label” to find where I might add the class name. There were no matches. So I dug deeper, and saw that the HTML for the label, checkbox, and person name is being generated by a Rails helper method.

This is the template code that calls the helper method.

<% people_without_access_from(company).each do |person| %>
  <%= add_person_to_project_check_box(person, company) %>
<% end %>

Next I pulled up the helper method to see if it really is responsible for producing a chunk of HTML with the label and checkbox.

def add_person_to_project_check_box(person, company)
  content_tag(:label,
    check_box_tag("people_ids[]", person.id, false, { :class => "company_#{company.id}_person" }) +
    " " + person.name
  ) + tag(:br)
end

Yup, it’s generating the HTML. Right away this smells bad to me. The helper is first generating a label tag. Inside that label, there is a checkbox followed by a space character and the person’s name. Finally a break is appended after the label. This smells bad for two reasons. First, it’s just not so nice for helpers to cook out HTML when they don’t have a good reason to. Second, it’s harder to locate and change HTML when it’s hidden inside a helper.

Returning to my original goal, I wanted to add a class name to the label around this checkbox. If I add the class name to the existing helper, it’s going to get even more messy and complicated because I have to give content_tag an attribute with the class name I want. It would look like this:

def add_person_to_project_check_box(person, company)
  content_tag(:label,
    (check_box_tag("people_ids[]", person.id, false, { :class => "company_#{company.id}_person" }) +
    " " + person.name
    ), :class => 'checkbox') + tag(:br)
end

To find a better solution, we should rethink what the helper should be responsible for. Helpers are useful when they hide complexity that isn’t relevant to the template. Looking at this helper method, I see that it’s useful to hide away check_box_tag with all those params. But the label, the break, and even the person’s name could all be in the HTML and the template would be clearer. Let’s do that.

Here’s the new helper. Now it only produces the checkbox.

def add_person_to_project_check_box(person, company)
  check_box_tag("people_ids[]", person.id, false, { :class => "company_#{company.id}_person" })
end

And here’s the updated template code, with the label, person name, and break moved over.

<% people_without_access_from(company).each do |person| %>
  <label class="checkbox">
    <%= add_person_to_project_check_box(person, company) %> <%= person.name %>
  </label><br />
<% end %>

Now that’s a lot easier to read. Generally speaking, it’s a good idea to keep your HTML in your templates and out of your helpers. Helpers are useful when they hide implementation details that are irrelevant to your template, or when they allow you to abstract common template code to avoid repetition. If you find yourself generating a lot of HTML in a helper, think twice and try to keep as much HTML in your template as possible.

“I’ve made much more money by choosing the right things to say no to than by choosing things to say yes to. I measure it by the money I haven’t lost and the quality I haven’t sacrificed.”
-Danny Meyer of the Union Square Hospitality Group

Great quote. From the book Small Giants: Companies That Choose to Be Great Instead of Big. More about the book:

It’s a widely accepted axiom of business that great companies grow their revenues and profits year after year. Yet quietly, under the radar, some entrepreneurs have rejected the pressure of endless growth to focus on more satisfying business goals. Goals like being great at what they do . . . creating a great place to work . . . providing great customer service . . . making great contributions to their communities . . . and finding great ways to lead their lives.

In Small Giants, veteran journalist Bo Burlingham takes us deep inside fourteen remarkable privately held companies, in widely varying industries across the country, that have chosen to march to their own drummer. He searches for the magic ingredients that give these companies their unique “mojo” and the lessons we can learn from them.

Related: Danny Meyer: Hospitality is king [SvN]

Our friend, and former 37signals-founder, Carlos Segura has redesigned Cartype: “A museum of automobile typography”. Very nice redesign (here’s the old site for comparison).

But it’s really so much more than that. Take his museum of gauge clusters:

Or his obsessive collection of brand emblems:

If you dig cars, you really outta check out the new Cartype.

I love me some padded link targets and today’s provider is a Working Library.

The site is about books and their connections. Each post references one or more books and the referenced books are aggregated in the right-hand sidebar. When you hover over a book title, the crisp tiny type is immediately enveloped in a big cozy hover block.

I particularly like how the hover reinforces the column dimensions. It’s a sudden punch of structure to the otherwise airy layout.

(Found via JSM’s oddities)

Last week I was in Seattle for a couple days. A friend suggested I check out the new Olympic Sculpture Park. It was near my hotel so I walked over there to see what was up.

Seattle

Nice landscaping, nice setting, nice sculpture, but the lasting impression wasn’t made by the art, it was made by a sign (actually, about 10 signs):

They even had an extra specific warning in one spot that “Even the lightest touch harms the art… Help the art survive… PLEASE DO NOT TOUCH.”

Public art in a public outdoor space in the middle of public paths and public lawns yet you can’t touch it. The only interaction is visual. It’s standoffish. It feels like a missed opportunity.

Chicago

Contrast this with Chicago’s Millennium Park. Public art and architecture that is entirely interactive.

A fountain that spits on you:

Or a snaking bridge that you can walk or hang out on:

Or reflect in public:

Chicago understands public art in a public space. The public will only be interested if they can engage with it. Walk on it, play it in, look into it, touch it, brush up against it. If you go to Millennium Park you’ll actually see and hear kids playing over the place. I don’t think you’d see a single kid at the Seattle Olympic Sculpture Park having a good time. I didn’t see any adults who were particularly interested either.

Alan Taylor of The Big Picture proves how designers who can also develop are able to get things done without jumping through hoops of approval, explanation, and cycles of review.

In an interview at Waxy.org, Alan talks about how The Big Picture came to life within the Boston Globe.

I have an advantage in that my main role is as a developer here, so I could build all my own templates, format my own style, and so on. I sort of bullldozed some things through though, like extra width, few ads, and I made it simple internally by doing it mostly on my own, no requests for development time, marketing or promotion. After the legal questions were settled, I was free to try it out. It took off fast.

This is another example of why I strongly advocate that designers build development skills into their kit. When you’re able to do things yourself, you can just do them. You don’t need anybody’s approval or anyone else’s time. And sometimes that makes the crucial difference between an unimplemented idea or a great success like The Big Picture.

Edith Macefield, 1921-2008.