The Goal of User Experience is Invisibility


A new boss once said to me, “I suppose you’re a bit of a gadget man, then?”  I wasn’t and never really have been, except maybe a bit as a kid.  I wondered if I ought to be.  I wish then that I’d had the clarity of mind to say, “No, and it’s precisely the fact that I’m not interested in the latest thing or the coolest piece of technology that I’m passionate about delivering a positive user experience.”  Oh well, benefits of hindsight.  I would go as far as to say that the ultimate goal of user experience is technological invisibility.  People only really care about content: finding something out or putting something in: the latter, usually to complete a task.

The bare truth is that the only people that care how good your website or your app are, are the geeks, the gadget chasers and, perhaps, the competition.  In other words, if you love technology then it could well be that you’re not best placed to deliver user experience.  The technology is the enabler and the latest isn’t necessarily the greatest. For example, pushing a product to only work on HTML 5 and being dismissive of those that don’t have the latest web browser is the kind of technological ignorance and snobbery that is suprisingly prevalent.  You can actually exclude users and give them a worse experience: but you got to play with your new toy (I hope it was worth it).  As with other areas of life, it’s what you do with it that counts.  It’s more mindset than toolset, to keep up the analogy.

It’s actually very liberating when you face up to the simple and what-should-be obvious truth that users want one or both of two things: data out or data in (other than playing games maybe.)  When you see it that way then you realise that the system/website/app/whatever will either facilitate this or just get in the way.  And that is user experience.  In fact, you may not even deliver a system/app, you may just give users the data if they already have the technology and a familiar interface…and if you really care about what they want rather than doing what you want.

When I was designing a corporate user experience strategy for a global company I shied away from saying this: perhaps because it still wasn’t crystal clear to me then.  I wanted to say something about making systems invisible or making them facilitate access to information or the completion of tasks.  For me, that’s the nub of it, that’s precisely what user experience is.  No one wants to see your hard work, they just want the end result.  Information technology begins with information for good reason, yet everyone focuses on the system.  Technologists love systems, versions and upgrades and users even rate systems for the quality of data, which is invariably due to processes and governance that have little or nothing to do with the system.

And, by invisibility, I don’t mean that it doesn’t matter what a system looks like or getting your online branding right isn’t important.  I completely support the idea of design in the fullest sense: something should work well and look great.  A symmetrical home page with clear calls to action will not appear as such – it will just appear easy to use.  No one (except geeks, early adopters, etc.) will ever sit down and analyse why your site/app/etc. is so damn beautiful that it delights them.  All people will tell you is that it works well and, yes, if you push them, that it looks the part and is nicely laid out.  The point is this: the site/system/app bit is the frame but the information or the task is the picture.  And once you start to see things that way then you know what your real objectives are: speed and ease, information and task, nothing else.  The means by which you get there will be hard work, demanding and challenging (if you do it right) but invisibility is the ultimate, seemingly contradictory, goal.  And, ironically, it is invisibility that that will make you or your organisation memorable and give you strategic differentiation, user adoption or whatever is your main business goal.  The rest is just noise.

Advertisements

The Coming of Enterprise User Experience: Why CTOs and IT Directors Need a UX Strategy


Whilst yesterday’s blog was about governance and getting your website or intranet under control through information architecture, this one takes a look inside the organisation to lift the lid on the pressures on good ol’ internal IT.  UX is barely touching the corporate world with so many producing systems the old-fashioned way and some hoping they’ll solve past failures by running to agile.  And yet very few have devised an enterprise UX strategy.  The world is now awash with UX designers and architects which is great but the focus remains on external websites for customers – and on design.  I’ve previously highlighted the lack of internal focus as pure monopoly – the staff can’t choose – but that’s not entirely true.  After all, staff are consumers too – when we let them have a break anyhow.  People are now seeing good design all around them as consumers.  They are standardising corporate and personal email on one device and stroking their iPads on the train.  All this means that expectations are going up.  The days of IT Directors getting a ribbing in the boardroom about their crap systems are over; they’re now being told to sort it out.  But how?

It’s time to get some focus on this and devise a User Experience Strategy for the enterprise.  All seems a bit grand doesn’t it?  Are we not just talking up UX design here?  Do we not just need to get a few specialists in to sort out the crap apps (crapps?)?  No, this is not the design bit, some direction is required first.

Here’s a paraphrased story…picture IT management in a room having a post-beating meeting about this problem…

What’s the problem?  I don’t get it?  So what is the user experience for one of our members of staff?  Is it another gimmick, should we not just sort out the systems we know have problems and…?  No, take a step back, we need to define what it means to be a user in this organisation.  Okay.  Anyone fancy starting?  Erm, right, so users get the standard stuff as well as stuff according to their role – or department – great, we’ve got that on Active Directory so we can start to profile staff from a technology point of view and hopefully automate the desktop for new starts.  So what actually is the standard?  Ok, everyone gets MS Office and the Intranet and then their specialist apps according to their profile.  Great, so what is the Intranet for, exactly?  It’s a presentation layer over the data warehouse and a comms tool.  Is that it?  Ah yeah, but it’s being reviewed isn’t it?  Gawd knows, supposedly.  You know I think we might need some UX objectives and principles here.   This is a useful brainstorm: we’ll come back to that.  What else should be standard?  What about Single Sign On as people are going crazy about having to log in to everything, never mind the security issue of passwords being written on post-its and stuck on the monitor…. Hmmm yeah, and how is that delivered through mobile devices?  Is it all pushed through Good?  Ah, but that uses the Safari browser on the iPad but didn’t we agree to standardise on Microsoft?  No, we never agreed that.  Well it feels like we have.  Yes, but the new version of product x doesn’t work on MS Internet Explorer so we need to upgrade the browsers.  Oh, we’re still on Windows XP so we can’t go to IE10 until we’ve upgraded Windows across all locations.  Ok maybe we need to change browsers.  But doesn’t some SharePoint functionality stop working if you don’t use IE?  Really?  Ok so maybe multiple browsers is good.  But then half of our specialist web apps have not been tested (let alone designed) on anything but IE.  Right, well that needs to be built into our software procurement process.  Oh, have we got one?  Sniggers.  In fact our website is the only thing that works on Firefox and Safari (although the sandal-wearers at the digital agency forgot to test it in IE and we sell to other large corporates who also standardise on Microsoft for an easy life – and they keep moaning about our website!)  Can I just go back to SharePoint a minute – we haven’t actually decided what we’re going to use it for have we?  Are you joking?  Well we rolled out out-of-the-box team sites to get going.  Which was a mistake.  Don’t start on that.  I’ll have to tidy up the mess, thanks!  Too much devolution!  Anyway, we need to migrate our Intranet onto SharePoint at some point.  Why?  It makes things simpler and will integrate with everyone’s presence and profiles and so on.  True.  Has anyone thought about the enterprise information architecture?  Ugh, not now, stick to the apps.  Response times aren’t great in AsiaPac are they?  I wish we’d clouded it.   Oh by the way, does anyone know how users will log into our cloud apps?  Hmmm, I think we’ll need to workshop this whole thing some other time, so who fancies a coffee?

What a headache and that’s why IT Directors get paid so well!  It’s something akin to stripping the engine whilst going round the track.  And it all got a bit teccy didn’t it?  But the challenge is not for UX designers but instead for strategists and technicians: it needs to be both strategic and technically validated so that the user experience is both defined at a high level and then proven technically.  A number of people need to be involved but it must always be strategic and for the long game.  It might help to engage some friendly tech-savvy users in that workshop as well.  In fact, set up a working group because it needs user validation as well as technical validation.  Obvious really.

And lastly, let us not forget what seems like a simple choice for our IT leader to make (keep your head down and hope it will blow away vs sort it out) is more complicated because of all the moving parts at different stages of maturity and focus.  It all comes down to projects and budgets but if you can lay down a strategy then you can start to prioritise and come up with a programme of work that becomes more realistic and communicable.  It’s the user journey for IT.

Innovating in Technology: Connecting the Old with the New Through Metaphor


Heavy!  But if you stop and think about it, the whole of our technological world is pervaded with metaphors, both verbal and interactive.  Metaphors aren’t just for writers but with technology it’s the hook with the now that takes people into the future and that’s the clever bit so I’ll call these ones ‘innophors’ (innovative metaphors) for now.

I’ve previously emphasised the importance of convention and familiarity with user experience but doesn’t this sound at odds with technology and innovation?  How can we innovate or differentiate if people don’t like change, if they only seek the familiar?  Familiarity comes in many flavours and the charge of technology and computing is so often through metaphor – to such an extent that the metaphor becomes the new reality*.  Think how much we scroll, cut and paste every day without paper, scissors or glue?  Does anyone care about that publishing metaphor?  How many people know?  Last time I talked about Excel and the spreadsheet metaphor that goes way beyond the balancing acts of accountants.  Maybe some of it was chance but I do wonder how many Excel spreadsheets are actually used for accounting purposes these days.  The keyboard is a metaphor for the typewriter and in 50 years most people that remember what the return key meant will be dead and gone – maybe along with the keyboard!  Now people expect to consume information in different ways and explore information spatially through touch.

In user experience design the lovely wireframe (a plain, low fidelity mockup of a web/system screen) is a metaphor for the initial shape of something, like a sculpture, before it gets built out.  Some metaphors are a bit unusual and you wonder at their effectiveness given how many people knew what wireframe meant in the first place!  It doesn’t matter in this case as the end user does not care so much as the ux practitioner but it does emphasise the importance of the creative concept and getting it right and knowing when to name it right.  Tim Berners Lee’s hypertext concept for the web is one of the greatest innophors ever invented and people quickly caught on to the idea of hypertext links and the implications for a highly connected network of information.

Ok, so what…..how does this help us?  It’s important because the gateway for change and innovation is typically through metaphor, be it the interface or the name of some service that relates to some previously understood idea but breaks it into a new one.  It can be as significant as tweeting on Twitter or as specific and non-verbal as flicking through album covers on your ipod.  The point for the user experience is less about something being new and more that it must be obvious.  If people don’t get the idea or the functionality then it’s no good, try again.  But this doesn’t mean that you can’t bring about radical change, it just has to make sense by connecting with people’s current understanding.

So whatever you want to bring about, design or conceive it must link to the now but it does not stop it being new.  Look to connecting a new idea to an existing one and use innophors.  People need a hook into the idea to take them on the journey and the concept – be it a name or a piece of functionality or a device – is what makes something take.  It has to make sense.  Keep pushing the metaphor into new bounds to define a new reality and user experience.

*Curiously, the metaphor can take over the original reality so you’re more likely to see a mouse in a plush office than on the street, we’re better at fighting computer viruses than real ones, etc.  It’s that lovely word ‘simulacrum’ that French postmodern intellectuals talk about in cafes.  I once spoke to my daughter about what we decided to call ‘cocktail’ words on the assumption that the colourful drink concoctions were called such things because of peacock tails but when we talk of cocktails we first think of the drink variety or we bend the word to some new end, cocktail of drugs, molotov cocktail, etc.  These things become meta-metaphors or something like that.  Amusingly, it turns out that I was wrong and that the origins of the meaning of ‘cocktail’ are not clear – which kind of proves me right!  It doesn’t matter what a word originally meant, it’s how we use it that counts.  Language and symbols should not just be seen as systems to help us map reality in some fixed and finite way but instead are tools to help us define new realities and new concepts (a journey in understanding courtesy of Ludwig Wittgenstein).  Symbolic power is so often the key to making technological innovations and doing them in a way that people understand.

The Joy of Excel


Yes it’s unusual to talk about UX away from web and ecommerce but so what, Excel is UX on legs.  Ok that’s two gratuitous puns too many but I was writing about risk management last time and it does that to you.  If you like to divide people into two camps (I know, there are those that like to do this and those that don’t) there are those that admit they love Excel and those that pretend otherwise – but everyone likes it – or loves it.  And yeah I know about Lotus 1-2-3 and I’m old enough to have used it but that’s history, get over it.

Excel is the perfect partner to Word, as numeracy is to literacy.  In fact, they could have called it Number but maybe they were wise to the fact that the concept of a spreadsheet (the huge bits of paper that hardcore accountants used to use to do their numbers on) would become a metaphor for what is in fact tables and records and things like that.  Metaphors are a big thing in computing but more on that another time.

It feels like the whole world uses Excel, in their work but also at home, even if that isn’t quite true.  Yes people still use it for balancing accounts but also for lists, managing projects (who can be arsed with the bastard child that is MS Project anyway), databases, reporting and anything else you fancy.  In fact, this versatility creates an End User Computing risk in some organisations as smart people in the business start to build non-supportable critical applications – ok UX can maybe create risk too!  People use it at home also – for balancing accounts, managing projects…the same things actually.

So what’s good about it?  The concept is great, columns and rows, lists and records.  You sort everything out, fair and square in nice little boxes and then do clever things very easily and then get to make it look good with charts and so on.  I’d bet there’s a lot of people who avoid going to parties to spend time at home on a pivot table.  Excel is easy to use but the fundamental concept puts you in control of whatever it is you want to do.  User Experience frequently takes account of putting users in control because they are people and people like control whether they admit it or not.  You want simplicity but you want control and sometimes these things seem at odds, ie simplicity = less functionality but control = more.

Giles Colborne of CX Partners wrote a great book called Simple and Usable which describes four strategies: Hide, Organise, Remove, Displace.  I like to turn these into the ironic mnemonic, HORD.  The key thing is to get shot of what’s needed and put occasional/first time functionality out of the way to retain simplicity.  This is what control means.  Over the years, Excel has grown and grown till its groaned.  Just how many toolbars were there?  The whole Office suite was exploding with functionality and something needed to be done, hence the move to the ribbon.  I’ve heard also that Microsoft got tired of requests for functionality that already existed so they made better use of the menu space by making it context sensitive.  The move to the ribbon in Office 2007 upset the hardcore Excelers.  Why move stuff?  Users were lost, for a little while.  I trust they did a proper information architecture research job to structure and label the information in the minds of the user.  But change is change and however good it was it was a major disruption to people’s habits.  It was a big step but it highlights the power of convention in usability.  If you’re used to it, it works, warts and all.  If you use Microsoft products then getting another one makes life easy because you get the layout and look-and-feel without having to think about it.  What’s best is not always ‘best’ in the eyes of the techy purist.  I think that simple fact, alongside compatibility and integration, is one of the biggest reasons why Microsoft dominates – it’s not just slick marketing.  Go on, mention the decline in Internet Explorer but face it, the controls are more on the websites than the actual browser so who cares.

Excel is probably the best thing Microsoft has ever done – and maybe will ever do.  They were lucky to popularise a great concept but they’ve done a great UX job on it nonetheless.  Whole businesses run on Excel (even if they don’t realise it) and whole households run on it too, from a simple list to a sophisticated database/reporting engine.  Excel gives everyone control and everyone the chance to be a spreadsheet geek; maybe the only thing it’s not good for is blogging.

User Experience Design as Risk Management


Exciting stuff, huh!  There’s no gags, puns, alliteration or other clever stuff in the title of this blog because it’s time to talk risk management which is – as you know – a very boring serious matter.  This blog looks at user experience strategy as a risk mitigation tool for web and software projects.

User experience is often miscast as usability or user interface design – which sound a little bit non-essential and nice-to-have.  Yes, UX encompasses those things but it’s the whole process that is important and sometimes misunderstood.  It’s about getting the deliverable right so I’m not going to talk much about usability or user interfaces here, just plain old projects.  And with projects come risks.  Sometimes risk is all that people understand and if you’re a fan of the psychology of behavioural economics then you’ll know about loss aversion.  In plain English, that means that people are more likely to be motivated to act if they think they will lose something than if they think they will gain something and risk is usually about losing something.  Which is why everyone loves, or rather hates, risk.  That includes project managers and rightly so.  So, let’s not sell the benefits of a user experience and instead sell the risks of not doing it.

Every project pack worth its salt has a list of risks and mitigating actions to ensure project success.  Risks come in many flavours but can include issues such as poor user adoption/loss of confidence, regulatory breaches, costly errors, loss of revenue, loss of reputation and so on.  Those risks can play out both internally and externally at an organisation and everyone wants to get the project right.  So, how do you get it right?  You go to the business or customer, ask them what they want, write it up in to a 72 page document, ask them to review it (which they don’t), call a meeting to talk them through it, chase them to sign it off (which they do – because they want the project done), maybe write a functional spec, hand it to the developers, months go by and, fingers crossed, test against the functional spec and done!

That’s a cynical but not wholly inaccurate take on the so called ‘waterfall’ software development method that has a linear set of steps.  Best of luck to everyone involved.  Unsurprisingly, it often doesn’t deliver to expectations.  People are now starting to turn to ‘agile’ because of this very fact – they have concluded that waterfall doesn’t work.  Agile is an iterative, little and often, show-and-tell approach with lots of questionable terminology (‘sprints’, daily ‘scrums’, ‘war rooms’) to make the new thing sound clever.  Naturally if you show a system bit by bit to users then you can clarify the direction of development which is great to ensure correct delivery but it can be hard to control scope and get the thing finished.  It’s also fun and removes planning and documentation so those that like to avoid such things love agile.  In other words, it manages some risks but raises others.  In some cases agile might work well, especially for an innovative piece of product development but for many projects it just misses out the steps and the clarity required to get things done properly, hence it’s often dubbed ‘fragile’.

So, nothing works.  Ok ok, I’ve been rather unfair about both these methods but the methods aren’t the point – the approach is.  I know waterfall can work well and someone must have seen agile deliver to keep on doing it.  However, the fundamental issues when projects do go wrong are simple – not getting the requirements right, not getting the design right, not getting sign-off right, not doing testing right, not communicating right.  I’d love to see these risks in a project pack – instead of lack of resource and the usual ones PMs feel they ought to put in.

This is where user experience design proper is meant to help: UX is doing waterfall or agile or whatever, right.  A user experience approach entails getting into the shoes of the user, identifying the types of user you have and noting their needs and preferences, observing them using a current system or process, interviewing them, understanding their decision-making processes, etc. It doesn’t have to take that long but proper research needs planning in to the project.  Once you start to gather this information you can clearly map user types (personas) to processes and draw visual diagrams to represent this alongside written scenarios.  These are the sort of documents that users will understand – and will sign off for real.  Requirements done then you can start to design to these requirements through standard techniques such as wireframing (as well as functional specifications).  There might also be a need for information architecture to help organise and label information in the most useful way.  This information should feed into the wireframes and a site/app map if required.  A visual design exercise may then come into play (especially if it’s a web application).  Again, visual designs can be signed off by users before commitment – even if the build has started.  Use workshops to present and validate the design, not to brainstorm and put the onus on the users.  Tweak it and build it and test it, against the functional specification but also against the scenarios and get the users to run through the scenarios – and observe them.  If it’s not obvious for them to use then it’s a problem.  Dig deeper and make changes before final testing commences.  Write a Quick Start Guide to help people understand the capabilities.  Again, ‘test’ it with a few users.

What’s good about this approach is that the users are engaged throughout the process to mitigate against the risk of designing to abstracted requirements.  The users are also involved in the design, sometimes in the information architecture or sometimes in discussing options around wireframes and designs.  There will be few chances for surprise and disappointment.  Also, with a defined set of users you’re doing change management by engaging them and getting them to sign off on tangible deliverables, helping to communicate the change and helping them to own the design.  In other words, the chances of adoption are greatly increased.

So, UX helps you get the system right because website or application building is a design process that needs to go through steps.  When you use words like architecture, design and build then the clue’s probably in the metaphor – it’s not too unlike building a house.  Waterfall and agile are sort of besides the point.  Only the largest corporates are beginning to understand the need for UX for software projects but you’ll see this approach catch on hugely in the next few years so it’s worth catching on before you have to catch up.

A pull handle on a push door


It’s annoying isn’t it.  Really annoying.  Which way that door is going to go.  Pull or push or both?  Who cares, you just need to get through it.  It’s got a handle on it.  Give it a pull.  Dah!  Fooled ya! Idiot! can’t you work a bloody door?!  How many times has this happened to you?  Not something worthy of an international crisis, sure, but add it all up and it counts.  Then add up all the other people that have had the same experience (as well as the irritation, embarrassment and distraction) and time is the thing that costs – and reputation.  Emotion counts.  If it’s a service or website or application, you may give up, or go elsewhere, or try and learn how the thing works – but only if you have no choice.

I’ve experienced very plush offices with just this door problem.  The solution?  Have ‘P-U-S-H’ stencilled on the handle.  This is called designing around a problem, or in medical terms, treating the symptoms rather than the cause.  Of course, people still wander up, alone in thought or busy in conversation, see a handle with their peripheral vision, and still pull it.  Dah!  In business, it’s the kind of issue that people try to measure with ROI.  We’ll show you how much you can save by solving these problems – something which, of course, will cost.  Don’t bother.  Just solve it. In this case, just remove the handle.

Now if you ask those guys in Facilities I bet they’ll tell you how it is.  Oh, we need to leave the handles on in case we need to reverse or reposition the door and the cost of removing the handle…  Oh come on, really?  How often do you need to do that?  You’d be surprised.  I bet I wouldn’t.  We’re always having to make changes to the office.  When did you last reverse the way a door opened?  Ah, I can’t remember but we’re always doing things like that.  Sure.

It’s the same in IT and application development.  It’s not obvious how to do that function – yeah, it’s a training issue.  So, we’ve designed it so badly we have to train people how to use it.  Sometimes it’s more subtle.  I was recently involved in the migration of an application for a FTSE 100 company.  The data had already been well positioned and structured in a data warehouse.  Thankfully, no one was interested in revisiting that and we could focus on the front end.  For once we could start with the user interface rather than the database, the only bit users care about.  So, let’s speak to the users and see what they need.  Well, we took the opportunity to revisit the information architecture (how information is grouped and labelled) as well as integrating the visual design with the rest of the Intranet and with a fully indexed search capability.  Great!  But.  But what?  They still want the ‘field finder’ functionality.  Ugh, really, they can’t find fields??  We don’t want to do that, surely.  Yes but people are asking where it is as they use it extensively in the current interface.  No, let’s not do it, we’re designing a product for them with their steer and our expertise so that finding information should be intuitive.  Out of scope.

We went live and no one’s missed the field finder.  In fact the system has been a huge success, one of the few projects we’ve been excited about putting live because we knew we’d got it right.  We knew that because we’d adopted user-centred design for a user experience that worked.  No, it wasn’t for a high volume retail website, just an internal application – one that is critical for the business – over which the users have no choice.  Afterwards, I said to the project manager that it was well worth all the extra effort and he said, no, it wasn’t extra effort, just a different approach.  Fair comment, this cost no more, we just did things better than we usually do.  Enterprise user experience is taking over the largest of corporates but everyone else it seems is still catching up.

User experience is not difficult, is not adopting “agile”, is not the sum of this or that set of methods but is an approach.  If you engage the user to understand how they work, use your design experience, and test your work then you’re more likely – far more likely – to have a successful project.  If you make people walk in the dark then they’ll ask for a torch.  If you put on the lights, they won’t think about light at all because they can crack on.  Do the work and give people what they want – and not necessarily what they ask for.