Let me tell you a story to explain why…

This past weekend I was home alone. With my other half away visiting family I thought it would be a good opportunity to catch up with my backlog of LOVEFiLM discs that have been sitting waiting patiently to be watched for a couple of weeks.

After getting a bit of work done Saturday morning I sat down to watch one of the discs with my lunch on lap, a drink within reach and snacks ready and waiting. I’d popped the disc into my PlayStation 3 and turned the TV and the surround sound on.

Ten minutes into the film it skipped. Not a few seconds forward, but to another scene. Quite a long way ahead of where I’d been watching.

Rewind.

Cross fingers, hope it was a temporary glitch.

No such luck; again it skipped, only this time to even further through the film.

Eject.

Put lunch down.

Walk over to the PlayStation.

Retrieve the disc.

Examine it; scratched. Not just a little mark here or there, but this thing had deep grooves taken out of it. You could have used it as a scale model of the Death Star to demonstrate how the trench run was executed the scratches were that deep.

Dejected I think; that’s fine, I’ll stream the film over the PlayStation LOVEFiLM app instead (I’d ordered the disc before it became available to stream).

I sit back down.

Pick up my lunch.

Open the LOVEFiLM app.

Eat while it loads. Eat some more.

Have a drink.

Watch the loading screen.

Any moment now…

Nope, error. The “Network was slow to respond”. Ok, quit the app. Test the network settings. Something’s really slow.

A quick test with my iPhone proves the WIFI and broadband are working fine. It’s the PlayStation that’s running really, really slow. I try turning it off and back on again (I know, but I was desperate).

PlayStation boots up, I eat some more. It warns me about the dangers of epilepsy, and finally I’m at the home screen.

I open the LOVEFiLM app again.

Sit watch the loading screen some more…

My lunch is almost finished by this point, my drink is finished so I go to the kitchen for a refill.

Come back, still no luck.

Network was too slow again.

In desperation I go to the bedroom to fetch my iPad. Unlock it, open the LOVEFiLM player app on that and bingo! I’m presented almost instantly with a list of movies, documentaries and TV shows to browse and watch at my leisure.

The PlayStation, the TV and the surround sound are all turned off, the last mouthful of my lunch is eaten and I lay back on the sofa iPad in one hand, snacks and drink within reach of the other and watch the film I’d set out to watch 20 + minutes before.

It turns out there were Sony Playstation Network issues over the weekend and that these were causing the problems with connecting to LOVEFiLM via the PS3. On the iPad the only network getting in my way was the plain old Internet, which was working fine.

In the world of on demand TV and movies Apple and their Apple TV will rule our living rooms, not because they’ll do anything fancy or because they will offer anything over and above what Sony et al already promise, but because they understand that on demand means on demand.

Apple will craft an experience around the product and the integrated service that comes with it that will just work. As you’d expect. Every time. I’d be able to sit down with my lunch in front of whatever TV device Apple have up their sleeve and be able to start watching the film I want (via my LOVEFiLM account or iTunes or something similar) before I’ve even taken the first bite.

That is why an Apple TV will dominate our living rooms, and why the likes of Sony will be scratching their heads wondering what went wrong and why Apple are eating their lunch.

Think about that for a second. A device that could tell you how many calories you’ve eaten, how much protein, carbohydrate or fat you’ve consumed, which vitamins and minerals you have enough of or too little of. How many litres of water you have drunk. Automatically.

Imagine that device was connected to your smart phone and could securely share your data with a website that could then crunch the numbers and report back your eating and drinking habits in real time or at regular intervals. Alternatively imagine that this device has a display of it’s own (or could use the display on your smart phone) that could (in real time) prompt you when you’d reached your daily limits or if you need more of a specific nutrient. Imagine you could tailor those nutritional needs to each user, be they weight lifter, long distance runner, rugby player or regular Joe Bloggs who wants to loose weight or gain weight. Whatever your personal needs it could be configured to track, warn or remind you appropriately.

Imagine how such a device could help the predicted tens of thousands of people who are heading for an early grave simply because they eat too much. Or the thousands of people who have medical conditions linked to their diet (diabetics, for example).

Think about how this kind of information would help those of us who are working out and trying to get a bit fitter, given that what you eat is half the battle.

Think about how this kind of device could be used by top athletes and their coaches, nutritionists and training staff.

We’re not that far away from this being a reality.

Applications like Runkeeper use your smartphone to track and report on your activity.

Other devices like the Jawbone Up and the fitbit and the new Nike + FuelBand also track our physical activity and connect via smartphones / computers to apps and websites that report back to us what we’ve done.

Doctors are working on tatoos for diabetics that track blood sugar levels and report their levels back to a wrist watch Tattoo may help diabetics track their blood sugar, making those talk to smart phones can’t be far off.

By taking these technologies one step further and developing a device like the one I’ve imagined would change the world. The pro sports market is huge, the diet / fitness market even bigger. And the global health market probably even bigger still.

And time and time again I have to explain why there is no such thing as “the fold” online and why we should focus our efforts on designing for clarity and readability rather than worrying about how much scrolling a user will need to do.

The fold does not exist*.

The term “above the fold” is a print world term referring to making sure a newspaper’s headline or main front page image is visible when the paper is folded in half on a newsagent’s shelve.

In the world of digital, online publishing and products the term is used to describe the desire to make sure that the most important elements of each screen’s design were visible without the need for a user to scroll down “below the fold”. Which was an admirable aim and design philosophy back in a time when web design was still an emerging discipline.

We as designers had not learnt important principles like how navigation design and information hierarchy helps to orientate users within our content. Users weren’t used to having to scroll to interact with the web, in fact; users weren’t used to interacting with the web at all.

But, those days have past. Today we as designers know how to organise content, how to structure the information on a screen and, even more importantly, users have learnt to scroll.

I have never once sat observing a user during any usability testing and seen them give up the task in hand because they had to scroll a page. They may have not been able to find what they were looking for, or they may have not understood what to do next, but not once have they not known how to scroll.

In fact, one of the first things many of them do if they do get stuck is try to scroll to see if they are missing something, if there is more to see somewhere off screen. Often they will do that before using a site’s navigation menu if the labelling isn’t clear enough, “just checking if there’s a better option somewhere else.”

If you ask these same users whether they like scrolling, they will say no. “I don’t want to scroll to find things”, “I don’t like scrolling pages and pages to find something.” But when you observe them using a site or application scrolling does not hurt their progress as long as the page has been well designed.

What users say when asked abstract questions and how they behave while actually using something are not always the same.

Trying to explain this to a client can be hard. The no scrolling mantra has become universal law in the minds of those who do not design for screens daily. It is one of those mythical rules of web design that many a project manager will wheel out to show they know about the web when appropriate (another favourite, that is thankfully starting to die a death, is; “everything should be no more than 3 clicks away from the homepage” – remember that one?).

Explaining that we cannot control a user’s screen size, orientation or resolution goes some way to helping clients understand that the fold is at best a moving target. Explaining that not everyone browses with their browser window in full screen mode, or that some users have enough browser chrome to take over a third of the available window height also helps, but there is no silver bullet for changing people’s mind on this.

Sometimes I have to give in and reduce the line-height or padding or margin to fit that little bit more content on the screen for the client’s choice of browser / screen size combination.

It is their product and their choice.

I only hope that as more of us use smaller devices like smart phones and tablets to interact with the web and more of our web experience is touch driven making scrolling child’s play, more clients will let go of their believe that the fold exists and that scrolling is the root of all evil in the World.

*Okay, so the fold does exist to some degree. Not everything will always fit on a screen. And if you’re designing a page with minimal content, or designed purely as a hook to draw the user into a more in-depth process / engagement (think landing pages / sign up screens) it is worth trying to make as much of the content “above the fold” as possible on as many screen sizes as possible. But as with anything related to the web, to try and apply that rule universally to all content and use cases will not work. Be sensible and be guided by your content, its purpose, its audience and their needs.

There is no denying that if you are in the business of providing an online product or service you need to be thinking about mobile. Encouragingly, even the big multinational clients I work with have quickly picked up on the trend and are thinking about it.

But how you think about mobile and to what degree you choose to invest in and develop for it is another question, and one that some of those clients are struggling with.

Ignoring gaming, which is a special case and doesn’t need to be considered by most organisations, the majority of online products and services fall into one of two categories: either they are web based applications (allowing users to create or manipulate data), or they are web based information portals (presenting data).

For both types of product there are three popular approaches you can take to supporting a mobile user base:

1. build your web application as a universally accessible web application (using techniques like responsive design and methodologies like designing for mobile first)
2. provide a mobile optimised (usually a cut down, less feature rich) version of your application along side your existing offering, and using clever redirection to filter mobile traffic to the mobile specific version of your application
3. build a native mobile app that compliments your existing offering.

Which of these options you choose needs to be dictated primarily by your user base, their content and functionality needs and their mobile usage.

But here’s the important bit; you don’t have to pick and stick to only one of these options. They are not mutually exclusive. In fact, I’d suggest that options 1 and / or 2 are compulsory, even if you are developing a native application as described in option 3.

Choosing option 1 as a minimum future-proofs your product: If (or rather when) a new device launches next year, as long as it has a browser, you already support it. After launch you can track and evaluate how many of your users adopt the device before rushing to support something natively that none of them end up using.

Even if you provide a native application (option 3), people will still try and access your site via their mobile browser and not supporting those users is a dangerous strategy. As more devices and variations of those devices emerge, supporting and adapting native applications for all possible versions becomes more challenging (and costly), a universally accessible version of your web application is a good baseline for supporting all visitors, whether they choose to visit via a bleeding edge device or not.

This baseline version of your product or service can then be complemented by a targeted mobile optimised version of your web application (option 2), or native apps (option 3) where your user base will benefit most from them. If for example you find that 90% of your mobile traffic is coming from iOS powered devices, and you feel that a native iOS app would enhance the experience for those users then making an iOS native app becomes a logical business investment. If, however, 90% of your mobile traffic is coming from Android users, the same iOS investment is not as desirable and your resources would be best spent on improving the experience for Android users.

When thinking about how to support mobile, instead of thinking about having to choose from one option or another, think about building your mobile strategy around a number of different degrees of support; with browser based access the bare minimum basic level, mobile optimised support as one level up and native applications as the ultimate, highest level of support possible.

Like most creative folk at the beginning of their career, the unsigned musician’s (or band’s) biggest challenge is finding their audience.

The digital revolution has meant that artist have more and more ability to produce, distribute and sell their music without the need for a record company but it can still be hard to find an audience.

As we talked about this challenge I got thinking. While sharing music and video online is helping folk market themselves actually playing a gig in a local bar, pub or club is still one of the best ways of building a following. But what if you could blend the two?

What if as an artist you could upload an album, song, music video or even other promotional material to a website and then during your gig audience members who like a song you’re playing could access that content on their smart phones?

What if Shazam worked for non-signed artists. What if there was an audio equivalent of a QR code that let you link a song to a URL. Your audience could open an audio QR reading app (like shazam) on their phone and it would listen to the track you’re playing and take them to a specific URL. Each song you play could link to a different URL or the same, depending on your marketing goals and preferences.

It could be the download page for that specific track, or related material like the lyrics, writing process, the accompanying music video, or just a simple “rate this track” type page.

Really creative folk could even link to some sort of Augmented reality page that could add to the live music, overlaying animations or other effects onto your live performance if someone holds their phone up to the stage.

The possibilities are endless.

The idea may not completely solve the problem of marketing a new band or artist, but it could make it easier to hold and exploit the attention of people when they’re the most likely to be open to finding out more about you and your music.

What is not so great is that many organisations still seem to be of the opinion that designing their product’s user experience is something that they can do after they have built it. They confuse user experience design with the graphical bit of user interface design and incorrectly assume that both can be added at the end of a project build as the polish on top.

Both assumptions are wrong; user experience design and the graphical component of interface design are not one in the same. And neither should, or can successfully, just be added at the end of a product’s development as the “polish on top”.

The look and feel of a product’s interface plays a big part in the user experience of said product, but it is not the only thing to consider. There is also the product’s information architecture, interaction design, information design and navigation design to think about. The design of each of these elements should be driven by your content requirements and functional specification, which in turn should be guided by your user needs and product objectives. Once your product has been built it is too late to change all of these elements of its design.

You can’t add a great experience to a product that is already built to work in a specific way. A technology driven development process, where design is considered an optional extra to bolt on once you have built something is wrong. To create a great user experience for your customers, you need to be designing your product with them in mind from the start; for web based products that means you need to adopt a user driven approach to your development, designing your product’s interface, process flow and experience before developing the underlaying technology.

Jesse Jame Garrett was spot in his book The Elements of User Experience. To have a great final product with a great user experience you have to have been thinking about delivering that great user experience from day one of your project. You sow the seeds of success when you ask that first set of questions about what do the users of this product want and need? If you can’t tie every decision you make about what your product does and how it does it back to the answers of those simple questions, your user experience will not be a good as it could be, and no amount of polish will change that.

Every week I get at least ten new contacts getting in touch to see if I’m available for work, or to find out more about my skill set. While I’m actively looking for work these calls and emails are welcome, while I’m mid contract or otherwise engaged they are less so. Whether I’m busy or not, keeping track of who the recruiters are, who they’re recruiting for and what type of roles they tend to be involved in filling was starting to become difficult. But keeping track is something I wanted to do so I could keep tabs on which recruiters fell into the good, bad and terrible categories and so I could remember the next time I’m looking for new work who had good opportunities and who didn’t.

Enter Highrise. I now log all calls and emails in a Highrise account and log all interactions between me and each recruiter in one easy to update place. This has let me build up a good picture of which recruiters know what they are talking about, which have good opportunities, which are well organised and which don’t talk to their colleagues.

I have been able, for example, to check when the last time a recruiter has been in touch and what we talked about, whether I have already told them when I’m next due to be available for work or whether I’ve told one of their colleagues. Searching through a timeline of contact in Highrise is a lot easier than trawling through broken email chains and includes notes about phone conversations that I’d otherwise not be able to easily track.

Going through this exercise I’ve noticed a change in trends of what clients are looking for.

In days gone by I’d get requests like “make it like Amazon / Google / Ebay / insert-poster-boy-application-of-the-day-here”

The most common request I get for now from all clients is: “Make it simple” (often followed by; “like Apple do“).

As someone who spends a lot of his time thinking about the holistic user experience of the applications he designs, I love that they want simple. But I know that making something look simple and making it simple to use are two very different things; many of my clients don’t.

When they say make it simple, they mean make it look simple. They mean make the interface sparse. They argue for one word where three are needed to explain the context of a label. They argue for removing icons or background colours where they are intended to add meaning to elements on a screen. They argue in favour of text being bunched up, smaller and badly spaced so it takes up less room on a screen, so it fits “above the fold”.

They lack an appreciation of the difference between simple and sparse. Between merely looking at or admiring an interface and actually using and interacting with it.

To paraphrase the excellent Mr Steve Krug; “A web application’s interface should be obvious“. It should be self-explanatory. A user should look at every image, every label, every heading, every input or button and know what to do with it, know its relevance to them in their quest for information or task completion. They should not have to think about how it may work.

One word labels like “Filter”, “Save” and “Add” without very careful placement or grouping with the things that they are related to can raise more questions than they answer. “Filter results“, “Save settings” and “Add a user” are more self-explanatory and even when carefully placed next to, or grouped with, their related interface elements still serve to re-enforce their meaning and reassure the user about what they are referring to.

While I once spent my time encouraging my clients to remove the guff and bloat that they insisted on adding to every screen of their applications, I now find myself spending time encouraging them to add just enough back in to make their interfaces understandable and meaningful.

Then we had dumb terminal machines that could remote into those mainframes

Then we had PCs that had local storage and processor power

Then we had PCs connected to the web with a bit of both local and remote processing

Then we had the web “2.0″ where we did stuff online

Then we were promised cloud computing, where we will do everything including storage online

Now in mobile we have native apps that use local processing and storage again.

Some predict the death of the web app citing native apps as the future. I say total rubbish. The future is an always on, always synced utopia where there is no longer any difference between a web app and a native local app. They are just apps. Apps that let you do whatever you want whenever you want on ANY device.

That’s where we’re going. Stop thinking about desktop vs. mobile apps vs. web sites vs. web apps. It’s just software. The lines between online or offline and device or cloud are blurring. That’s a good thing. Get used to it.

I’m not sure exactly where the idea started, but over the past few years it has become more and more popular to talk about aiming to fail fast when starting an online product or service. Don’t. Don’t aim to fail. That’s just dumb. I understand why some people say that and what they mean by it, but I worry that too many people will read the headline and focus on aiming to fail, rather than aiming to test an idea and understand what’s wrong with it quickly. Aiming to fail seems to me like a very negative way of approaching business and product or service development.

Instead, the message should be to concentrate on launching your product or service, seeing how it works, testing it and getting feedback on it as fast as possible. Then adapting. Learn what people want and more importantly need from your product or service and how they would like it to work and then move with your audience. Don’t aim to fail, aim to test, learn and improve. Aim to iterate fast not to fail fast.