Below are two examples of parking machines. The proposition in both locations is the same: you park your car and before you leave you put a ticket in the machine and pay for it. That's about as complex as it gets and yet these retail owners have two very different approaches. One has gone for a simple design and interaction approach and the other...well the other has decided it's a good idea to bombard you with information that completely lacks any hierarchy.

Now I think most people are smart enough - and have most likely been conditioned over time to understand the process and the order in which they need to submit ticket, pay and leave - but it's interesting to see the likes of Westfield go with the information design we see below. And when I see interesting I mean perplexing. #over-engineering. 

Exhibit A - Westfield, White City, London, UK

Exhibit B: Mall of the Emirates, Dubai, UAE

Now the Mall of the Emirates design lacks a certain finesse visually but hey, it does exactly what it is supposed to and when I am trying to drag my wife away from the shops at the mall, being able to pay and go as quickly as possible can only be valued as a good thing. 

Facebook, Google+ and the BBC Sports website are just three site’s which have dramatically changed their visual design recently – and faced the wrath of their user base as a consequence. All you need to do is hit Twitter as soon as a major players tweaks the front-end to see the stream of vitriol emerge from the masses.

Whilst this type of discussion will have marketing and brand executives quaking in their boots I would argue that change, if considered and well researched, is worth the risk.

Websites and designs are meant to evolve to reflect both changing user requirements and technology developments. Of course, there is a right way and a wrong way to go about this. I am here to tell you how you can update your front end with confidence and pride.

Figure 1: BBC Sport old design

Figure 2: BBC Sport new design

Figure 3: BBC Sport new design Twitter backlash

Rule number 1: Base the change on an actual requirement
Don’t change design for design’s sake.
Endless rounds of interface updates are the stuff of nightmares for your loyal users. If you are implementing an update think about where the requirement has originated. If it’s an anecdotal piece of feedback from the Chairman’s son, it’s time to question the value of following it through.

At this point it’s a good idea to some general research with your audience. Collate all the feedback comments and see if this reveals any insights with regards to actual requirements, and if a change has originated from a business need, look to see if this is going to conflict with what your users have told you. A little bit of legwork could prove invaluable in either red-flagging a senseless change or supporting an innovation. 

Rule number 2: Before you go live, do some user testing
User testing is often that part in the project that is squeezed out due to time pressures. This is absolute stupidity/madness.
Why take the risk and launch something without actually knowing if people are going to use it? All you need to do is haul in a minimum of 5 representative users and take them through a task-based test. Can they still achieve the goals the interface is designed to facilitate? Are their any obvious barriers to completion that we have time to change before go-live?

It will take a day or two of project time but will be worth it.

Rule number 3: Prepare for the haters
Know this, as soon as the change goes live the haters will emerge. You can’t please everyone.

All you need to do is listen to the feedback – the constructive parts of it anyway – and see if you can learn something from the negative comments. Try and engage with these users and find out if perhaps there are fundamental elements missing that would help improve their experience.

Rule number 4: Change is good
If change is based on a real requirement and has been properly researched and tested, it’s absolutely a good thing.
Sometimes organisations think that because their product works well and has a degree of market strength, they can avoid thinking about paying for design updates. To some extent you can but complacency will get you in the end.

Innovation rests at the core of the technology industry and if businesses want to maintain a comfortable position, in front of competitors, then it’s time to think about how you can stay ahead of the curve.

However, this process does not always run smoothly. You get angry stakeholders and you get apathetic ones. Each type can be difficult to manage and it's often down to the strength of a Consultant's communication skills to keep things in check.

Below are some extreme personalities that I have come across. Okay, it reads like a work of fiction but I can assure you they exist within every large organization on the planet:

a) The Krug Protégé  - he (NB: this type is always male) read "Don’t Make me Think" by Steve Krug during his commute to work and had an epiphany. He now knows everything about user experience. No really, he does. That one little book changed his life and he is now using his company's web projects to "wow" senior management. That means challenging the minutiae of a wireframe and seizing opportunities to belittle consultants in a workshop - he who shouts louder and all that. Sadly the Protégé misread his beloved book and so absorbed is he in his own opinion and expertise that he does not value the contributions of others - especially not those users that keep schlepping in for testing and stumbling over the very functionality he recommended. Pah! What do they know? They haven't even read the book!

b) The Teflon Shoulder - Teflon has a prominent position within his/her organization - although the exact skill-set and reasons why they have clung on to such a role for so long are much speculated. One of the key suspicions is that Teflon is an excellent delegator and that means that all decision-making responsibilities are passed onto some other poor sod. Should that decision turn out to be disastrous for the organization - and in turn for the poor sod - well, that is certainly not Teflon's fault. The impact of Teflon in the stakeholder team is that timescales extend to infinity and beyond. There's a sharp intake of breath when the Consultant pushes for sign-off on just about anything because, as Teflon will tell you for the 100th time, it is not his/her responsibility.

c) The Bored Boss - The Boss is very senior. The minions within the company often refer to the Boss in hushed tones; such is his/her esteemed position within the organization. The Boss however is totally baffled as to why he/she is being consulted and involved in the user-centered design for this project. Isn't that what they employed Teflon for, for goodness sake? As a result the Boss will spend all meetings and workshops focused on his/her Blackberry, occasionally sighing or looking over their perched glasses as you try and whip up some engagement. Whether they are checking emails or trying to beat their high score on Brickbreaker, nobody knows. All you will know is that that deeply irritating scrolling sound will be the soundtrack to your frustration as you try to engage them within the process.

So as you can see from my over-dramatized descriptions above, not all stakeholders are equal. They are unique personalities and they need to be treated carefully. And no, you cannot get away with excluding them from the process entirely. Just as you want your user requirements to be met with user engagement, you need to do the same for your business requirements. That means putting both your kid gloves and "game face" on.

To make it a little easier I have found that there are a few golden rules that, when followed, go far to avoid poor stakeholder engagement. 

FYI: These tips are generally applicable to large organizations: 

1) Have a stakeholder strategy - now I don't mean go away and prepare a novel, documenting each stakeholder in excruciating detail, I just mean dedicate some time at the start of the project to thinking about who you need to engage and how you need to engage them. Start by brainstorming within your team and listing out all the possible stakeholders touched by your project. Alongside each name consider: to what degree does the project impact them, what their expected position is going to be, supportive/neutral/challenging and their degree of influence. Once this is complete you can work out the method of engagement you need to take and the communication style you need to adopt. Those with high influence and a more challenging style often appreciate face-to-face or direct telephone contact for example. A special person needs a more special and unique style of management etc. This will help everyone understand the general stakeholder landscape and will ensure that the entire project team knows the mode of engagement from the very beginning.

2) Set expectations at the beginning - now some stakeholders need to sign off on every key decision, but this degree of approval is generally sought from the person at the top and NOT from every stakeholder possibly impacted by the project. From the very beginning it is your responsibility to make this clear to everyone. You will not be holding workshops to get approval from each person on minor interface tweaks or color palette selections - no my friends, this is not a democracy! Of course, they will be encouraged to feed into the process but only in a very structured way via interviews or workshops that will be established to take place at key intervals in the timeline.

3) Understand the context - you need to swot up and understand what has come before this project - what ventures did they try and fail? Was anyone sacked because of what happened? Is there any brewing resentment in the corporate ranks? A lot of this you will pick up from the stakeholders themselves and it's a good idea to start the project with an introductory "get it off your chest" session. This allows everyone to get their voice heard and also enables you and team to understand both what to avoid but how to avoid the design solution you are implementing. It's also a great opportunity to get gossip and understand power plays.

 4) Meet commitments and provide follow up efficiently - to a stakeholder, especially one genuinely excited about the process, there is nothing more annoying that giving up 2 hours of time for a workshop only to never hear from the moderator again. If you want to really involve stakeholders in the process you have to keep open channels of communication. As we mentioned above that doesn't have to - and shouldn't mean - that we seek feedback on every single detail - but it definitely should mean that you maintain regular email contact and let them know how things are progressing. The end result is positive engagement that will spread throughout the organization.

5) Be flexible and open – my first step was decide on a defined strategy for engagement and I have also talked about set times for workshops and interviews. It all sounds quite rigid and structured but what I should also say is that you must be open and flexible when it comes to this process. Just as project scope's change, so do stakeholders and it's up to you to keep your ear on the ground and respond to criticism or praise from your client. Don't be afraid to change tack. Whether it's upping the number of interviews you have or the scaling down the frequency of communication remember that at the end of the day you are dealing with human beings - who also happen to be paying your bills. In all projects openness beats mystery any day.

So they are my top tips. Now over to you…

What kind of stakeholders have you encountered during your professional career and what techniques – non-violent please – do you have for dealing with them?

Thanks for reading!

Yes, I have been injected with a combination of verbosity and some good old jolly festive spirit.

Whilst some of this can be put down to the last few days of imbibing, eating and receiving more pairs of socks than a man will ever need, a tiny part of my happiness should be attributed to a strong trend observed in the run up to the holiday season.

Because during this frenzied time we saw some eye-catching campaigns emerge from global brands. These were designed to lure us in and elicit a good feeling" about both company and experience. And I think some of them worked well.

As campaigns they often capitalized on the consumer's own devices, downloading neatly and allowing users to engage with the campaign in various hotspots - either within store or at home. Augmented reality - yes those two buzz words that are the stuff of marketers dreams - featured heavily and was applied in a fun and often meaningful way.

Here are some prime examples of what I am talking about:

eBay Give-a-toy store

This was a clever corporate social responsibility (CSR) strategy for eBay - aligning their brand with the act of donating to a worthy cause. All users had to do was interact with QR codes and by the simple click of a button they could donate whatever they could afford. The visual feedback provided by interactive character animation is a nice, warming touch.

This is seamless and an approach that could work well year round.

Maybe then the streets (at least of the UK) would be rid of "chuggers".
For those unaware of the chugger experience:
1) count yourself lucky and
2) Imagine being accosted as you walk down a high street to sign up for a charity - by about 6 young adults all vying for your attention and making you feel guilty for studiously avoiding eye contact.

[View:https://www.youtube.com/watch?v=Yw1u40g5qH8]

Macy's Believe

Augmented reality for kids. No really, it is. This is a sophisticated way of interacting with some characters and taking a memento of the experience away for keeps. It's cute, it's interactive and it encourages customers to get in store.

[View:https://www.youtube.com/watch?v=xvzRXy3J0Z0]

campaign page: https://macys.com/believe

That's just two....there are many more and I would be interested to see what stood out for you marketing wise this holiday season.

To close, I think the reason why I wanted to blog about these particular campaigns was partly because:

a) They genuinely bought a smile to my face; and
b) They prove that technology can indeed be fun. Users don't necessarily need to know how it all works, what the back end looks like and what code gets involved when creating such experiences. In fact I would wager £100 on them not even caring. It's about the experience and what they get out of it emotionally and functionally.

Remember that the next time you get bogged down in the the minutiae of mobile, PC, tablet and software creation.

A (belated) Happy Holidays!

I send out wireframes for review and feedback. These may be low fidelity sketches or high fidelity interface mock-ups. Whatever they are I send them out for comment because I believe in a collaborative process.

I compose the email, explain what wireframes are and how they are not indicative of actual design etc. and press send. Then I wait...

And here is where my special skill comes in because I sense what is coming next. It's inevitable. At some point - typically within the first 15 minutes - a colleague and/or client is going to come back and write the following:

"These are good but it would be great if you could add more colour."

Figure 1: Spot the difference, one is a low fidelity wireframe the other is a visual design

Obviously at this point I smile/sigh to myself in despair. It doesn't matter how many times I iterate the purpose of wireframes and how they are differentiated from visual design by their very nature and concept, people still misinterpret their purpose.

In some ways I understand this. It's human behaviour. People think visually and so they are cognitively pre-conditioned to think that a wireframe is intended to convey design. They see the broad outline of an interface and rather than focus on perhaps the interactive elements and the mode of navigation, they think about copy and imagery and of course, colour. But here is the crux of my argument.

There is design and there is visual design - in this context the two are very different. The visual graphical layer should come much later in a product's development - it's the skin that brings a product to life but it is not the element that will define:

• What elements rest on each page
• How the navigation and link metaphor works
• How you can cross-sell content/products to users

These attributes are some of the types of things that the wireframes define. They are as equal in importance to the look and feel but theyare a completely separate element altogether.

There is often a lot of debate in the IA professional network - some think wireframes are not a part of design at all, and others fervently disagree. It's a messy area. My take has already been explained. If you search the definition of design you can plainly see that wireframes fall into the idea of "specifiying an object intended to accomplish goals in a particular environment". A technical definition that can be roughly translated as a roadmap of how something is going to interact with your users.

That's what wireframes do. By implication then they won't tell you what colour palette to use. How to brand your product visually. Nor will they tell you what colour to make the links and what treatment you will need to apply to images. That's not an information architect's job. That's a VISUAL designer's.

I am sure you, reader, know what I am on about. If you work as an information architect I am sure you have some stories of your own to share on this matter. Either way, I think this rant has cleared things up and I feel good about getting it all out in the open.

I will step down from my soapbox now.

Foregoing user testing is often because of timescales and budgets. It is often excluded from the design process because individuals within marketing or management think they know better. They make critical design decisions based on their own limited knowledge and personal preferences instead of asking the people who matter most - the customers. 

This is a massive mistake. We can’t assume that people think the way we do and we must always remember that we are not our users.  If we test prior to launch then the user experience will be always be improved. In this age of technology there’s simply no justification for not being informed by user testing. It’s a straightforward process, rarely expensive and can often be absorbed within tight timescales without impacting on delivery dates. 

So here’s what you need to know:

It’s NOT market research or UAT

User testing is not market research and it is not UAT. It is an entirely different methodology and approach.

Market research activities such as focus groups are designed to find out people’s opinions and attitudes about a product concept. They rely on the user reporting their experiences after consideration and feedback is rarely obtained from an actual product interaction. It is also different from functional testing as this does not involve real users at all. Even UAT, which may simulate typical user journey’s does not involve users and focuses more on system response to actions without consideration of the type of elements that would be explored in user testing.

When you should do it

User testing can be carried out at any stage of a design, from the initial concepts to the final product. In general, the most efficient way of carrying out user testing is to do it as early as possible in the design process, so that fundamental problems are eradicated before further design work is carried out. Then test often. Some feedback secured at the beginning of the project is great but it’s not enough. Keep validating your assumptions – even if it involves just showing it to 1-2 users.  The best approach to testing is to start early and test often, using an iterative development process of design, test, update, test – etc.

What happens during a testing session

Whether you are conducting a round of testing up to 20 users or a quick validation exercise with 1 to 2, each session should follow the same approach. You want to aim for consistency. If you don’t then you risk undermining the strength of the findings and feedback. During the sessions users will be presented with an early version of “the product”. It doesn’t have to be fully designed – user testing is still valuable if you present just a few screens - but it should give some representation of what the product is about.

Then users will be presented with task-based questions and asked to "think out loud" while they are carrying out a task. What they say reveals their assumptions or beliefs about the product or service, their goals or intentions, and any confusion or misunderstandings. Combined with observations of what the users actually do, this allows us to determine why they are having difficulties, making errors or getting stuck.

The evidence you get is objective and realistic. It is not based on personal opinion and that is the important bit. It will help you understand the users and see things from their perspective.

The nitty gritty - costs

Generally, user testing should be conducted by an external specialist agency. They are the independent party, distant from the design and client environment and so therefore able to ensure objectivity in the collected feedback. Costs vary depending on how many people you want to test and the nature of the recruit. If for example, your product is aimed at CEO level individuals, it will be more expensive to secure such participant’s involvement.

Whatever the cost, though the expense of user testing is generally far less than the cost of getting it wrong.

I’ll end this little diatribe with a common statistic, often included by usability agencies as a scary sales tactic. The scariest aspect of course is that this is largely true. Research is well worth the time and money. In the end, it always pays for itself.

“The rule of thumb…is that the cost-benefit ratio for usability is $1:$10-$100. Once a system is in development, correcting a problem costs 10 times as much as fixing the same problem in design. If the system has been released, it costs 100 times as much relative to fixing in design.” (Gilb, 1988)

​It can be difficult to find the balance when it comes to information provision - give too little and your users will become abandoned, lost in your site or product and unable to work out where to go next.

However, the same result can happen if you provide too much data or instruction. It might seem helpful at first to provide all possible permutations of advice - but actually you are creating the same sense of abandonment. It will only serve to distract rather than assist and the end result is the same - frustration and confusion.

Here's a couple of real-life examples to put that above statement in context - and yes, I did really just want to include these on a blogpost, but they do also encapsulate exactly what I have said....give too much information to a driver/pedestrian/lost tourist on a Microsoft conference in Seattle and the result is total and utter confusion.

Trust me. I've been there.

Figure 1: a traffic signpost in Seattle, as a driver I'm not
sure what's relevant, are you?

Figure 2: another example of a signpost that is targetting
cyclists, pedestrians and motorists at the same time, I think?

​It's a tough thing watching user research take place. Beyond that glass mirror sits The User, specially selected to review "your work". They look at the computer. They click through a prototype. And they verbalise feedback. Meanwhile, you, The Creator, furiously scribbles notes, recording the elements that are not resonating as well as you had hoped - and of course, the elements that just don't work at all.

It's tough but it's invaluable. The old addage of "you can't proofread your own work" rings true - you are not your audience and whilst you can try and get into their heads with personas and user journeys, user research is still needed and should form part of any project.

Now I am not saying that the following brands didn't do research - judging by some of the errors made it would be easy to assume that they bypassed it altogether - but we can assume that they either didn't incorporate the findings into development: or they chose to ignore the feedback completely. Either way, here are some examples that raised alarm bells in the user experience community.

Waitrose

It's a shame then that there recent site redesign turned out to be such a disaster, with endless articles written about it's ambiguous navigation terminology and overall poor experience. In fact it was so badly received - by both industry experts and users - that Waitrose had to publish an apology! Here are some of the highlights - or should I say lowlights:

​If you’re new to the field of user experience then welcome to this blog! Hopefully in the months to come there will
be plenty for you to see around here.

I thought it only seemed right to kick things off with a post that attempted to explain precisely what user experience is.

This is more difficult to articulate in words than you would expect.

I could say that it is simply about putting the user at the heart of the process, ensuring that technology, interface design, marketing and branding are
all aligned to ensure the best - and most intuitive - journey through a product.

...and whilst this is somewhat correct it doesn’t go far enough.

This is where diagrams come in. They serve a critical role in the UX community because...well, few of us are able to take away the ambiguity of UX definition when using words.

1. The Honeycomb

2. The Wheel

3. Emphasising importance

4. Putting the users at the heart of everything