A User-Centered Approach To Web Design For Mobile Devices

Advertisement

For the past few years, we’ve heard pundits declaring each year as “year of the mobile Web”; each year trying to sound more convincing than the previous. Whether 2011 will be the real “year of the mobile” remains to be seen, but what is indisputable is the fact that the mobile usage of the Web is growing and evolving. As it evolves, so does the mobile user experience, driven by advances in mobile device technology — from better browsers on basic mobile phones (or feature phones — remember the Motorola RAZR?) to the increased adoption of smartphones and tablets.

The term “Mobile Web” (although often criticized1) is commonly used to describe accessing the internet using a mobile device. This definition is broad enough to cover everything from using a browser on a feature phone, to using highly customized apps on smartphones or tablets. “There’s an app for that” has made device-specific applications the rage of the day, with some companies starting off backwards with “we need an iPhone app” instead of first understanding what their users actually need when they are mobile, the devices that they use, and then deciding the best approach for going mobile, which may not be an app, but could be a mobile website instead. Mobile websites are universally accessible, less expensive to develop and maintain, and can be searched and accessed by most mobile phones.

(The term “Mobile Web” is criticized because it implies that there are “different” Webs which just isn’t true — there is no Desktop Web, for example. It makes more sense to speak of the websites optimized for users accessing those websites through mobile devices. We will be using this perspective in this article. — Smashing Editorial Team)

This article focuses on designing the user experience for mobile websites accessed from mobile phones with small screens, though the process can be applied to building apps as well. As a Web designer, the good news is that the process is similar to designing desktop websites — with some additional mobile-only considerations that go hand-in-hand with small screens, device features and constraints, and connectivity issues. The user-centered mobile design life cycle can be thought of as an ongoing process as shown below:

User-Centered Mobile Design Lifecycle
The ongoing user-centered mobile design life cycle

Let’s discuss each phase of this life cycle in more detail.

1. Assess Current Situation: Do You Really Need A Mobile Website Now?

Silly as this may sound in an article about creating mobile website user experiences, it is important to first figure out whether you actually need a mobile website. True, there will be 91.4 million mobile internet users in the US by the end of this year, but how many of them are in your target audience? Mobile commerce sales in the US in 2010 were $3.4 billion, but if you are not selling anything online, does that matter to you? The more relevant statistic is how many of your users are accessing your website using mobile devices. A quick way to find out is of course by looking at your existing desktop website analytics to identify the percentage of mobile visitors, along with the types of devices and operating systems they use to access your full desktop site.Dig deeper to understand why these users visit your site using a mobile device — what they are trying to do, and the content and functionality they are using.

Now, think about what else would be relevant to these mobile users, and for some competitive insight (and possibly inspiration), take a look at what similar sites are doing with their mobile presence. Your desktop site was created to support some business goals — it may have been a simple goal of creating awareness or a more complex goal of generating revenue through online sales. How will a mobile website complement that existing website? Identify the content and functionality that will be useful for your mobile users while supporting your business goals, including any new goals for mobile. Save these “business requirements” — we’ll need them when deciding what goes on the mobile website.

If, at the end of this exercise, you realize that you have very few mobile users, and they occasionally use just a couple of features (like finding your phone number, or hours of operation), you may be better off for now just optimizing your desktop site to make that information easily accessible by mobile users instead of building and maintaining a separate mobile site. If your website happens to be running on WordPress, there are plugins that can easily mobile-enable that website with little effort.

Not all websites need to go mobile now. Companies that need to extend their core services to their users (like those in travel and banking) certainly do, but a manufacturer of commercial jetliners and military aircraft or a provider of specialized industrial gases would probably not need a separate mobile website now, though that may change in a few years. But if you realize that you need a mobile website, let’s focus on the reason you need it: your users!

2. User-Centered Mobile Design Starts With The User

User-centered design relies on user involvement throughout the design process, leading to a solution that users will find useful and want to use. To achieve that, you first need to have a clear understanding of your users, grouped into a prioritized set of user groups whose needs can be thought of individually. For a pharmaceutical company, those groups could be patients, healthcare professionals and caregivers, with the first two groups being the primary user groups, and caregivers being a secondary user group with very similar needs to patients. Identifying your key user groups and creating personas will help you design better for your main users, the way BBC did when building their future mobile strategy32.

BBC Mobile User Groups
BBC’s mobile user groups (taken from their future mobile strategy32)

To develop a mobile user experience that aligns to the needs and expectations of your targeted users, you must involve representative users and their feedback throughout the process. Direct input from your users through primary research methods like observing users, contextual interviews and focus groups will give you insights about their mobile behavior, including what they want to do on the mobile Web, and when and how they will use it. Primary research will give you answers to questions like:

  • Why do they use your site on a mobile device?
  • What features are they using?
  • What features are crucial for them when mobile?
  • What are some sources of frustration?
  • What devices do they use to access the mobile Web?

As you build a detailed picture of your users and their usage patterns, supplement it with secondary research about industry and mobile market trends from Forrester4, eMarketer5, Nielsen6 and comScore7, comScore Data Mine8, DeviceAtlas9 and Opera’s State of the Mobile Web10. Apart from an understanding of your user and their needs, you will also get a better understanding of the types of mobile devices you have to consider while designing.

3. Prioritize What Your Mobile Website Should Offer

While evaluating the need for a mobile website, you had a list of features you would like to offer on your mobile website. Ideally, these business requirements would align closely with the user requirements identified during user research. If they do not align, look at the requirements asking yourself “what value will this add to the users?” to ensure that your business requirements meet user needs and goals — this is user-centered design after all.

As is often the case, if you end up with more features than you can handle at launch, prioritize what you can initially offer, taking into consideration time, effort, and resources available. Hard as it may be, resist the temptation of trying to build in all the features right from the start. As 37signals so eloquently put it: “Build half a product, not a half-ass product11.”

4. Mobile Design Considerations

Now that the groundwork has been completed, it’s time to get to the fun part: actual design! The basic design steps and principles of desktop website design apply to mobile design, with the addition of a few important mobile design considerations. Mobile devices are personal devices with small screens, always turned on, have intermittent slow connections and are mostly used when the user is — you guessed it — mobile.

This brings us to the big “C” of mobile: Context. Mobile users are not captive like computer users are. A user using your desktop website is sitting comfortably, and in a worst case scenario, may be simultaneously listening to music and intermittently tweeting. They are however, not doing all that with one hand, while walking around. Picture a mobile user trying to find directions using a tiny phone with intermittent connectivity, while strap hanging and swaying in a subway train with sub-optimal lighting conditions, deafened by the screeching of wheels on tracks — that gives you some context of use. Simply put, context is about the environment and conditions of usage, including distractions, multitasking, motion, lighting conditions and poor connectivity as you can see in the video below:

Designing for Mobiles: Users & Context12 from Niek Dekker13 on Vimeo14.

In Tapworthy – Designing Great iPhone Apps, author Josh Clark boils down the mobile user’s mindset to one of three possibilities:

  • Microtasking: Using the phone for short bursts of activity.
  • Local : Finding out what’s around the user.
  • Bored : Using the phone for distraction/entertainment.

Keeping all these factors in mind, here are some specific mobile design considerations to pay attention to while designing for the mobile Web:

Design for Smaller Screen Sizes

From designer's screens to smaller mobile screens
From a designer’s big screen to smaller laptop and mobile screens

The most visible difference between a mobile device and a desktop is the screen size. For years, we have been increasing the minimum screen resolution we design for (remember the days of “optimized for 640 x 480″?). Mobile phone screen sizes have also been increasing, but even the gorgeous screen of the iPhone 4 is still small in comparison to a standard 1024×768 desktop design (designed by someone using a 2560×1440 display). This gets more complicated when you factor in the range of screen sizes used by your mobile users. And let’s not forget that some smartphones can change orientation and their users’ expect the website to resize accordingly. Even though many smartphone browsers today can miniaturize desktop websites, they inadvertently break the user experience by making users zoom in and out, which brings us to the traditional approach of creating a separate website for mobile devices.

Bryan Rieger addresses the issue of designing for multiple screen sizes15 with a 4-step process:

  • Define device groups by grouping screens with similar widths together resulting in a manageable number of groups,
  • Create a default reference design that will adapt to smaller and larger screens,
  • Define rules for content and design adaptation for it to display well and
  • Opt for Web standards and a flexible layout.

While you should ideally be designing for mobile devices used by your users, for a more generic list of browsers to support, follow Peter-Paul Koch’s recommendations of supporting Safari iPhone, Opera Mini, Android WebKit, BlackBerry (WebKit & older for US), Nokia WebKit (Europe).

The other approach advocates a single website that caters to all devices, mobile or not, based on Luke W’s Mobile First16 principle (see presentation17). Mobile First starts with a design for mobile, which can then be progressively enhanced18 for desktop websites. To see it in action, take a look at Yiibu’s
proof of concept site
19 based on Mobile First.

Selecting your design approach is not a black and white option. Think about which will work better for your situation. Irrespective of the approach you select, there still are other considerations that go into building a mobile Web.

Simplify Navigation

Without a mouse to point and click, mobile users have to rely on tiny keypads, trackballs and touch to navigate mobile websites. Add in the small screen with the need to complete tasks quickly and efficiently, and clear and intuitive navigation becomes crucial:

  • A common approach that works for the start pages of most sites is a list of links to main features and content, prioritized based on user needs. These often end up being presented vertically instead of the horizontal model used on desktop websites.
  • Reduce the number of categories and levels of navigation, and rearrange based on priority, presenting the most important categories first.
  • Use clear, concise and consistent labels for navigation across the site.
  • Provide access key shortcuts for feature phones, so users can enter a keypad number (0-9) to quickly access a link (AA and CNN examples below).
  • When designing for touch, make sure the tap size (width or height) for the navigation item is at least 30 pixels.
  • Make links obvious, and provide clear and immediate visual feedback to show the selected link.
  • When displaying the main navigation links on internal pages, put them at the bottom instead of the top, to avoid users having to tab through all of them to get to the main content on the screen (CNN example below). If not displaying all the links, Southwest’s approach of listing key links (Home, Air Reservations and Flight Check In) on secondary screens works well.
  • At the bottom of the mobile homepage, offer a link to the full site so users can switch over to the desktop site, and vice versa.
  • Breadcrumbs are not usually not used on mobile sites since navigation is not usually so deep that users need a trail back.

American Airlines, CNN, and Southwest simplify mobile navigation
American Airlines, CNN, and Southwest simplify mobile navigation

Prioritize Content

Be succinct. Smaller screen sizes require even more careful attention to the content displayed to the user. Put on your editor’s hat and cut unnecessary content, then cut some more. When you’re done, prioritize the content and display the most important content first.

Amazon desktop Vs mobile site
Amazon’s mobile site prioritizes what it offers users on the homepage

Minimize User Input

Tiny user input mechanism on Casio watches
Having used tiny numeric keypads and touchscreens on these Casio DataBank watches for over 20 years (yes, I admit it), I know the pain involved with entering data on miniscule screens. Feature phones have tedious numeric keypads for input, while smartphones have tiny keyboards, either real or virtual, which are subject to fat-finger errors.

  • Keep your URL as short as possible, keeping in mind, feature phone users have to repeatedly press a key for most alphabets (key presses for “com” are 222-666-6). Follow URL naming conventions that users are used to, like m.site.com or mobile.site.com.
  • Use alternate input mechanisms where possible. While apps can use device capabilities for input including motion, camera, gyroscope, and voice, mobile websites are slowly starting to use some of these features, like geolocation.
  • Limit input to essential fields. For instance, if registration is required, limit it to the minimum required fields, and use shorter alternatives like a zip code instead of city and state. Volkswagon mobile captures geolocation, but does not use it when trying to schedule a test drive. Not only that, the mobile form is longer and more tedious than the desktop one.
  • Select the best mobile input option (e.g. allowing users to select from a list of options is often faster than typing).
  • Use smart default values. NJ Transit’s mobile website remembers your last selections and defaults the date to today’s date.
  • When users need to log in, offer the option to stay signed in, especially since mobile devices are personal and not usually shared.

Alternate inputs and smart defaults
NJ Transit uses geolocation, remembers selections and defaults to today’s date

VolksWagon mobile site captures location, yet does not use it
VW asks for location, but fails to use it (the mobile form is also longer than the desktop version). See larger image20

Design for Intermittent Connectivity

Even with mobile service providers rolling out faster G-speeds, mobile connectivity remains intermittent and does not even approach broadband speeds we are so used to on our wired and wireless connections (not even Justin Bieber’s 6G phone21!). Users pay for internet access on their phones, and not everyone has unlimited data plans, so as mobile designers, we should think small when designing for mobile:

  • Keep page sizes small so they can load quickly and are within the memory limitations of most phones.
  • Remove unnecessary code, comments and optional tags.
  • Reduce images to sizes and resolutions appropriate for mobile devices.
  • Minimize the number of embedded images to reduce the number of HTTP requests and to speed up page load time.

Offer Cross-Channel Consistency & Integration

When you create a mobile website, you cross over into multi-channel territory, and with it, the need to maintain a consistent and integrated user experience across channels.

  • Balance form and function. Continental Airlines22 takes a minimalistic, no-frills approach, using just their logo for visual branding, while Southwest23 makes their mobile website a little more visual with color and icons.
  • Maintain continuity. By signing in on the Amazon mobile website, users can view and manage their shopping cart, wishlists and view and track orders, just as they would on the full site. Another good example in the making is Kindle for the web24 which, when launched, would allow you to continue reading a Kindle ebook where you left off, irrespective of the device you last used. It would also synchronize your library, bookmarks, notes, and highlights.
  • Extend the user experience. Sephora mobile users can look up user reviews and ratings of products (by UPC or name) when trying to decide between two or more products in-store.
  • Build a consistent user experience. Citibank users going from the full site, to the smartphone website or an iPhone app have the same user experience across all these channels (though some feature phone users cannot use the site at all).

Cross channel examples of balance and extension
Balancing form and function; Sephora extends the experience for the mobile context

Other Considerations

  • Detect if your users are using a mobile browser and direct them to the mobile website25 (with a link on that screen to switch to the full site).
  • Do not rely on technology that is not universally supported by your audience devices like Java, JavaScript, cookies, Flash, frames, pop-ups and auto refreshes.
  • If you must make the user scroll, make them scroll in only one direction (most sites scroll vertically).
  • Use short, descriptive titles for your pages for easy bookmarking and recall.
  • While there are advocates for creating separate mobile sites for feature phones, smartphones and iphones (yes, their own website), others have gone down this road and are opting for a single mobile site. Facebook, one of the most visited mobile properties, recently decided to unify its mobile websites into one interface26.

5. Prototype Review & Refine

Prototype Review and Refine
The rapid prototyping process (from Design Better And Faster With Rapid Prototyping27)

Prototyping is important in an iterative user-centered design process, allowing designers to quickly visualize parts of the website, review with users and refine the design. Prototype early and often through the design process, starting with low fidelity paper sketches, refining them into medium fidelity wireframes and subsequently into high fidelity designs, continually testing with users and iterating based on their feedback.

Double check your code for compliance by validating your mobile site using the W3C mobileOK Checker28 or mobiReady29 to uncover and fix potential issues your users may face. Mobile emulators30 and simulators are useful during development, but nothing beats testing your site on actual devices that your users are using.

Ongoing Improvements

Your job is not done when you launch your mobile site — you’ve just come full circle. It’s time to monitor site usage and user feedback to identify changes and requests for new features, in addition to any features that did not make it in the first release. Periodically evaluate your mobile site against competitors using a scorecard (sample from Yankee Group [pdf31]) to identify potential areas for improvement.

In Conclusion

The mobile Web is different, and may be daunting, but the design process is similar enough for Web designers to ease into mobile design. Designing the perfect mobile website is an impossible task even for experts, but using an iterative user-centered design process can help create the best experience for our users with their help.

Related Articles

Resources

Tools

Books

  • Designing the Mobile User Experience by Barbara Ballard
  • Mobile Web Design by Cameron Moll
  • Strategic Mobile Design: Creating Engaging Experiences by Joseph Cartman and Richard Ting
  • Mobile Design and Development: Practical Concepts and Techniques for Creating Mobile Sites and Web Apps by Brian Fling

(ilj)

Footnotes

  1. 1 http://www.the-haystack.com/2011/01/07/there-is-no-mobile-web/
  2. 2 http://www.bbc.co.uk/blogs/bbcinternet/2010/02/bbc_online_our_mobile_future.html
  3. 3 http://www.bbc.co.uk/blogs/bbcinternet/2010/02/bbc_online_our_mobile_future.html
  4. 4 http://www.forrester.com
  5. 5 http://www.emarketer.com/blog/index.php/category/mobile/
  6. 6 http://blog.nielsen.com/nielsenwire/category/online_mobile
  7. 7 http://www.comscore.com/Press_Events/
  8. 8 http://www.comscoredatamine.com/category/mobile/
  9. 9 http://deviceatlas.com/explorer
  10. 10 http://www.opera.com/smw/
  11. 11 http://gettingreal.37signals.com/ch05_Half_Not_Half_Assed.php
  12. 12 http://vimeo.com/2447785
  13. 13 http://vimeo.com/niekdekker
  14. 14 http://vimeo.com
  15. 15 http://mobiforge.com/designing/story/effective-design-multiple-screen-sizes
  16. 16 http://www.lukew.com/ff/entry.asp?933
  17. 17 http://www.lukew.com/presos/preso.asp?26
  18. 18 http://dev.opera.com/articles/view/graceful-degradation-progressive-enhance/
  19. 19 http://yiibu.com/about/site/
  20. 20 http://www.smashingmagazine.com/wp-content/uploads/2011/04/vwbig.jpg
  21. 21 http://www.youtube.com/watch?v=pS9sUm5Y0sg
  22. 22 http://pda.continental.com
  23. 23 http://mobile.southwest.com
  24. 24 http://www.amazon.com/gp/feature.html?ie=UTF8&docId=1000579091
  25. 25 http://mobiforge.com/designing/story/a-very-modern-mobile-switching-algorithm-part-ii
  26. 26 http://mashable.com/2011/03/31/facebook-launches-mobile-website-for-all-phones/
  27. 27 http://www.smashingmagazine.com/2010/06/16/design-better-faster-with-rapid-prototyping/
  28. 28 http://validator.w3.org/mobile/
  29. 29 http://ready.mobi/
  30. 30 http://www.mobilexweb.com/emulators
  31. 31 http://www.keynote.com/docs/news/Yankee_and_Keynote.pdf
  32. 32 http://www.smashingmagazine.com/2010/11/03/how-to-build-a-mobile-website/
  33. 33 http://www.smashingmagazine.com/2010/12/02/a-study-of-trends-in-mobile-design/
  34. 34 http://www.smashingmagazine.com/2010/07/19/how-to-use-css3-media-queries-to-create-a-mobile-version-of-your-website/
  35. 35 http://keynote.com/benchmark/mobile_wireless/article_the_mobile_dilemma.shtml
  36. 36 http://yiibu.com/articles/rethinking-the-mobile-web/
  37. 37 http://gs.statcounter.com/
  38. 38 http://www.quirksmode.org/mobile/mobilemarket.html
  39. 39 http://www.quirksmode.org/blog/archives/2010/04/mobile_browsers.html
  40. 40 http://blog.nielsen.com/nielsenwire/category/online_mobile/
  41. 41 http://www.netbiscuits.com/external_content/marketing/Netbiscuits_Mobile%20Web%20Metrics%20Report_11-1_Feb.pdf
  42. 42 http://techland.time.com/2010/08/25/times-50-best-websites-the-mobile-edition/
  43. 43 http://www.w3.org/TR/mobile-bp/
  44. 44 http://www.comscore.com/Press_Events/Presentations_Whitepapers/2011/2010_Mobile_Year_in_Review
  45. 45 http://www.forum.nokia.com/Develop/Web/Mobile_web_browsing/Web_templates/
  46. 46 http://mashable.com/2010/12/16/create-mobile-site-tools/
  47. 47 http://html5boilerplate.com/mobile

↑ Back to topShare on Twitter

Lyndon Cerejo is a certified user experience & usability strategist at Capgemini with a successful track record with clients including Allstate, American Express, Coca-Cola, General Motors, Merrill Lynch, and Walmart. His key areas of expertise are user experience analysis, information architecture and rapid prototyping usability testing, online strategy & marketing. He is the co-author of marketing.com - a book about marketing adaptations on the Internet.

Advertising
  1. 1

    I’m using Joomla with K2 and feel that it’s quite difficult to customize a Joomla site for Mobile Devices.

    It would be better if I know how to customize K2 component that for such mobile devices as iPad or iPhone^^

    0
  2. 2

    Great post.
    Thanks for sharing.

    0
  3. 3

    Stephanie True Moss

    May 2, 2011 6:22 am

    Great article about mobile and considering the needs of the increasing numbers of mobile users. It is important to make sure that items added to the mobile version are also optimized for mobile. An example in this very post is the video above which is NOT mobile accessible – at least for iPhones!

    0
  4. 5

    Thanks for writing this… was perfect first read of the day.

    0
  5. 6

    A website I’m currently working will be launching with both the desktop and web version of the website at the same time. My idea is to offer a button not only to swap between the full and web version of the website, but also to go to the same page on the full and web version. I can’t believe the amount of times I’ve been on a website (such as Facebook) on my mobile, but a feature has been missing, so I have to then gone onto the full site, then find the same page again. I haven’t seen any websites offer a quick page change like this though, is it because it just doesn’t work very well and people don’t want it, or people have never needed it.

    0
    • 7

      Lyndon Cerejo

      May 2, 2011 7:10 pm

      Tyler, you’re right – few websites switch to the corresponding page, and not consistently. If you are on a product page on the amazon mobile site, and click on the “full site” link at the bottom of that mobile page, it takes you to the corresponding product page on the full site. But if you are on a category page, it takes you to the amazon homepage.
      In a user-centered approach, you should be able to glean the type of switching behavior your users expect and build it accordingly.

      0
      • 8

        This is a practice that happens a lot with language versions as well: once changing to another language on an inner page, most of the times you will be taken back to the homepage in the other language. This is pretty frustrating. Although it requires more programming work, technically it is possible so project managers/developers should consider this in their briefs.

        0
  6. 9

    Joram Oudenaarde

    May 2, 2011 7:24 am

    What I don’t understand:
    Why not just design a full-sized website? For smartphone-like devices (Android phones, iPhones, iPads, Windows7 Phones and such) the browser was made to view full-sized websites. Hence the reason they implemented touch-scrolling in all directions and the ability to “smart” zoom to div’s.

    Personally for me, that’s the beauty of using mobile browsers: I don’t have to see or make concessions when I’m using a mobile browser compared to using a normal browser. I can still see the same website in all it’s glory. Mobile internet nowadays is fast enough (not ás fast as ADSL/Cable, but fast enough) to view those normal websites, so why not use that to your/our needs?

    Also, shouldn’t it be the viewer’s choice to choose between a mobile view and a normal view of the visited website? :)

    0
    • 10

      Nathanael Boehm

      May 2, 2011 6:31 pm

      Yes, you should have the choice of the ‘standard’ website instead of being forced to use the ‘mobile’ version if you’re on an iPhone and are in the situation where you need features not offered by the mobile version, or feel more comfortable using the ‘standard’ website if there’s little continuity of experience between the two versions.

      The thing is that the mobile optimised version should have been tailored to the contexts and goals of people using their mobile device to access a website … just as the main website is tailored to the contexts and goals of people using a desktop computer.

      Instead of ‘mobile’ I prefer to use the term ‘on the go’ and design for people who are out and about. For example whilst seated at a desktop you might be doing some in-depth product research and comparisons and then decide to head out to a store to buy that product … what sort of information are you likely to need about that store while on the go, using a mobile device? Location? Perhaps a map? Business hours? Phone number?

      That’s just one scenario and it’s entirely possible that someone might be expecting to use their mobile device for the more intensive tasks hence you offer the switching option for those edge cases.

      If the mobile site is merely a cut-down version of interface and functionality that’s been decided by the business or designer without understanding contexts of use and user goals then it’s likely to disappoint.

      0
      • 11

        Lyndon Cerejo

        May 2, 2011 7:30 pm

        Nathanael – well put!

        Joram – At the end of Step 1 (assessment) and Step 2 (understanding your users), you may realize that you don’t need a separate mobile website for your users. Or you may find out that your users are looking to quickly get to something on your website and pinching in and out gets in the way. Focusing on your specific users will also give you an idea of how many of them use feature phones (vs. smartphones) where browsing a full site is painful.
        It is a good practice to give users a link to the other version (offer a link to full site on the mobile site, and link to mobile site on the full site)

        0
        • 12

          joramoudenaarde

          May 2, 2011 9:50 pm

          @Nathanael and Lyndon;
          Good points, and thank you for the response :)

          I do understand that not all websites need mobile/”on the go” versions, but it happens quite a lot that a website decides fór me that I need to see a mobile version. Usually that ends up being a slimmed down version where I can’t see the original design and/or content the way I usually do… making the experience a lot less like that website was “supposed to be”.

          I believe http://www.tuaw.com has or had that function. There were slim to none of the design elements left that “made Tuaw Tuaw. But to a lesser degree, also websites that show a different layout like http://hicksdesign.co.uk/ does it (although to a far lesser degree). The layout changes, elements that you know where to find on the normal version dissapear or move from a location where you know it “should be”.

          To me, in some cases I can understand the reasoning for (I believe it’s called) responsive web design, but in most cases it just takes away the experience a lot of people are expecting to see when visiting their favourite websites. I mean, wasn’t the whole reason for developers like Apple and Mozilla to boast about having the “full web experience” with their mobile browsers, to actually see the full website?

          0
        • 14

          I can’t emphasize enough the importance of offering a link to the full site!
          I have stopped reading several daily sites due to autoredirect to mobile (with drastically lowered functionality) that can’t be switched to full site.
          The drive to mobile has rendered these sites frustratingly useless to me, and prior to mobile launch I had no problems with the full sites displaying well on my Android.

          0
          • 15

            The worse thing what happened to me concerning mobile web experience was booking a flight on the go, right at the airport after missing a flight. Glad I had my iPhone with me with 3G and I found a flight with Vueling, leaving within an hour. However, I got automatically redirected to their mobile web version, and it was impossible to pay! I almost got a nervous breakdown: on one hand the hassle with my credit card data which seemed to disappear in cyberspace, on the other hand the flight which was about to close boarding and besides in another terminal. The only solution was changing to the desktop version where the payment went smooth and I finally managed to book – and take! – that flight.

            0
  7. 16

    BlueTrain Mobile

    May 2, 2011 12:34 pm

    Great post! It is becoming more and more evident that mobile web is well on its way to being the most widely used medium for web access. With over 370 million smartphones shipped in Q1 of 2011 alone, companies shift to mobile web is inevitable. A user centered approach to mobile design is a must. Easy, straight-forward and concise content are the primary characteristics and features which need to be inherent throughout your mobile site.

    0
  8. 17

    Hector Jarquin

    May 2, 2011 12:40 pm

    Content could be presented to fit any screen, handhelds, smart phones, tablets, netbooks, notebooks, desktops.

    I’m currently working on Flexible a WordPress Theme that does that. http://madeflexible.com it’s free! and fits content in many screens that support @media, android, iOS, including Facebook iFrame Integration. Please check it out.

    0
  9. 18

    Loved this article, particularly the comments about context – being in a grocery line microtasking certainly changes the types of tasks and attention that one has available (i.e. as opposed to being at your desk.)

    Another point to add, which fits somewhere between your “Review” and “Refine” steps, is simply to leverage A/B testing (in addition to user testing) to test and validate alternate layouts, content and features. This is the sort of thing done by SiteSpect (http://www.sitespect.com — full disclosure, I work there) and focuses on mobile optimization.

    Through an A/B test you can collect data about user behavior that, when analyzed and segmented around mobile device capabilities (i.e. touch screen vs. hard keyboard, screen size, OS, carrier data speeds, etc.) the UX team can learn alot about what’s really working out “in the wild”.

    Eric

    0
  10. 19

    I believe this is the way to go. Much enjoyed this article.

    0
  11. 20

    Good post, specifically about the finding whether you need a mobile site or not.

    0
  12. 21

    Great article. I especially like the point around prioritizing content. So important for mobile developers not to cram all web features into the mobile experience. I wrote on this topic ‘A secret to success for mobile apps’. http://www.nextwala.com/nextwala/2010/01/the-secret-to-success-for-your-mobile-application.html

    0
  13. 22

    Thanks for the resources! There is always a dilemma about what to display and what not display on a mobile site. The User-Experience is always at the center of our preoccupations.

    0
  14. 23

    I find it slightly ironic that I read this on my phone. I generally do all my day to day website reading on the way to and from work on the bus and that means I don’t have to waste time at home reading all the new posts from blogs I follow. This is reason enough for me to not to drive to work.

    0
  15. 24

    it’s a really interesting article as the merging of two different media is not just only a case of replicating the website on a smaller scale. There is a lot more to take in consideration when developing a mobile version of the site (interaction , size , speed , device os etc etc) Right now what i’m developing is a jquerymobile platform feeding from different feeds generated from Drupal. It’s super easy , i suggest you to check the jquery mobile project.

    0
  16. 25

    Patrick H. Lauke

    May 4, 2011 3:00 am

    “Mobile users are not captive like computer users are. A user using your desktop website is sitting comfortably, and in a worst case scenario, may be simultaneously listening to music and intermittently tweeting. They are however, not doing all that with one hand, while walking around”

    or, they may be sitting comfortably on their couch at home, and – while watching TV or just relaxing – are doing some browsing on their smartphone or tablet device. “mobile” device does not immediately equal “somebody at the bus stop, walking around town, etc”

    0
  17. 26

    Good article.

    0
  18. 27

    While your article is interesting, there are some basic flaws in your approach. You initially indicate that you should look at the mobile users currently using your website. What if the reason I’m not looking at your website on my mobile device is because it isn’t mobile and the experience is horrible? A better approach is to look at the most popular activities and content on your website. Initially, provide a basic prototype enabling that content and those activities while enabling an option to view the entire site. The site should be basic and fast to set-up. This shouldn’t be a major effort. Then begin to assess the success of your mobile site. How many users are you getting? What are they doing? What aren’t they doing?

    The rest of the article is great. I just think your starting point is flawed.

    0
  19. 28

    Good one!!!!!

    0
  20. 29

    The “mobile Web” has different rules: usually smaller screens, slower connections, clumsy input devices and a whole lot of browsers with their own special problems (and you thought IE6 was bad? try Teleca Up, any older Obigo Browser or waste your time trying to style forms in Netfront Access).

    However, the different standards supported by these very different browsers have many things in common. Some may lack CSS or JS support, some only know a subset of HTML and WML whereas others boast with their ability to understand all modern standards.

    If you want to support the mobile Web, you have to concentrate on the basics, think in linear processes (top-down, because you haven’t got too much horizontal space), leave out big visuals, complex effects, flash and so on. I usually write semantic HTML4/5 with hidden hr-nodes to distinguish different sections, because this is also supported in WAP/WML, yet without CSS you get a ruler to separate your sections. Any phone without HTML-Support will still display a working page.

    Though I wrote a literally tiny JS toolkit (http://tinyjs.sf.net), I avoid to use more than few parts of it in my mobile pages. Working without a toolkit and optimizing for size rather than speed is a core feature.

    If you want to do your job really well, most of your time will be dedicated to testing. Use simulators, emulators or products like device anywhere – or even real phones.

    Greetings, Alex

    0
  21. 30

    John Constantinescu

    May 9, 2011 2:05 pm

    Great post. Mobile is clearly the future of browsing.

    ————————————————
    questdome.com

    0
  22. 31

    great post! Thank you for sharing this.

    0
  23. 32

    Gidday there Lyndon….Thanks for a great introduction to websites for mobile devices. I am beginning to see the use of the concepts you mention. It makes so much more sense to use websites designed for mobile users. A way to play multiple video formats has been a big problem for me to consider.

    I am waiting for somebody to introduce VLC Player for mobiles or similarly a way to play back multiple formats. I am still to find an in-depth explanation on how to code up so mobile browsers can view a video on my blog.

    With QR codes coming onto the scene it’s beginning to make even more sense to use these mini websites. You have already given me food for thought on how to go straight to a search bar from a QR code.

    Thanks for sharing

    0
  24. 33

    I am the project lead for “California Mobile”, an effort to expand government resources for the state of california onto mobile devices. Please check out Ca.Gov from your favorite smartphone!

    0
  25. 34

    Brisbane Osteo

    July 7, 2011 3:17 pm

    Awesome post, so glad I found it! Thanks for sharing!!

    0
  26. 35

    PlasticCardChick

    August 31, 2011 5:47 pm

    I didn’t even realise there was so much to consider for mobile users! such an awesome post.

    0
  27. 36

    firstly thanks for sharing this stuffs………its great.. hope get more updates on my mail box…

    0
  28. 37

    Excellent Post!
    It has helped me to finalize my decision of building the browser base version vs. native app of our newly developed website.

    One area that I would like to be address is security and compliance. Is there a benefit of building browser base vs. native app, if your site has to have corporate security standards.

    Thanks/

    0
  29. 38

    Great article! As a requirements analyst, I found this article helpful in terms of developing a system that works across multiple devices. Check it out! http://requirements.seilevel.com/blog/2012/04/tips-for-it-product-managers-the-case-for-system-agnostic-requirements.html

    0
  30. 39

    Brilliant article. Thank you

    0

↑ Back to top