10 steps to making a website tablet friendly

10 minutes read

It’s clear that whilst some people might have struggled to see the point of tablets when they were initially trumpeted, they are very much here to stay. More and more people are preferring to go online with their tablet, rather than their trusty computer so it’s becoming essential that websites are tablet friendly. Follow these 10 steps and you too can make your website wonderfully tablet friendly.

1. Determine the tablets to focus on

There are an increasing number of different tablet makes and models out there, from iPads to Samsung Galaxy tabs, Kindle Fires and even emerging phablets (basically large mobiles). It’s not feasible to test your website on every tablet so you need to determine the tablets that you will be focusing on. This should be determined by your website analytics. Any analytics package worth its salt (such as Google Analytics) will tell you which devices are accessing your website. Focus your efforts on the tablets that make up the bulk of your tablet traffic so that you can optimise the site for the greatest number of tablet users. Don’t worry too much about anything with less than 10% of the mobile site traffic (analytics packages will show tablet as part of mobile traffic), but do periodically check the stats as things can change surprisingly quickly in the mobile and tablet world.

If you don’t have an analytics package installed (if so, why not?) then it’s generally safest to focus on iPads first and foremost and then Android based tablets such as Samsung Galaxy tabs. It’s also a good idea to include a mini-tablet (i.e. around the 7 inch screen size mark) in your set of test devices as the smaller screen can cause additional user experience issues (over a larger tablet) that might need to be addressed.

2. Identify common tablet user journeys and page views

Having determined the tablets to focus on you should then identify the most common tablet user journeys on the site, and the most popular pages for tablet users. Once again your analytics package should be able to give you this information. This will give you an insight into how tablet users are using the site, and if this usage differs in some way from desktop and other mobile users (always a sign of something interesting afoot).  It will also help you to determine the sort of tasks that you should be reviewing and usability testing the site against on a tablet (more of this later). It’s also a good idea to look out for any exit rates (when a visitor exits the site from a page) that are greater on a tablet than other traffic. This might be an indication that there are problems on this page for tablet users that are causing them to quit.

3. Gather any tablet related site feedback

You’ll often be surprised at how much feedback might already have been captured from people trying to use the site on a tablet. This might be in the form of comments received via an onsite survey, from market research undertaken within the company and even from feedback captured by customer service representatives. It’s a good idea to have a quick mine for this information, to see what you can find and what might be worth adding to the mix.

4. Review the site on a range of tablets

Now that you (hopefully) know which tablets people are using to access the site and what they are doing when they’re on the site (or at least trying to do) a next step is to carry out a review of the site on these tablets and against these tasks. For example, a common journey might be to carry out a product search on the site, so you should be including this task in your review.

It’s a good idea to ask a number of people to review the site, each on a different tablet. For example, the first person might review the site on an iPad, the second on an Android tablet and the third on an iPad mini. This will ensure that you’ve covered a number of different devices and that a number of eyes have been over the site.

When reviewing the site look for anything that might cause usability problems for tablet users, such as small tap targets, small text and unclear hyperlinks etc. Having completed the reviews (which should take a while) pool all the findings together and collectively go through as a group (assuming you have multiple reviewers) to consolidate findings and remove any duplicates. For more about carrying out site reviews take a look at my guide to carrying out usability reviews.

5. Carry out tablet usability testing

Site reviews are great but they always involve a lot of guess work because you’re trying to second guess what will cause users difficulties. Usability testing eliminates this guess work because you are testing the site with actual users against actual tasks and can see the problems with your own eyes (unless they are unmoderated tests, but more of that later). Of course you don’t have to run any tablet usability testing to make a website tablet friendly but I would strongly recommend that you do. Usability testing will give you much more concrete evidence of tablet usability issues to resolve and will help to answer questions that you might have, such as “why are a lot of tablet users exiting the site at this point?”.

Usability testing sessions can either be moderated (a facilitator is running the session) or unmoderated (a participant follows onscreen instructions). They can also be run face-to-face or remotely. If possible I would always go for moderated testing over unmoderated, and face-to-face over remote. Whilst it’s possible to use tools such as UserZoom to carry out remote unmoderated testing on a tablet and something like join.me to carry out remote moderated tablet testing I find that you get a lot more feedback when running sessions face-to-face.

Between 8 – 10 usability testing sessions is generally a good number to run, although it will depend on the site and the number of different user types you want to test (more user types should equal more sessions). You should also test against the tablets you are focusing on. For example, you might test with 4 iPad users, 2 mini-iPad users and 4 Android tablet users.

For tablet usability testing sessions it’s important to recruit people that would actually use your site and that are experienced tablet users. After all, you don’t want false tablet usability issues to arise because this is the first time someone has used a tablet. It’s also a good idea to ask participants to use a tablet that they are familiar with (or even bring their own) as there can be significant differences between say an iPad and an Android tablet. Focus on key tasks and try to keep them as naturalistic as possible. For example, if you’re testing a travel website you might ask a participant to get a price for a trip that they are planning. You might even specifically recruit participants that are planning an upcoming trip or holiday. Also try to carry out the testing in a natural environment. People don’t generally use a tablet at a desk so don’t do desk bound usability testing. Perhaps carry out the testing on a sofa, in the nearest café, or even in the pub!

Ideally you should be recording sessions so that you can go back and review stuff. Of course recording each session isn’t essential but can be really helpful for reviewing the various tablet interactions. In the past I’ve simply set-up a digital camera on a tripod (i.e. behind the participant) to record interactions with the tablet. An alternative is to use something like UX Recorder to capture directly from the tablet screen (although this is iPad only and can slow the tablet down somewhat). Another option is to stream the output from the tablet to a computer (using somethink like Reflector or AirServer) and record this on the computer.

For more about tablet usability testing take a look at UX Magazine’s  Eight Lessons in Mobile Usability Testing and also check out my more general Usability testing hints, tips and guidelines.

6. Prioritise tablet usability issues

So, you’ve carried out a review of the site on a range of tablets (you did review on more than one tablet didn’t you?) and hopefully also carried out some tablet usability testing. Together with any tablet related site feedback you’ve collected you should now have a long list of usability issues that need addressing. You will want to prioritise this list so that you can work out which issues to start work on first and where you’ll get the biggest bang for your buck.

A good way to prioritise the list is to collectively plot each issue against it’s severity (i.e. how much it impacts the tablet user experience) and the cost to fix. Get everyone that was involved in the site reviews and usability testing together, along with some technical boffins that hopefully know a thing or two about developing websites for tablets (and probably mobile). Draw a large cross on a white board or large piece of paper with severity on the vertical y axis and cost to fix on the horizontal x axis (see image below). Write each issue down on a post-it note and plot it on the graph. Of course at this stage you might not know how costly it will be to fix something but you should be able to take a pretty good guess, especially with your technical boffins there to advise. Once all the issues have been plotted you can get a view of which the most pressing are (i.e. high severity and low to medium cost) and if there are any quick fixes (i.e. low severity but also low cost). You can also make a call on any issues that are high severity and a high cost to fix. Are these true show stopper or can they wait a little while?

Sometimes it’s useful to do this exercise a little bit back to front. You go through your issues and identify possible fixes (see the next step) before then estimating a cost. This certainly makes it easier to plot a cost but if you’ve identified a lot of issues then fleshing out possible fixes for all of them (including low severity issues) can be quite time consuming.

7. Come up with fixes for tablet usability issues

Having prioritised the list of tablet usability issues you now need to come up with ways to fix these issues. Fixes might be something as simple as increasing the size of the text on the site to completely redesigning a page or user journey. It’s a good idea to come up with a number of different ways to fix a particular issue. This allows you to weigh up each possible fix against one another (to find the best one), and also to identify if one particular fix is going be cheaper (i.e. easier) to make than another. Generally it’s best to keep fixes as simple as possible. If you think that something can be fixed by tweaking the design then try that before making a more substantial design change. The worst that can happen is that you identify that the tweak hasn’t worked and requires a bigger change, rather than potentially spending a lot of time and effort on a substantial change that might not be necessary in the first place.

Of course it goes without saying that you should follow good tablet UX design when thinking about possible fixes. There’s not time to cover good tablet UX design guidelines here (another day perhaps) but there are a loads of articles and guides out there that you can use. Two good free resources are the Tablet web design best practices guide from Mobify and the Usability of iPad Apps and Websites report from the Nielsen Norman Group.

8. Evaluate your tablet fixes

Of course you could just make your tablet fixes, put them live and sit back to bask in your own glory. In a perfect world all the fixes would work perfectly (and England would have won the last world cup) but as we know the world is a cruel and far from perfect place (damn you Germany), and there is a pretty good chance that not all the fixes will work as well as you hoped. This is why it’s a good idea to evaluate changes before they go live. Sure you might not need to worry too much about very minor fixes but the more substantial stuff should be evaluated, iterated and perhaps even usability tested.

You will of course want to be evaluating fixes on a tablet which will mean either diving in to the code or creating a tablet prototype using something like Axure or Prot.io. I’m yet to use Prot.io (it’s on my list of tools to try) but have certainly created numerous tablet prototypes using Axure and can thoroughly recommend it as a prototyping tool. The evaluation might be just a case of reviewing the fixes with the development team, all the way to running another round of usability testing. It all really depends on how big and important the fixes are. Iterate the fixes until you’ve got something that really works and don’t be afraid to hold something back if you don’t think that it will make the site any more tablet friendly.

9. Release the tablet fixes into the wild

As any desert chef will tell you, “The proof of the pudding is in the eating”. This is not only true of a chocolate mousse, but also of a UX design. You don’t know how something will perform until it’s out there in the wild. Release the tablet fixes and see how they perform. What is the effect on the tablet site usage? What about any customer satisfaction scores that you are hopefully capturing?

I’d also advise on a series of smaller bang releases, rather than one spectacular interstellar big bang release. Smaller releases are not only easier to manager but also make it easier to track each fix as it goes live. The risk with putting everything live at the same time is that not only is there more to go wrong, it makes it more difficult to identify which fixes are working, and which have fallen flat on their face.

10. Repeat ad infinitum (to infinity)

Making a website tablet friendly is not a one off activity. You should be continually evaluating the site on a range of tablets; reviewing the break down of tablet visitors; checking the tablet site usage and potentially even running ongoing tablet usability testing. It’s only with ongoing love, care and attention that you can create and maintain a truly tablet friendly website. Mmmm pudding….