The answer is dead simple (though many won’t agree): we can’t!
The experience consists of many things. It’s not just about the design or the screens we use (or their absence, for that matter). It’s also the keyboard, the three buttons on the mouse, our internet connection and many other aspects. We can’t use right click on the mobile, nor can we use GPS on the SmartTV. So for these reasons I say that the same experience cannot be served to each and every one of us.
But still we try. Why? Because it is in our nature: we try to apply known patterns and our previous knowledge to solve new problems.
Long before the rise of smartphones we’ve seen many different devices accessing the web -- tablet PCs, pocket PCs, mobiles and others. It didn’t bother us much because the numbers were small.
But even then people like Jacob Nielsen criticized websites that didn’t respect other devices or screens. HTML was created as a non-device specific language and the bright minds that put the specification together surely couldn’t have anticipated today’s situation better.
How Do We Solve the Problem?
There are two mainstream camps (I bet there are more, but these two stand out). One battles for responsive design -- a way to display the same content to many different devices. The second battles for “forking the web” into multiple content streams, each for a different device.
I don’t want to put more fuel on the fire than I already have, but I believe that they are both wrong -- or at least partially wrong.
Responsive Design
I’d like to say that responsive design is the answer to all problems, but I just can’t. I see why it’s so great for designers --they develop a pattern and then apply it to dozens of websites. It’s simple and it pays a huge reward. But often there are situations when we need more concise versions of the content or different content for different devices. Responsive design solves neither of these problems.
Forking
Forking also isn’t great, because how can one create 100 versions of a website to make it work on any device? With this approach you also need to choose a “master site” that will serve as a template for the forking. But which one should be the master site? Is it the desktop version? The iPhone version or Samsung Galaxy?
Context Driven Web Experience Wins
If you know something about brands and branding, you surely know that brands -- and web experiences -- consist not just of the logo, but also colors, tastes, smells and feelings. When you walk into a McDonalds you don’t need to see the logo above the front doors. The smell itself identifies the brand to you.
Let’s apply this to web experience. Well I don’t mean the smell, but let’s find what it is we can make common across all devices. It is the “feeling.” Can I have the same feeling with the desktop and mobile site? Sure I can.
Here’s an example from the offline world: I used to have money in one bank where whenever there was a need to write a form, they’d write it for me. So I never had to pick up a pen for anything but to sign a document. That was great, I really loved it.
When I wanted to do something through their online banking, it wasn’t the same, but it felt the same, because the forms were easy, self explanatory and pre-populated with as much information as possible. In other words -- different design, but the same feeling.
One of the reasons I don’t believe in the universal design approach is the difference in the devices used to access the web. It’s not just the hardware that is different. The main difference lies in the context in which I need to access the web.
One URL, Many Reasons
When surfing from a mobile device on the go, users want the action to happen fast. They are looking to finish specific tasks -- comparing online prices while shopping, finding the nearest cafe or checking in.
I can hardly imagine checking into a cafe as my priority while sitting home by my computer. But I still use the same URL, this time to find the opening hours or menu.
We all know that users don’t visit websites for one single purpose. The device which users use to access the web is really a hint for us as to what the purpose of the visit can be.
The Context of the Visit is the Real Thing
When we come to a problem of recognizing this context, suddenly it seems that the devices we use are not that smart (can a website tell if you’re home?). But we can make a best guess and offer the most realistic scenario. Of course we should keep options open, so that if we have made the wrong assumption users can still do their job (as I mentioned in my previous article about hiding mobile content).
Learning Opportunities
Webinar
Mar
29
The CX Commute vs. the CX Joy Ride
Is your CX traffic holding up your customer's journey?
Webinar
Mar
29
Is Your Microsoft 365 Data Recoverable? How to Survive the IT Hotseat When Data is Lost
See why MIcrosoft recommends third party backup
Webinar
Mar
30
An Optimized Customer Contact Strategy Combines Transparency and Intelligence: The State of Outbound Communications
Learn from the Neustar-commissioned Forrester Consulting study on challenges and solutions for contact centers
Webinar
Apr
5
Adopt a Modern Digital-First Marketing Strategy
Learn how to use a composable DXP to your advantage
How Can We Deliver the Feeling?
We shall combine the power of responsive design with forking to address the context, not the device.
Real world example:
Imagine that you are selling your own product through your own website. What are the possible scenarios, or in what context could users visit your website?
- Users searching for a solution -- In this context users are focusing on research, are probably willing to spend a lot of time on your website to get all the information possible (of course, only if you get their attention). So for this context you need to have as much supportive content as possible.
- Users searching for a retailer -- In this case users are focused on a single task: finding the closest retailer as quickly as possible.
- Users searching for support -- Again in this case users are willing to spend a lot of time on the site (or Google), but they want to get it done as quickly as possible.
So how would these scenarios break down into solutions? First of all, I’d use a really simple main menu to break visits into the different contexts. For the first context, I’d say if the visit came from a mobile device, I’d show the shortened basic info and let users dig deeper if they want. If the visit came from a desktop, I’d show the full info right away.
In the second context, if users accessed the site via desktop or tablet, I’d show a map of the country or region and offer a search, but if the visit came from mobile, I’d offer “nearby” as the default option and put everything into a short concise version.
With the third context, for desktop visitors, I would again display a fully featured support form, but for mobile users I’d offer a Twitter or phone number to ask questions directly and leave the support form as optional.
The Bigger Problem
The really big problem of this approach is that there are no backend solutions to deliver content in this way. Today’s content management systems don’t solve this issue.
When there was no responsive design, they offered forking. Now they quickly hop into responsive design, because it’s so dead simple to implement into the existing systems. But I’m sure that a new wave of Web CMS tools is needed to really solve the problem of context driven content publishing.
Bonus question: In which order would you sort the following contact information on the Smart TV, mobile and desktop sites?
- contact form
- phone number
Since typing with the remote control is hard, the only feasible option for me for Smart TV is option three and I wouldn’t show anything else. For mobile it could be 3, 1 and 2. And for the desktop web, I’d choose 2, 1 and 3.
Is any Web CMS prepared to deliver content in this way?
Title image courtesy of lancelee (Shutterstock).
Editor's Note: For a different opinion on responsive design and forking, you may also be interested in reading:
- The Rise of Responsive Design or Why Today's Most Popular Mobile Strategy is Doomed to Failure by @gabesumner
