In our design work, we often try to take an objective view. We try to take ourselves out of our own subjectivity and put ourselves into the shoes and minds of others, to empathise with them, to design for them. We try to remove ourselves – literally, we take our own self out of the picture – to design solutions that work objectively, not just something that meets our own personal preferences.
Mostly this gives us a useful way to stay focussed, to design well. It can also provide a useful technique for eliciting genuine feedback and avoiding any sense of personal affront – we can say things like “The thinking is…” rather than “My idea was…”.
But trying to take an objective view can also introduce assumptions. We confuse perception for reality, opinion for fact. We assume that what we see exactly mirrors what actually exists. But, as Korzybski famously said, “The map is not the territory”. Our perception will always remain subjective. Our interpretation will always remain personal. We will always make assumptions.
So how do we use this to our advantage, turn it around, make a negative a positive?
I was reminded recently that some years ago, over the course of a couple of months, I tweeted a daily “UX Mantra”. They’re now buried somewhere in the depths of Twitter, but as I still have my original notes, I decided to put them here for future reference. Some are probably a bit ‘of their time’, but I think most remain relevant. Make of them what you will. As always, take anything that’s useful, ignore anything that’s not.
I recently wanted to get my ageing iPhone 6 battery replaced. It had become excessively worn, would no longer last through the day on a charge, and – perhaps my imagination but probably not, given the well-publicised criticism Apple recently received in this respect – the phone felt a lot slower than it used to. In response to all the negative publicity, Apple were offering replacement batteries for just £25 instead of the usual £75.
As it turns out, you can’t just walk into your local Apple Store and get it done there and then. You need to book an appointment, so that they can make sure ‘your’ battery is in stock.
No problem, I thought – there’ll no doubt be a booking form on the web site.
UX Hong Kong this year once again proved to be an inspiring and thought-provoking conference. One idea I had, prompted by several of the sessions and various discussions in the breaks, was the potential value of projects having a ‘Sprint -1’.
All but the most basic web sites and online applications are really systems, and often pretty complex systems at that. Most of the projects I work on are systems – case processing, sales management, dashboards, and of course good old content management. Designing a good user experience for systems goes way beyond simple ‘user experience design’. It requires a much broader range of skills and expertise. Or if you prefer, the user experience discipline has a much broader definition than many assume… ;-)
So what makes you a good designer of user experience for systems? What sort of outputs should you be producing? What skills do you need? What does good look like?
Having just won a Design Business Association Design Effectiveness Award for a system I designed*, I’d like to think I know a thing or two about that.
(Incidentally, I’m addressing this article to UX practitioners, but if you’re someone who hires or manages such people, I hope you may find it interesting too.)
Southern is the railway operator that serves the South East of England, and runs the train services used by several hundred thousand people each day, many of them commuting between the south coast and London.
Until recently, they had a fairly horrific web site, with an ugly and difficult to use ticket booking engine. Then, some months ago, they revamped it. And – astonishingly – made it worse. What used to be painful but manageable is now painful, long-winded and very nearly impossible.
To illustrate, I want to show a couple of ticket-buying attempts I made recently. Then I’m going to share some thoughts on how I think the experience might be improved.
Following on from my article about knowledge economy skills, it may be useful to drill a bit deeper into what we mean by skills, and also how they are acquired. Back when I was authoring the UK National Skills Strategy for Interactive Media, I did a lot of research, consultation and thinking on this, which I’ll try to distill here.
I was giving a talk a while back to a group of digital media entrepreneurs and practitioners at the HUBBA co-working space in Bangkok. As part of my talk, I mentioned some thinking I have been doing around education and skills. This was well received and provoked some interesting discussion, so I thought I should write it up here.
I was at a digital skills round-table event yesterday, here in Brighton & Hove, discussing how tech SMEs can influence a city training strategy. The attendees ranged from local practitioners and employers, to training providers, local colleges and representatives of various local organisations and statutory bodies. It was a very interesting debate, with much food for thought. I had an idea…
Malaysia Airlines recently gave its online check-in process a cosmetic makeover. I can’t say it’s an improvement, but that’s my subjective opinion of course. What I can say objectively, however, is that they have made the user experience worse for at least some users – because the most important function, the ability to print your boarding pass, no longer works. They have broken the button.
You can check in online, but if you try to print your boarding pass on a Mac or iPad (and perhaps other platforms – I have only tried Apple OSes, albeit across various different devices and machines), nothing happens. Pre-makeover, the ‘Print Boarding Pass’ button used to load your boarding pass so you could see it, print it or save it as a PDF etc. Now – nothing. You have no choice but to queue up at the airport check-in desk.
When I first encountered this a few months ago, I assumed they’d soon fix it. When I encountered it again while checking in for my flight today, I wondered what it was costing them.
I do a lot of flying. Sometimes for work, sometimes for leisure. Variously in Economy, Business and First. Certainly, much of it is paid for with cash, either by me or my clients, but some of my flights – especially in the premium cabins – are funded with air miles.
Quite a few of my friends have been asking about this, so I thought I’d write up an introductory guide on how to travel for less money, or in more comfort, than you otherwise might, by playing the air miles game.
That’s perhaps a little premature, and I admit I may be exaggerating for dramatic effect, but I suspect it’s on the horizon.
I’ve long maintained that User Experience is just another in the long line of buzzwords that have afflicted our industry since its inception. Granted it’s now an established buzzword – it’s an absolutely valid discipline, and a role that is becoming increasingly accepted amongst practitioners, managers, recruiters and clients alike, but nonetheless I would argue that the label ‘user experience’, along with the UX acronym, is a non-descript buzzword.
And from where I’m standing, I can’t help feeling it’s one that doesn’t have much longer to run.
That age-old problem of job titles has been on my mind again lately, prompted by my starting to look around for my next project, hence the need to convey clearly what it is that I actually do, plus the imminent need to print up some new business cards.
I’ve been mostly calling myself a User Experience Architect in recent years, but really just because that’s the terminology agencies – digital and recruitment – relate to. User Experience is certainly becoming a more firmly established discipline, yet it remains stubbornly undefined, with myriad competing and conflicting interpretations abounding.
I’ve seen and heard of quite a few Agile projects that have failed to live up to expectations, or even failed completely. And I’ve watched organisations – agencies in particular – struggle to adopt Lean UX.
Not because there’s anything wrong with the methodologies, I think. And not necessarily because they were implemented badly – though I’ve seen that happen. I suspect it’s because one crucial factor gets overlooked – the people.