How it all began
My journey into UX began back in the mid-90s. I was lucky enough to learn about the Internet whilst at University. I remember heading to our computer room – a small office in a basement in central London. Access to the web was via Mosaic, a web browser. To access the websites, I remember having to type in an IP address – whilst domain names existed, they were hard to find. I remember Yahoo! coming out – making it so much easier to find things.
Not that there was much to find. Luckily my course taught us how to make websites, and also how to program Flash & Director. Back in those days, they were made by Macromedia. I had the power to make content, so set about learning what to do. I quickly grasped programming and helped fellow students create their projects. No-one wanted to fail, and fees were usually negotiated by the number of beers owed in the bar.
Upon leaving University, I was lucky enough to start my own business, Ymergyn. I had helped a Photographer’s agent in London, servicing his Apple computers, and as the web was quickly expanding, developed websites for their photographers, teach them Photoshop and set up their printers. It was by chance that I would bump into a web developer at one of my clients. He was about to join a company full time, and could no-longer fulfil a client’s project. So he passed it to me.
The project turned out to be for a big client. BP required an extranet site for its Acetyls business, and it was my job to build it. Unfortunately (fortunately?), the agency I was working with were print designers, so I had to also design it. And so my UX journey began. It just wasn’t called UX then.
UX evolution
Those early days taught me to design products for the end user. There were no rules, no frameworks, no processes, and no experts. The few of us working in this field in London openly shared ideas and learned from each other. It became clear that the user was the most important person in any product. Get the product right for them, and the spreadsheet would fill itself out for the client.
To me, this was UX 0.1. User Experience before it became User Experience. The learning stage – an industry that was learning to crawl. The original websites were pioneering – but shockingly simple when you look back. The tasks were simple, but the methods complex. Everything was hard. Everything was from scratch.
UX evolved over the years and eventually was talked about in earnest about a decade later. So jump to around the mid-’00s, and UX was on everyone’s lips. The rules had been defined, and the process was ready. UXers could exist – companies wanted them to help them develop their websites correctly, or at least on the path to correct. UX 1.0 was born.
It has only been recently that UX has re-invented itself. UX is now well practised – with products having clear stages through Research, Ideation, Prototyping, Build & validation.
Inclusive UX
I first understood how to design for Inclusion during my time at the BBC. Our project was complex – localised into a number of languages but also required to exceed accessibility standards. I remember requesting a meeting with the Head of Accessibility, to check we were on the right path. As he was totally blind, he was well placed. The first thing he wanted was an overview of the project. I grabbed the mouse and looked at his screen. Without saying a word, he leant forward & turned the screen off, and unplugged his mouse. “You tell me if it works”, he said. Suffice to say it didn’t, but it was a great learning experience. People use the web in different ways, with different tools. And so this became central to my design ethos.
Jump ahead another decade, and we are in the mid 10’s. Mobiles are taking over from desktops, but so UX needs to evolve. It becomes mobile first. Functionality is paired back, so as not to bloat the mobile interface. It soon becomes clear that – in general – the extra functionality is not required. UX 2.0 is born – Keep It Simple Stupid, as I call it.
So what is UX 2.1?
The main problem with the majority of current UX is that accessibility is ignored. It is still viewed as a ‘feature’, and usually, de-prioritised out of the MVP (Minimum Viable Product). Why waste time building a feature for the few people that are disabled – when you can build for the majority of people.
So this is the mistake that’s made. Accessibility is viewed as being for the minority, not the majority. Yet in the UK, it is estimated that 18% of the population* are disabled, with many more impaired – something that isn’t technically defined as a disability but affects their ability to function in everyday life. Something that makes their life more difficult.
Why should deliberately excluding 18% or more of the potential audience be deemed not a requirement? Especially as feature requests are often required to tweak the conversion rate 1-2%. How about tweaking it 20%?
That’s a huge population in itself, but designing for a user’s needs is more than just designing for accessibility. It designing for everyone. UX 2.1 is situational UX. It understands that accessibility requirements are there to help build products that people with permanent disabilities or impairments have. But also extend that to people with situational or temporary disabilities.
And this is what I call UX 2.1 – Accessible UX for everyone. Why 2.1? As you see, UX has evolved, and so have the accessibility standards. And the best/most used standard for web accessibility – created by the WCAG (Web Content Accessibility Group) – has also evolved to version 2.1, and include new technologies including websites. UX 2.1 is UX plus WCAG 2.1
What does UX 2.1 involve?
I’ll explain more in future posts, but for now, I’ll summarise. Accessible design is for everyone. Everyone is disabled in some form or other depending on their situation.
Users watching videos at work, or on the commute can find audio intrusive – closed captions allow them to engage without sound. Mobile users using interfaces whilst walking can find larger buttons – conveniently placed so as to not drop their phones – advantageous. Sunlight glaring off mobile screens can make feint text impossible to read. Looking at bright screens in dark rooms can cause eyestrain – so having the ability to reduce the contrast can make things easier.
None of this is hard – it just needs Product teams to embrace it. For it to become part of their process. Make products designed & built to be used. By everyone. Wherever they are.
Not make products that make as users’ life unnecessarily difficult.
* https://www.gov.uk/government/publications/disability-facts-and-figures/disability-facts-and-figures