I don’t have a Ph.D. in ergonomics. I didn’t even stay at a Holiday Inn Express last night. But still, I have to say, I have to disagree with Jakob Nielsen in his blog post. Jakob states that if you build a mobile site (and he recommends that you do), that you redirect users to it automatically.

This is not that different from the incredibly annoying tendency of sites to offer you their mobile app with the persistence that the talking toaster from Red Dwarf offers you toasted bread products.

Stop. Please. Take a step back, my Web developing, app developing friends. It’s time to educate the executive suite on use cases, before they shove “WE NEED A MOBILE SITE!” or “WE NEED AN APP!” down your throat.

Too many sites today are focusing on building “mobile” versions of themselves, when a large, and growing, percentage of the population is using smartphones that, even with small displays, have incredibly full-featured Web browsers that can render most sites normally, and feature pinch to zoom functionality in the event of site elements being too small to easily “click” on with a fingertip.

Let me explain a bit. There are at least two distinct types of Websites in this world. Probably more, but at least two key categories. Those sites are:

1. Content-based Web sites. Examples include Slate, Salon, Fox News, New York Times, News.com. These are sites you go to to read content. To browse. Think of a library where you’re just wandering the shelves, and perhaps consulting the index.
2. Task-based Web sites. Examples include your bank, Expedia, the Delta or Amtrak Web site, or Urbanspoon. These are sites you go to in order to accomplish a task. Think of the DMV. You’re there to renew your plates or driver’s license, or get new plates or a new driver’s license.

If you’re building a content-based Web site, and you’re not filling it with advertising, or so many link targets that it’s unusable with a full PC or Mac, and you haven’t used obscenely tiny text, then honestly, it’s going to render pretty well on an iPhone, and likely incredibly well on an iPad. It is my belief that if you have a content-based Web site and you build a mobile version of it for your users, you’re doing most of them a disservice. If you shove everyone to the mobile site, you’re doing all of them a disservice. If you do that to an iPad user, you’re just making yourself look incompetent.

The Web browsers on the three predominant smartphone platforms are all pretty capable. The browser on the iPad even more so. As long as you’ve taken the lack of Flash into account and provided h.264 video instead, there’s really not much work you need to do. If you build an entirely new site for mobile users, I believe you’re wasting your time, versus simply driving a concerted effort to make your site more usable and more consumable (and building in a good content search/improving your SEO).

If you’re building a task-based Web site, there is perhaps some logic to building a mobile app, but if (BIG IF) and only if you understand every, single course of action a mobile user might want to make. This is critical. If you’re an airline, and you miss a single “verb” that a user might want to take advantage of, you’ll make their life more painful than if – as above – you had simply focused on site usability, navigation, and SEO. Make your seat change page the first result that a user hits when they search for “Delta change seats”  (which isn’t the case, as best as I can tell).

For task-based Web sites, hitting every potential target is critical. Your user may well be mobile, but more often than not, whether they’re mobile or not, they want to get something, a task, done. I’ve explained this concept of simplified design before.

More importantly than all the above, let me offer you 10 “to-do’s” that I believe to be important when considering your Web site, any “mobile ‘optimized'” versions thereof, as well as an app, should an app actually make sense.

1. Think of how you treat your users when they navigate to your Web site, regardless of site type. Do you take them to the content they wanted to go to? Or do you insist on asking them questions? Do you like it when Windows or your Mac (or a crappy app therein) asks you petulant questions, or keeps you from simply accomplishing the basic task you want to accomplish? No. You don’t. Why do you do that to your users?
2. If the referrer to your site is Google, Bing, or any other search engine, DO NOT ask the user about a mobile site. DO NOT ask the user about your app. DO take them to the page they clicked on, unless you want to learn what “bounce rate” means. Interstitial dialogs as the welcome to your site on search results are user hostile, insulting, and they make you look stupid.
3. Focus on your site usability first, whether your site is content-based or task-based. Simplify your normal site, and make video mobile-viewable.
4. Focus on your SEO next – when a user looks to accomplish a task with your brand, what’s the first result they get on Google or Bing? If it’s an FAQ page or help document, that’s not really very helpful. Take them to a verb. Take them to where they can accomplish a task – whether they’re on a mobile device or a full PC/Mac.
5. If you conclude that you absolutely must make a mobile version of your Web site, provide an easy to see escape hatch to your full site, allow users to permanently opt out of your mobile site, and when you redirect them, take them to the page they originally wanted to go to, unless you also want to learn what “bounce rate” means. The most passive-aggressive thing you can do to a user is the “Mobile site bounce”, where you decide taking them to your mobile site is more important than taking them to the content they wanted to see, or fail to keep the content reference when redirecting back to the full site as they’ve requested.
6. Focus on your site usability first. Simplify your normal site, make video mobile-viewable.
7. Don’t shove users to the mobile experience on content-based Web sites by default – at least not on modern smartphones, and definitely not on the iPad. Make it an option for smartphones.
8. If you run a Task-based Web site, a mobile version of your site may make sense – but only do so if you clearly understand every single task a user may want to accomplish while in the “mobile” version of your site.
9. If you run a Task-based Web site, a platform-specific app may make sense. But again, don’t do it unless you really understand all of the tasks a user may want to accomplish on your site, and you’re willing to provide them all through your app. Building an app that doesn’t let people accomplish the same things your site can do is, frankly, nonsensical – and you’re going to end up ticking off your users. Why do that?
10. If you run a content-based Web site, or you have a discussion forum, for all that is good in the world, please do not insist on always offering up your mobile app. It’s great you paid a developer too much to build it for you. But listen – if a user is on their iPad or smartphone, in Twitter, and you offer them your app instead of the content – it’s beyond useless. Ask once if you must, but don’t ask again. And really – you shouldn’t ask to begin with. Users don’t install apps for every single site they visit. If they did, they’d run out of space on their smartphone, and it would be an incredibly unusable model.

Remember – a poorly engineered “mobile” Web site is no better than not having a Web site at all, and a poorly engineered app is no better than not having any app at all.

As I said in my simplify post: “It’s better to do one thing really well instead of two things half-assed.” Consider your “mobile” site and your app that second thing. If you don’t know exactly what you’re doing, and you’re unwilling to take into account every single user scenario, please keep your finger off the trigger, and just focus on making your normal, good old-fashioned Web site itself simplified, usable, and SEO optimized.

Update: Several readers have pointed out the use of the word “responsive” as a design goal that developers should work towards. Indeed, as I recall working at two previous startups, our biggest pain point – the thing that made us look bad – was that we were the last thing to load on a page (an add-on JS script), and all too many content sites are not optimized for fast download of page content, or for optimal rendering. Making your primary Web site responsive, reducing your page weight (and as a result, your page wait), and making sure that your content renders fast in any browser should all be primary design goals for any good Web developer. Oh, and if you have a slow ad engine, you’re causing bounce too. Ad engines are notorious for being slow to load – and they can easily pin the whole page while the user waits for the thing they care least about.

Don’t make a mobile site because your regular site’s performance sucks or your pages are too heavy. Improve your regular site’s performance instead, so every user gets benefit from it.