I’ve been hard at work transcribing some of the interviews that I have done in the last several weeks for Drupal for Designers, and I just came across this great conversation with Todd Nienkerk that didn’t quite fit in the book, but was still a Very Interesting Conversation. I offer it below, for your reading pleasure.
Todd, if you’ve never met him, is one of the founders of Austin’s Four Kitchens, a team that works on big websites for great clients. They’re also the people who co-created Pressflow, a Drupal distribution built especially for large-scale websites, and they also run DrupalCamp Austin, which is happening in November.
The following conversation happened a few weeks ago, and covered a huge range of topics — mostly grid systems, design for Drupal, responsive design and various snarky tangents. In this bit of it, Todd and I go off on restaurant websites, and we also talk about working with clients who don’t understand the cost of creating a good web presence.
Todd: I have noticed that the #1 factor in project success from a design standpoint is: has the client done this before?
If this is a client who has tapped three or four people who are junior-level, or are new to this, and they’re communications or marketing people or something, and the CEO says “hey, we need a new website — you’re sort of in charge of that…”
Dani: yes — “you’ve done HTML before, right?”
Todd: exactly, and the person is thinking, “I’ve never done this, I’ve never built a website before,” they come to us and they say, “hey — I’ve never been through the process of building a website before and I don’t know what to expect.” There are two possible outcomes that come from that. Either they have full faith in us, and their bosses have full faith in us, or they listen to us, and they have full faith in us, but their bosses don’t. Or their bosses are saying “we’re a non-profit that has never really done a serious website, and we don’t really get project management — I don’t really understand why UX is necessary. It seems like a lot of extra fluff to me.”
They don’t take us quite so seriously, or their attitude is, “that looks good enough. I don’t want to spend any more money on design. I just need the website to ‘do’ certain things. I don’t really care how it looks.” Those are typically the people who have never been involved in a web project before.
Dani: I also find that part of dealing with non-profits, especially in the client intake/sales process, is reading between the lines, and listening to how they *say* “we’re a non-profit.” I’ve done a lot of work with non-profits, and I find often in conversations with fundraising/development managers that if you hear them say, “well, we’re a non-profit,” in a certain tone, that it’s often a cover for a host of things that they don’t want to deal with.
Todd: Yes, that ends up becoming code for “we’re a non-profit, so we do everything bare-bones.”
Dani: Yes. We do everything bare-bones, we don’t have a lot of money, and to put a sort of New Age spin on it, it’s sort of a “lack” vs. “Abundance” mentality; you think that because you’re a non-profit, you basically have to spend almost no money on your marketing; meanwhile, if you look at the list of biggest, most effective non-profits with the largest reach in the Boston area, most of them spend about 5-6% of their revenues on fundraising efforts — including their website. They’re spending that money, and as a result, they are getting more donations, and they’re able to do more work, than perhaps 100 smaller non-profits in that space combined.
Todd: it’s surprising, too, how many people don’t seem to understand that the most effective dollar they can spend is on a better website. It’s sort of like, when you go to a restaurant’s website, what do you care about? Phone number, address, menu. That’s really all you care about. Who’s the chef? That’s an afterthought — that’s what you might get into when you’re starting to dig around and learn more about the restaurant.
Chances are, when you’re at a restaurant website, you’re about to leave the house and go out to eat, you need the number for reservations, you need the address so you can look it up on a map, you need a menu to make sure that your friend who’s gluten-free can actually eat something there. Or you’re looking at it — which is even more likely — on your phone, and that address is locked into an image, and you have to somehow put that address into your memory long enough to switch apps on your phone and type it all in to find the restaurant — or the menu is locked into a PDF, and you don’t have a PDF reader on your phone.
This is all super-basic stuff, and yet restaurant websites, more often than not, tend to be about the show, not about the information. That sort of conflicts with what I said about advertising dollars, but I suppose it depends on the industry. In the case of a restaurant, chances are that you’re not going to learn about the restaurant on their website, but on Yelp, or some other thing that is gauging its value. It’s not like a non-profit, where you do have to learn about the non-profit and what they do on their website. I don’t think there’s a real “rating system” for non-profits. You’re going to their website because you want to a) donate, or b) learn more about them.
I find that so many websites just assume that the website is little more than a brochure, or a television commercial, or it is some thing that is not a website.
A website has to do what the users of that site expect it to do. And restaurant websites are a good example of how many websites *don’t* do that, because they’re so egregious. They, on the whole, entirely miss the mark. You arrive on the website, and it’s a fashion show. It’s this Flash thing with all the dishes fading in and out, and all this sliding stuff, and you’re like “no. I don’t need this. I just need your address.”
Dani: well, I also think that, at least in the restaurant world, that you’re going to find all that other information on Yelp. So you don’t “need” to have it on your website.
Dani: The other problem, I find, with restaurant websites — I’ve actually done quite a few, and while I was able to talk them out of Flash slideshows, I’ve done my share of downloadable PDF menus — the biggest problem with creating a good restaurant website is actually updating the menu. The reason is that most restaurants don’t actually have a marketing person. The person updating the website is often the owner of the restaurant, or the owner’s son/daughter/whatever. They’re a chef, they often don’t have very much tech savvy, they usually work 12 hours a night or more.
If you’re a chain with a big marketing department, or you’re a hometown diner with 20 things on the menu that never change, it’s not a big deal, but if you’re like any of the restaurants that I’ve worked with, where you’re a relatively small place with a focus on local, seasonal food, you’re constantly changing your menu. With one of my clients, I basically just set up a Pages template and showed him how to upload a PDF. Because his menu changed every week, and he didn’t have the time or ability to figure out how to update the code of his website. Another client calls me every time he has to change his menu because it’s written completely in HTML and he can’t figure out how to make changes.
So yes, you’re probably just looking for the menu, or the contact information, but the problem with a lot of restaurants — and the reason I think so many of them are horribly bad — is simply because either they’re sort of “fashion” websites, where it’s not so much about the food as it is about the atmosphere, or they are restaurants where you have someone in charge of the website who doesn’t have time, knowledge or interest in maintaining this website.
Dani: So really, either way you’re screwed.
Todd: Yep. I imagine that partly, this is — and I think this speaks to all types of industries, and all types of websites — that so much of it requires buy in from the owner of the website, or the owner of the business it represents. In the case of restaurants, you need the owner or chef/owner to not only update the document where they update their menu and print it out — because no chef, no matter what, would not announce the menu in some way; whether they put it on a black board, write it on paper, or maintain it in a Word Document. Because, duh, you can’t not have a menu.
It should be, in my opinion, and I think that this will change over the next several years; it’s changing now, in fact — it needs to be just as “duh” that you have to update the website when you change the menu. Or maybe, you change the menu on the website and print it off from there. Maybe keeping the menu in a Word document or something similar is doing it backwards. Why not kill two birds with one stone and have a good printable template that’ll print directly from your website?
Dani: See, now that sounds like a Drupal distribution that needs to be made, there, Todd. I think we need to work on that.
Todd: [laughs] That would be be cool.
Dani: I think we’ve figured out what we need to do next.
Todd: You’d need one “menu” page node with a good, printable template.
Todd: I like this idea.