More and more, mobile devices are a major point of contact with Web sites.  Having heard questions about making mobile Web sites from my colleagues and clients, I have begun brainstorming about the process required to make a successful mobile Web site version of an existing site.  With less real estate for a Web design, designers may feel that making a Web site for a mobile device is more restrictive than the original Web dimensions of 640 by 480 pixels at first glance.  Looks can be deceiving, especially when not looking at the big picture.

The Big Picture: Design for the Audience First

Like any Web site design, the journey begins with content.  Often, information architecture leads us down a path of organizing existing information for a Web site.  If none exists, plans are made to add content.  The magic ingredients for what makes up the content of a site is often determined by industry practices, competitor Web sites, and what the client wants to place on the Web site.  Every situation is different, and clients may ignore the first two reasons if you do not show them the ROI from following them.  But I have left out the most essential ingredient from this list: audience want.  This is where most Web site designs go wrong.  And it is no different for a mobile Web site.

Determining what an audience wants from a Web site requires a little investigative research.  Digging deep and analyzing the competition’s information architecture is the first step.  You can easily tell when a Web site is designed for the clients rather than audience when the language used for links, navigation, and headings refer to brands or terms not quickly identifiable by the average Web user.  Steve Krug addresses this issue succinctly in his Don’t Make Me Think book where he breaks down the name for a link that points to job listings in a human resources department.  He takes us from “Employment Opportunities” to the basic, short, and clear “Jobs” title for the link.  The key point to remember is that the guts of a Web site—its naming for links, navigation, and headings—all have to be clear in order to be effective with the average Web audience.  If a site is designed for a particular audience, then the limitations scope can change to suit that audience.  To help in designing for a particular audience, create mock user profiles to frame assumptions about who will visit the site and analyze the information architecture and vocabulary from that perspective.  You will need to compromise with the client’s needs for promotional content, so keep looking at all content through the audience lens to suggest the clearest way to present information.

The next step is hardest: user testing.  This step may only be used if the resources (e.g., time and users) are available.  After carefully creating the Web site from the information architecture plan, you can test its usability with actual users from the targeted audience (NOT the client) to yield whether it is successful or any alterations are needed.  In time, you will uncover several similarities between users that you can plan for in any initial Web design.

Next Steps: A Tale of Two Web Sites

Now that you have the Web site designed and structured for the targeted audience, creating a mobile version of the Web site should be easy.  If you thought this was true, think again.  The goal of a mobile version of a Web site should not be to mimic the same Web site in a different format for a mobile device because mobile users may only want specific features of the site that they access often.  With mobile sites for Facebook and the Internet Movie Database, the users are looking for a quick way either to get to Facebook status updates or a movie search.  Advertisements and all the detailed functionality found on the regular versions of those Web sites are removed to accommodate the largest want from the targeted audience.  Without a solid Big Picture plan, you could not follow-up easily in narrowing the scope to only user’s wants.

Without this delineation between a mobile and “regular” Web site, the content would remain the same and the design would somehow have to accommodate both radically different display devices for those types of sites.  The answer in that situation would be to create a rather complex series of checks to determine the browser being used, the resolution for the browser, and perhaps even the hardware device viewing the site.  Much can be done with standard CSS to deliver pages based on browser and resolution.  Other checks may be more problematic.

The Technicalities

Most Web designers are familiar with the standards approach of creating a separate style sheet for print.  This style sheet often turns off elements on the page (e.g., header, footer, ads, etc.) so that only the page contents is printed in a manner effective for the print medium.  A similar approach may be used to deliver a mobile version of a Web site after determining whether a user is viewing the Web site with a mobile device or the resolution is very small.

Recently, I redesigned a poorly formatted password management tool that used tables for its layout into an adaptive framework.  An adaptive framework is a grid-based layout system created by CSS and jQuery that presents a Web page based on browser width.  The framework I used was Joni Korpi’s Less Framework.  What resulted was a simple design that works well on mobile devices.  Check out my final design using Less Framework on Berea College’s Password Management site, which is a modification of Turbo-IT’s Self Management of Passwords.  (Unfortunately, much of the table code had to be commented out rather than removed so that the calls from ASP.NET controls compiled in a DLL would still function.)

Using an adapative framework may just be the first ingredient to delivering a mobile Web site version.  Other ingredients may also be Include statements and modularized Web design (static- or database-driven) to avoid duplication of content between the sites.  Even with ID labels for style elements, sections of pages can be reformatted or hidden completely based upon parameters set by browser and resolution checks.

What about You?

Have you designed a mobile Web site?  If so, how did you do it?  What approaches did you take?