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

When your shiny new website is no better than the old one.


You come across this so much with websites.  It’s the same with other applications too.  The new project will save us.  Just the thought of having a new thing, like a new car, to blow the cobwebs away, nice new design, nice clean smell, lovely.  It might be a new web design or it may be a brand new website but unless you’ve done the research and put together a content strategy then you’re leaving it to chance.  At worst, you’ll irritate people by changing something for the sake of it.  Amazon may not be the most flashy of sites but customers rate their overall service proposition so highly that Amazon are probably, and rightly, very cautious about changing it.  Let’s be clear, there’s nothing wrong with changing a site but unless you have clarity on who it’s for and how you’re improving it for them, then you’re on high risk ground.  Don’t just do it to make yourself/senior management feel better.

Let’s be clear, a website is just another means of communication.  I know, what a revelation….  But it’s so often forgotten.  I’ve made this analogy before.  Think of web content as speech and the site structure and design as body language and it might just focus the mind a bit.  If the two things are clumsy and don’t work together then it’s awkward.  Think, as you would with any other communication, of your audiences next.  Then think again and dig deeper.  This is the research part.  Know your segments, trawl your web analytics, scrutinize your marketing data, look at what your competitors are up to.  Interview user representatives about their needs and how they want to interact with your website or digital offering.  Build personas for each user type and use them as tools to guide and test design for the future.  Use the outcomes to build scenarios and understand how these users move between emails, devices and other touchpoints as well as what they do.  Don’t bother with a mobile strategy, it shouldn’t be a separate thing.  Have a digital strategy, know your capabilities and brand and build a proposition and user experience around it.

Then there’s the content.  This requires some strategy of its own.  What content can you provide or syndicate?  What are the themes?  How do they relate to each segment?  Who’s going to provide it?  Who approves it?  What requires regulatory compliance and what doesn’t?  Research what content works well now and bin the rest.  Start afresh with the right tone to reach the audiences and put some personality (preferably your brand) into it.  Write small chunks for people to digest and don’t try and teach them general things about your industry – users will find this elsewhere.  Show them what is of value and nothing more.  Then work out your trending themes and what types of content you can add value with that has a shorter lifecycle.  Once you know all these things, you’ll want to put a full content lifecycle process in place and have that supported by a content management system.  Please don’t buy the system first and then work it out.  As with a new website, unless you’ve done the work upfront, the system won’t save you.  Whatever you do, don’t migrate content that is old, stale and barely used and, if you’re putting in a new content management system, don’t let it dictate your content governance model.  It’s the same with any system, you have to do this the other way round: sort out your data and sort out your governance and then implement otherwise you’re setting yourself up for failure.

Upgrading your website is hard work but rectifying a mistake is even harder and more costly.  Good luck!

Why Business Analysis Fails the User Experience


We live in a world of opposites, or at least that is how people view the world. Previously, I talked about those that prefer either traditional, sequential waterfall software development or the more flexible agile approach. You also tend to find two polar opposites in the development of business applications in contrast to websites and e-commerce applications.  IT tends to attract those people that like to work with technology – and not people; whereas Marketing, where the whole point is to engage customers and interact with them, tends to attract those that like to work with people.  Yes there are exceptions but as generalisations they are true; I’ve worked on both sides of the fence and seen the differences consistently.  No wonder then that we find different worlds and tensions.  To get their websites done Marketing would sooner get their own team or outsource to design agencies who know the importance of getting across the right message, or customer experience in the fullest sense. This is all well and good in e-commerce but who will champion the corporate customer, the poor staff member with no choice but to be served by IT even when some of the systems they have to use look like they were designed by children?  We end up with a split between the user-oriented web/e-commerce sites that can delight their users (as well as sometimes frustrate them in their careless execution and lack of attention to detail) and business applications where the requirements are gathered and delivered to in a way that frequently fails to deliver to expectation. Have you noticed that the main difference in personnel is the presence of UX designers on the one hand and business analysts on the other?

Software development is full of business analysts whose job it is is to gather requirements, analyse them and propose solutions in consultation with technical staff.  It’s a very logical, rational process.  Business analysis is great because good analysts ensure a good coverage of requirements and system needs.  The problem with analysis is that it does what it says it does – pulls things apart, strips the engine to its component pieces to be comprehensive – but focuses less on how these parts are assembled and how people will make sense of them.  Business analysts are a bit like police – just the facts, ma’am.  In the functional specification (if there is one) there may be a flow diagram or two, clarification of fields on a form and so on but the design responsibilities often end up with the developers if only because no one has done the work up front.  In other words, a key part of the project hasn’t been done.  This approach is unthinkable in most product development practices where working hard to assess needs and validate designs is imperative.  The UX approach is to look at who the types of users are, their aims, their preferences and so on and what tasks these users need to do.  Personas and scenarios are modelled visually so that all project stakeholders can understand and comment on them.  This typically moves on to an information architecture/wireframing/visual design phase where key parts of the solution are prepared visually, again by designers who understand the requirements. These deliverables can also be reviewed and signed off by stakeholders before commitment to build so the users know what they’re getting and the developers know what they’re building.  Any scenarios can be reused to test the final deliverable which tops and tails the project quite nicely, ie testing the deliverables with the requirements.  In contrast, the traditional software approach is to test a list of functions individually.  Whilst this should also be done to ensure full coverage, what it fails to do is to evaluate how these functions work together, ie the user experience.

So, business analysts need a sea change in their approach and need to work alongside UX specialists to deliver user centred design.  Conversely, it would be good to see business analysts more consistently involved in the web/e-commerce world to ensure the job is done comprehensively (a lot of design agencies can’t be bothered to test in different web browsers for example – too boring I suppose).  The fact of the matter is that good software and web projects require both the detailed approach of business analysis and the holistic approach of user experience design to ensure that user needs are met both comprehensively and in alignment with real users in real life scenarios.

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.