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 which 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.

When I found out that the flat I moved into in the middle of April was in a VirginMedia 50M broadband zone I got very excited.

When we finally had an engineer round to install said broadband (it took over a month) I got even more excited.

When I woke up one morning to find that we had no connectivity to the Internet and a dead telephone line I was very much not excited.

I went through the normal procedure of turning everything off and rebooting the router with no luck. I checked the phone line and plugged in different phones to make sure it wasn’t a dead phone causing the problem, still no luck.

I used my MIFI to get my laptop online so I could check for known issues. I found the Virgin broadband status page and was told there were no known issues. So, as a last resort, I phoned the customer support number (from my mobile – expensive – as the Virgin telephone line wasn’t working) and reported the problem.

The very helpful customer services person on the other end of the line confirmed that there were no known issues in my area (after checking that I’d run through the standard turning off / on routine) and booked in an engineer for the following day to come round to my flat and test my connections.

End of story until the next day. I went out in search of a proper broadband connection (thanks Starbucks) and got on with my day.

A few hours later I get a text message from Virgin (good customer service, keeping me informed) letting me know that a fault had been identified in my area and that an engineer had been sent to fix it. The engineer who had been booked to come round to my flat the following day had been cancelled as the “known fault” escalated the problem and meant it wasn’t a fault with my connection or equipment. Great.

I carry on with my day assuming that wheels are turning and things are in motion to get the problem fixed.

Later that afternoon I return home to find a working telephone line, but no broadband. Hooking up my MIFI again, I figure I will check the official status page again for an update. Only, the official status page had no update. It still showed no known issues in my area. I guessed that they were so busy fixing the known fault, it hadn’t been updated yet.

Later that evening my telephone (the one plugged into the Virgin phone line, with a Virgin provided number) rings and I answer to Virgin customer services checking if my phone is now working. Which it is. As they proved by talking to me on it. Great. Still no broadband though, which seemed to surprise the Virgin worker, “oh, well we have an engineer out fixing it and it should be working again within the next 5 hours. In the mean time just reboot your super hub every now and then to see if it’s working.”

For the rest of the evening I reboot my super hub every now and then and still have no connection.

The following morning we still had no connectivity. Still very much not excited. I hook up my MIFI again to get an update, but the official status page still insists there are no known issues in my area. Frustrated, I call the support number (free this time as the Virgin phone line is working) to see if I can get an update.

I explain the problem, the customer services person checks their system… “There are no known faults in your area, I will arrange for an engineer to come round to your flat tomorrow for you.”

“Hold on,” I interject, “that’s what I was told yesterday…” I explain the story and the “unknown” known fault.

“Okay sir, in that case there is a known fault in your area and it will be fixed soon.” I’m now confused.

It turns out that in the World of VirginMedia not all faults are created equal. Some faults are special faults that are only reported to people who don’t answer the phone to customers, and are certainly not reported publicly on the official live status page of the VirginMedia website.

Which (finally, to your great relief I’m sure) leads to my point: As a service sector company, communicating with your customers when things go wrong is hugely important. If like VirginMedia you have a status page on your website that suggests that your customers can find up to date, live service status information on it then it needs to show exactly that. Anything less is raising your customer’s expectations and then failing to meet them. A combination that results in very upset and angry customers and provides a really bad customer (and by extension user) experience.

Virgin eventually fixed my broadband connection later that second day. And, in fairness to them, called me back several times to give me updates. Over the few months we’ve been a customer of theirs that has been the only prolonged down time we’ve experienced, and I’m pretty happy with the speed and service that we get.

But on that day, when they failed to deliver their promised service, to be told that their status page only shows some faults made me question how much longer I would be a customer. It felt like I was being lied to, and it hugely lowered my opinion of their ability to deliver a service.

If you want your customers to trust you and, more importantly, stick with you when times are tough you must be open, honest and responsive when things go wrong. And you must also never raise expectations beyond what can be delivered.