Rating:

3

Gamification seems to have been the big thing for a while. Maybe we have heard too much of it. Some would say we have been over sold on gamification, making it the wonder child that will make your websites work and attract and keep customers.

Gamification by Design – by Gabe Zichermann and Chris Cunningham is the recommended discussion seed book for UXPerth this month (April 2012). I don’t often review the books for UXPerth, unless they are amazingly outstanding or something a lot worse.

Game Design and Beyond

This book was published in 2011 so it seems to have been written late 2010. This is a telling factor on some of the examples given in the book, more on that later. As with most titles of this type it is very US centric, which really should have been looked at.

It deals with an introduction to gamification techniques, at 170 pages, it’s a quick read, even more so if you skip sections.

The book discusses aspects of loyalty generation, motivation both intrinsic and extrinsic, overall game mechanics, engagement and reinforcement techniques. Pretty much all the major techniques are covered off reasonably well.

A good quarter of the book is a developmental tutorial involving step wise (using ruby) code examples of gamification. Which I didn’t find to be that useful at all.

The final chapter is nothing more than a sponsored insert, like those brought “sponsor” talks at conferences, this was a waste of space.  Plus it dealt with badges, which are the worst aspect of gamiification.

When you read this book you aren’t really sure if you are reading a book on gamification or game design.  So many times the examples quoted where just pure games, games that people would use as distractors or time fillers rather than example of commercial sites or applications using the same techniques for commercial gain.

The case studies that I was hoping to be a core aspect of the book, seemed to be too brief or in several cases dated very quickly; such as Yahoo Answers or Quora. However the examples dating is often an issue with light weight tech books.

Maybe this is a US thing, but Yahoo Answers have never been relevant here. It just seemed overloaded with bad information, even years ago. Quora well that’s really slid into a place of all noise no information in the last year.

Also some case studies I have never heard of.. like Health Month, again I’ll assume it’s a US thing like Starbucks or the like.

A good deal of the time a found myself wanting to see the research, or the data at least, behind the bold statements on behaviour on this or that technique, now I’m sure Zichermann has them, but why aren’t they in the book.

After a while it just became a very frustrating read.

In fact if I hadn’t been using an ebook version I know I would have thrown this book across the room a good number of times.   As a UX consultant I read lot, and frankly this book although technically good,  just lacked supporting documentation. I would have normally discarded this book into the reject pile within the first few chapters.

A Word on Gamification

Maybe I’m not the best person to review this book. I’m not a current gamer. I used to be, then I discovered life is too precious to be wasted on mindless addictive games that don’t get you anywhere.

So when the authors talk about engaging people, about hooking them in with leader boards, achievements or other methods, I understand the concept, but just don’t get as to why people would be sucked in.

Sure I understand the techniques, but on a personal level what’s not to stop the person returning to the real world and abandoning this silly internal quest an app or site has set for them.

Maybe I need to see this happening with real people with some user testing.

There really has to be something in it for the user beyond stupid badges – yes I do mean Four Square – another poster child in this book.  A good deal of the good assumes it know why the techniques are working, but doesn’t show any details.

Then there is also a the ethics of all this tobe considered, with addictive gamification hooking a user into a almost gambling like habit isn’t really that ethical.  Its nice the way this book neatly sidesteps the issue. Not even referring to ethical aspect left a bitter taste in my mouth.

Being aware of ethical of nay UX manipulation of an audience is something  any UX professional needs to be aware of.

Gamification Didn’t Invent the World

Anything in the UX world that is a design pattern or now standard technique for engagement or audience retention has it seems has suddenly become a gamification aspect. For example from forum post ranking to star rating to summary control panels these are all now gamification.  Years ago in 2000 they were called community engagement.

Now I have followed, seen, used and designed  lots of these techniques as they have developed over the years, I can tell you they didn’t appear suddenly from the world of games design.

There seems to be an over zealous desire to label everything as being from “game design”  in this book.

Overall

If you are a developer or designer is this book any good?  Well yes and no.

It’s a good introduction text in relation to the techniques and what behavioural effects they are meant to have.  But I would take the examples with a grain of salt.

As a UX consultant I could have lost half the book without noticing.

It’s not a badly written book. It does show you the techniques and methods used in gamification, for that I’ve given it 3 stars. If you just want the core information, then yes this book does supply that. Some say it’s the number one book in gamification, this isn’t my view.

I have this feeling throughout the book maybe the editor should have been a little more questioning of the references than the code.

If you do buy this book, please go get the cheaper ebook. Save yourself some money.

Of late I have noticed a very disturbing trend.  Some designers no longer draw or sketch on paper.

Have we been seduced by the shiny digital world, sure low-res paper prototyping is still popular, but what of sketching.

Not pretty sketching where we aren’t focusing on the heart of the interaction issue, but real sketching where finding the solution is the focus. I’ll discount Inkling sketching as it’s still pen and paper.

We seem to have a collect of designers that just go straight for photoshop, illustrator, Balsamiq or Omnigraffle.  

We used to tell developers not to rush to start coding, to step away from the computer. In fact developers I have seen are doing this, they are sitting down any drawing out the wireframes etc on paper.

Digital is Bad.

Designers, however are rushing headlong to the computer, trembling to open Photoshop and draw some nice neat lines or the like.

Stop it!!

To make matters worse there seems to be a trend to producing the first idea out of our heads as the preliminary digital sketch.

There are a lot of things that I find very disturbing about this:

• Same Environment.

  When you sketch, away form you computer, you free yourself of the trapping of your own design, likes and dislikes and allow yourself to focus on the likes and dislikes of the audience you are designing for. It’s just a change of mental space.

• Too Precious.

  Going digital, no matter how sketchy it looks, still has an air of “time and resources” have been expended on this, it’s precious. All that time used on making it pretty, could have be used sketching another alternative.  We all know that neat and pretty leads to a biasing of a design on critique.

• Too much Fussing.

  We tend to fuss over the precision of our digital work. Sketching is about finding ideas and the journey not the end product.  It’s about finding structure, not fussing over fine details, you can look at those later. Product designs avoid the digital and detail till the end, why don’t we.

• No Accidents or Mistakes.

  Accidents can happen with pen and paper which are not seen digitally, these generate ideas. The free flowing nature of quick design generation on paper will often lead to a misplace line here and there and this will often allow you to abstract out another design direction.

• Immediate Ideas are Lost.

  Sketching is about the immediate and trying out new ideas, drawing up that interaction now before you forget it.  Doing this digitally just takes too long, no matter how good you are.

• First Design is Last Design.

  Too often the first design produced ends up as the last and only design.  With sketching you can iterate over the design, not worrying  about the outcome.

  I know sometimes the boss wants it all done digitally. Well screw them, you are being paid to come up with good designs fast, churning out the same theme of a photoshop design is not designing. Do what you are being paid for, create something new fast, on paper.

• Can’t Draw.

  Okay this shocked me. But I’m from the old school.

  As a designer it’s not a bad idea to at least be able to draw basic shapes and know how to shade. These skills you can practice and master in a few hours.  We all have atrophied pencil drawing skills.  But never let it get to the point that your can’t draw at all.

• Sketches are Messy.

  Still after doing all the right things your sketches are a mess. When you show them to your colleagues and peers they just don’t communicate the intent you want. This is an issue that a lot of people have. They just fall back to the digital world to escape it.

  Yes your initial sketches maybe a mess. That’s okay, lots of younger UX people have this issue. Don’t run away from it.

  Just practice. You could use any of the various series of UI stencils available if you like. But remember these are really just tools to assist you while your skills improve.

• Collaborative Magic is Lost.

  There is a special magic that happens when you sketch ideas in front of a client on paper.

  They will often want to draw too.  Sketching then becomes this collaborative communication tool.  This synergy you get is just priceless.  Somehow that just doesn’t work on a computer or even a tablet.

Paper is Good.

So let’s just STOP pretending to sketch on the computer, tablet, laptop, whatever.  Try going analogue for once.

1. Get some paper, a pencil or drawing pen,
2. Go sit at another desk, table or on the couch, just away from computers,
3. Put on your favourite music,
4. Go draw, sketch away,
5. Let your mind wander, try different ideas, just iterate rapidly taking the best bits from previous ideas.

You have permission to make a mess, if you boss walks in and asks what your doing, tell him you’re designing.

Don’t be precious over the ideas, just let them flow.  If it goes well you may have 10-40 ideas within an hour.

There is a wonderful aspect of “flow” that happens when you design this way.  It’s not something that you can do digitally.  Mainly because digital is just to restricted to the pixel, to perfect, to clean.

So next time you have to start a design I don’t want to see you reach for a mouse or a tablet.

Use pencil and paper, please.

Fostering even a moderate level of UX design in any team or project can at times be an impossible task.

Often there are things that we do that can stifle and sometimes even oppose UX techniques we are trying to support.

In a way, it’s as if we are by accident forcing UX people to leave or just warp back into simple pixel pushing designers or worse photoshop operators.

1. No Contact with Users

   It has been said that the opinion of a UX designer doesn’t count at all, it is the opinion of the users that are the most important element of any design.

   Not allowing contact with any users really doesn’t help in the research or evaluation process.   The entire knowledge which the design is based just becomes second hand with all the issues that are associated with this.

   Any UX design has to have users engagement, often as early as possible, in fact the more the merrier.   Stop doing this and well its not really user focused, more expert or self design.  Which is okay, however its not why a UX designer is hanging around.

2. No Collaboration

   A good deal of UX professionals tend to be very sociable people.  We often joke a good way to send us over the edge is to force us to work alone with no access to our peers.

   UX people need to collaborate, talk over concepts and ideas, if only to just confirm issues.   Working in isolation will stunt their skills and abilities over time.

   Even just being forced into a strict communication structure can be an issue, as you tend not to be allowed to discuss and talk over issues that may arise.

   It’s a little like the old “throw the design” over the wall approach.  Which sadly is still alive and well.

3. No Critiquing of Design

   The ability of have any design or idea critiqued fairly, with understanding is a great tool for the advancement of a design.

   Now I’m not talking about the usual management style of, “I don’t like that”, or “That isn’t what I’m looking for.”

   The critique needs to explain why a design is good or bad, provide evidence, or even alternatives to progress the design.   Force a UX person into the situation where they are just given no direction or not allowed to improve by having their design examined and suggestions made to improve the design. Then they are just going to stagnate and get bored.

   Don’t expect someone who is bored to stick around.

4. No Space or Time to Think

   Creativity is not about group thinking or brainstorming.

   Sure these things are good for getting some ideas on the table.

   However the real creative work happens when someone is alone, focusing on the problems, the design, the issues and playing with the outcome, examining the alternatives.

   It is then at this time that someone is designing at their best, although to the untrained eye they may appear non productive.  This is when those crazy ideas are found.  To do this they need the time and space to focus to be alone, not easy in the cubical city that modern management loves so much.

   Our obsession with having people appear productive is just plain cost ineffective.

   Having people doing mindless tasks just because we need them to appear to fill their hours of the work day is just an inefficient use of their resources.  It’s an old school industrial workhouse ethic that we just need to loose.

5. No Time to Iterate

   There is nothing worse than having the first generation of an idea or interface go into production.

   Particularly when you know that will a little more time, sometimes just a few hours, the interface could have been iterated and improved on.

   However the budgeted time is just too short so the first round of concepts becomes the final one.   I have seen this happen time and time again.  It really is very sad and everyone (except the client) knows it’s not their best work.

   In the design world being able to fix issues, correct assumptions and design mistakes is required to find the perfect design.   Design isn’t a precision art where the right interface can be found by following a formula.  It takes iterations, time to craft the perfect UI.  We have to allow for this time.

6. No Failure Allowed

   Design is very much about failure, especially UX or product based design, as you really want to fail as many times as you can and improve things as you go.   All those failures are just minor issues compared to what would happen if they were encountered after a product was released.

   So we have to find them and fail a little in the design process.  This is normal.

   It’s often not the fault of the designer as to why the product or interface fails.   After all we can’t expect every person to be masters at their craft and be able to see perfectly into the minds of the audience.

   Personalisation of failure, instead of taking it back to the fault of the design and looking for a solution, is the outcome.  We know it’s wrong, but still it continues, make mistakes in mockups or draft wireframes just isn’t allowed.

7. No Designing

   If you ‘re employing a designer, be it on contract, as a client, or in-house, the best thing you can do is let them design.

   After all isn’t that what you are paying them for.

   Just driving the design and it’s direction from a management stand point will generally get you poor results.   Think about it are you allowing people to really design or are you dictating the design to them and they are just software operators.

   Designers usually love constrains and a tricky problem, but if you restrict the playing field too much and they can’t  design, you may find they have just decided to move on.

So that’s my short list, a few things to consider, I’m sure we have all worked in those environments or unknowingly caused them.

If you have any I missed, just pop them below.

A part of Lean is Hoshin Kanri (HK). It is a form of policy development or strategic planning.

Like any good strategic planning process it deals with the mapping out of how the business can get to the desired outcome.

Translating the long term vision into manageable objectives and actions.

Hoshin Kanri is based around the idea that we are all domain experts within your own fields, and hence have something to contribute no matter where we stand in the organisation.

For it to work effectivity, senior and middle level management must be prepared to delegate some authority and trust.

It’s about participation by everyone from the CEO to the lower ranks of the organisation, providing a top down and bottom up directions of communication of measurables.

A3 Reporting

A3 Reporting is a way of implementing Hoshin Kanri, it forms the communication process.  Now don’t consider this as a top down stepped approach but a cyclic iterative approach.

Simply put a CEO will want to implement a critical business direction change based on improved customer service.  This direction change has to be backed up with research and empriical evidence, not just a gut instinct or a previous way of doing things.

If it’s the later the CEO can expect to be called out to explain why.

• The CEO outlines his request on one A3 page, this the “What” that is required. It’s distributed to the next level of management.
• The next level then considers the “what” in terms of their division and sends out various focused “what” requests to the divisions middle level management.
• In turn the middle level management send another A3 page with their specific focused “what” request.
• This continues with A3 page requestes with increasing granularity until it reaches the lowest level of the organisation.
• At this point a report on “how” the request would be done or not done or alternatives is sent on a single side of an A3 page  back up to lower management and so on.
• Management collecting and summarising the approaches as they go up the corporate structure.
• At the end of the process the CEO is presented with a single sided A3 page from each division on “How” they would implement the outcome.
• This allows the CEO to review the directions and make informed planning decisions.

The major fall back with this is the element of trust that is required up and down the communication chain and the acceptance of peoples domain expertise by management.

Traditional management and organisational structures will not like this approach as it’s not about wins and achievements on a personal level but collaborative team efforts.

The key to A3 Reporting is limiting the reporting space. It all has to happen on one side of a single A3 sheet of paper.

Some place even reduce this by having the downwards “what” in the top A4 (half) of the A3 page and the “how” on the bottom of the page.  There is no limit to how the material is displayed: text, tables figures, graphs, drawings or storyboards.

As you can see the “what” can become the goals, sub goals and objectives,  with the return being process, measurements and review points to achieve the goal.

UX usage

Application of Hoshin Kanri into the UX process is a little harder.

Communication and design discussion documentation aside, which is most of what we produce, the A3 Reporting at its core could to used in terms of restriction of the reporting process.

However the core of Hoshin Kanri is the movement up and down the structure of the translation of the long term vision.   In UX environments the movement is to almost socialistic agile teams where there is no king, no management. So this maybe an issue in adapting this.

If we take  an issue and breaking it down into components for process and then returning a solution all within a limited spacial scope that may have merits to allow us to focus on the facts and outcomes alone.  Using system cards and only allowing a solution or outcome item (say research) or the like to be expressed on a small card would simulate this somewhat.  However this is very similar to existing agile processes as well.

Mind you the entire process of Hoshin Kanri is very close to the UX cycle anyway – well kind of.

So does Hoshin Kanri or A3 Reporting have anything we can steal for UX, or are we already doing the good parts.  You tell me?

I have been interested in Lean for a while, if nothing else than to explore if any of the techniques could be stolen for use with UX and service design.   I’m only starting out on this journey about Lean, learning mainly from the local Perth Lean Meetup group.

This is the first, of hopefully a series, of short articles on what I learn from the Lean meetup.

So I expect that I’m bound to get some aspects of Lean wrong.  That’s okay I’m sure someone will correct me if I’m too far off track.

Lean and UX

It’s quite amazing that when people talk about lean you suddenly realise that a lot of the techniques are in fact unnamed technoques within UX that you just do because they make good design sense.

I guess this comes down to the way in design you are always dealing with the “thorny” issues or problems, and just except it as the norm.   Where as in business these issues are often pushed aside as to hard.

The core of Lean is stated in terms of continuous improvement as:

 Produce Quickly,  Test Quickly,  Fail Quickly
-  Repeat.

Now that’s a little too close to the UX design principles of “design, test and fail quickly”.   But this is not surprising as Lean like UX has grown by stealing what was good from its environments.

Background of Lean

Lean comes from the Toyota Production System which rolled into Lean in the 1990′s.  It’s focused on waste management with an overall goal to improve customer value.

This is achieved by using empirical (evidence based) methods to adopt various new or hypothetical ideas.   Older pre-existing ideas are not automatically considered due to pre-existing merit, but must reprove themselves.

Sound familiar? – Oh look scientific method, my old friend.

Lean is also about improving the “flow” of work or communications.  This is achieved by a Pull based processing, where waste reduction (low quality)  is looked at as a system wise consequence not focusing on the point of failure.

It’s about getting the right things in the right place at the right time, in the right quality.  This should result in the perfect “flow” for the system.

Now isn’t a lot of UX about delivery in the journey for the user.

Application of Lean

Lean is not about cutting process or documentation.   It’s not about trimming the fat.

It’s about moving the decision making process from management to the people that are informed.  Such that the decision can be made at a level which the person can control the outcome with all the respective relevant research or facts.

This can be from a design decision to the layout of your own workstation so you have logical place for everything.

Lean is used for continuous product or service improvement.  Any new services or features must be ones that a customer is willing to pay for.  If it’s not then it’s waste, then is will be simplified, integrated or eliminated.

Again note customer centric.

One interesting application of Lean is in the creative environment.   If Lean is implement correctly it will allow for an action based management approach where the only directions forward is via consideration of the Customer view with a focus on that outcome.

Focusing on the tools and not the communication, collaboration of the design will fail to produce the best design outcome.  After all good design comes from conflict and collaboration to pull the design forward.   But we already knew this, right?

Concerns

I do have one concern with Lean, it seems at this point to be a little too methodology based.  Now we know that overall methodologies don’t work in the long term, hence  we need to move to more informed design approach.

I guess it’s really about not following the process by rote, but applying the techniques to assist in the decision making process which considering the final Customer outcome.

I suppose Lean does have it’s place, at least we can steal some great ideas and reuse them, if nothing else.

Times have just got to change. I’m a little sick of living in a world that is regionalise into sales and licencing zones for no real reason besides to restrict sales due to some arcane money grubbing corporate policy.

What makes matters worse is people building experiences that highlight this and rub our face in it time and time again!

I regularly buy music online from various places, I tend to favour non DRM music, or if I can buy directly from the artist which is even better – I don’t like iTunes much at all.

Now eMusic, which I use, have recently redesigned and tweaked their user interface  towards a very strongly  recommendation engine based sales model.  Now I have no issue with this at all, in fact I applaud it as a welcome change, as it’s always good to discover new music.

It’s Very Simple

After you have signed in, eMusic knows your country of residency as it’s in your billing profile, they also know your likes, dislikes and  previous purchases.  Which is good as all this leads to a better browsing and recommendation experience.

Or so you would think.

Below is the home page of the eMusic site after I signed in.   It shows you a selection of “New and Noteworthy” albums.

Now seeing as eMusic knows so much about me, I would expect the selection to be tailored towards my tastes; and yes it is, at least a few of the albums on the home page are of interest.

However despite knowing so much about me, eMusic goes and destroys the entire experience by not allowing me to purchase ANY of the albums recommended.   Due to licensing restrictions in Australia.

Here I am, wanting to purchase an album, but I can’t.   To make matters worse eMusic decides to wave a large flag in my face, screaming, “HA HA you can’t buy this”…

Changing the Approach

Now what would it have taken to exclude the albums from being recommended.  Emusic you already know they are “Not Available” due to my being in Australia, as we can clearly see this on the screen (above).

So just exclude the items “Not Available” from the query, really it’s not that hard.  Just show me the “Available” high rated or new albums.

A recommendation is a waste of time if I can’t purchase it.

Maybe eMusic just wants me to move a few clicks away and download the music for free.

You know I try and support and do the right thing by the musicians, but sometimes the paper pushers just get in the way and destroy the experience.

The model and experience is broken, they need to change.

I have been interested in agile process for a while, especial it’s use with UX techniques.

The other day I ran into a myth that there aren’t many User Experience Design people with skills that can work on agile teams.

It seems UX people aren’t very flexible.

This I find almost laughable, in fact most UX professionals I have found are extremely flexible, often changing tack or techniques as required, at a moments notice.  Maybe we are too flexible.

The core of any agile process really is to have a role less team that can specialists with generalised skills.

Having the traditional defined roles of a Architect, Business Analysis, Project Manager and Developer is really against the principles of working as a collaborative team to achieve days tasks.

In fact what you want to have is the entire team being “T” shaped in a way.    With just deep specialisation in key areas, but still able to operate on other duties as required to get the team over the line.  Hence like the rise of the UX Developer.

Looking at this mix, maybe a User Experience Design “T” shaped person is also required.

Well it seems that “user experience” or even “design” is still a dirty word in the agile sphere.

Sadly I see this time and time again.  The UX specialist is brought in on a agile project at the end or just to correct some issues.   The consistency of maintaining the user experience is often lost as they leave.

The reason given is often that they can’t find UX people to met the team requirements when they are building the team.  Or that the user experience or requirements aren’t on the clients mind.

There is also a false belief that there aren’t any designers that can code (at least on the front end) and understand User Experience and maybe get Usability too.

Looking in the Wrong Place.

I’m calling people out on this one!  I know a lot of my freelance contacts (including me) who are UX or design based could fill any of these “missing skills” for an agile team.

The people exist, we the “T” shaped UX people are sitting around waiting.

It’s just your recruiters or  team builders that aren’t looking in the right places or asking the right questions.

Mainly this comes from the way people are recruited – along old school waterfall process – go get a BA, a Project Manager, a few Developers and maybe a tester or two.   Unless the BA and Testers are closet UX people, and it does happen, the project is going to face issues.

Which is a pity as these project could escape the usual last few sprints with the UX polishing consultant, and do it all properly from the start and save resources.

I guess that solution is for all UX people to just say they are a BA instead.

Will be very interesting to see the audience attending the upcoming Agile UX  Conference in Sydney.

As with any young industry we tend to endlessly debate the labels we should be placing on the User Experience based roles that we are conducting.

Along with this debate on the labels, we seem to be now in a blame game on who really is responsible as an industry (which I had no idea we where) for the on going career development of  junior,  mid level and senior UX people. Maybe better to just fix it folks.

As these elements of navel gazing have been going on quietly in the background the game has been changing.   Maybe For the better.

With any new discipline, well new to the main stream, it will influence other roles as elements of its workflow and techniques become widely known.

Over the last three or so years I have been noticing that there has been a  dramatic tendency to move away from the UX professional to favouring o role more like that of a senior developer or sometimes a BA with UX skills. Not that BA′s doing UX is that new, we all moonlight as BA′s when we can’t find UX work.

Let′s call them a UX developer.

It is not all that bad.

Now I know a lot of you will be a gast at this.  But just think for a moment.

To often as UX professionals we are asked to do the impossible, to be the super UX hero and save the day.

You know the scenario well.  You get a phone call asking for help with a project that is in its final stages.  All they need is a little UX magic to make the project shine.  Familiar?

Now you know it’s way to late in the project for you to have any major influence on any of the underlying flaws in the UX. But you take the gig anyway.

You do it in the  vain hope that you can at least make a little difference and hopefully the project management will learn that the time to get the UX professional involved is at day one, not before launch.

You do the best you can, but you know it’s not going to be good enough.

The watching, learning, mentoring.

Now the senior developer or BA watches and learns from you, maybe you inspire them to go and do a little professional development on UX.  Overall they pick up a few core UX skills.   Which is good.

On the next project these forward thinking devs or BA start to apply these learnt skills early in the process, so at least in part there is some element of UCD with a UX component considered.  Which again is good.

After all they are already a part of team framework – project manager, BA, dev. With someone in this team championing the UX component there is no need to inject a UX consultant into the mix, who is just going to disrupt things anyway.

Now from a project management view the injection of the UX professional just didn’t work out that well anyway. At least now the team internally now has the UX skills to move forward.

Developers control the game anyway.

Yes the UX developer does have at Cooper puts it “skin in the game”.  Yes they are concerned with optionisation of the system, to focus on the best business outcome.

However the UX consultant isn’t the only one that can deliver a non biased view that supports the user cases.   A good BA or UX developer can wear this hat as well. They can be objective they can change hats mid stream.

I have seen this more and more with recent projects.

Afterall we as UX professionals don’t control the projects, the devs do.   Now maybe we should be training and mentoring developers in the UX cause not designers. Which is opposed somewhat to what Nat Boehm has to say.

So overtime maybe the UX consultant will be as dead as the webmaster, a thing of the past.

In the future maybe consideration of the UX will be just a mainstream inclusive activity of the development team.

I don’t mind completing surveys, I even do those phone surveys.  Having working with several different marketing teams and conducted countless UX information gathering surveys over the years.  I can understand the difficulties of getting a good response from people. So I don’t mind taking the time to complete the odd survey.

Still I have to wonder sometimes if the teams behind the surveys are really understanding their audience that is completing the survey in the first place.

A few weeks back our fence was blown over in a storm.   We put in an insurance claim, it was processed, and we got the fence repaired.  No issue, good service all round.

Then I get an email request to complete a customer satisfaction survey from my insurance company.

What is Dissatisfied

The survey seems very standard. Besides being inaccessible in parts if you only use a keyboard.

All was good until we (partner and I) complete a question that asked us to rate the service from 1-10 (10 being outstanding).  We gave them a 7.   The survey responds asking why we were dissatisfied.  We weren’t.  We just rated 7/10.   Not perfect, but not dissatisfied by our ranking.   But the survey consider the rating of 7/10 as dissatisfied as it changed the questioning to suit.

This assumption, that if it’s not a 9 or 10 then the customer must be displeased, doesn’t in anyway take into account the personalised rating scale of the customer.   We may never give a score of 10 or 1.  We could be very happy with a score of 7/10, as we were.

Lesson to be learnt here is that you can’t assume that a 7/10 or even 6/1o indicates a negative emotion or dissatisfaction from the customer.   This type of survey  gleans towards a negative bias or an over inflated towards the extreme positive.

Now that was a minor issue compared to the next one.

Doing the Likert Scale

The presentation of a Likert scale question is never easy.  A UX professionals we are always looking for a new way to present a question or interface without promoting any bias.

However when we were presented with the following question.  We both starred at the screen for a good minute before we could jointly work out what was required.

What you are meant to do, and it took us a few goes to work this out, is drag the card (on the left) to the response boxes (on the right) and drop them there.  They then appear as a box with text in within the response area.

There are a number of issue with this interaction:

• It’s very different to the traditional layout, it was completely outside what we were expecting.
• Initially you can read the page question as “How would you rate your experience in terms of:” Answer – “Extremely, Very, Reasonably…”
• You may ignore the small help text “Please drag each item to a category”
• You may ignore that card completely
• There is no indication as to what an “item is” or what a  ”category is”, they mean the card or questions and the possible answers (on the right).
• The process of reviewing or moving categories isn’t as smooth as it could be.
• There is bias to dragging the cards (items) to the responses (categories) at the top of the page.
• It’s only usable with a pointing device.
• I just don’t even want to think about the accessibility of this.
• I still don’t know what the “+” buttons on the responses do.

Yes it’s fine when you workout what to do. But most people aren’t they concerned about the survey and are likely to leave if the question layout breaks a mental model.

Overall it just seems to be a fancy “cool” javascript insert, that frankly should have been killed off or tweaked to make it usable.

This is a classic example of a new interaction technique not being the best delivery method.  Sometimes the cool tech is just not the best way.

Now the concept is still valid, but it just needs a little more refinement, and maybe a little proper user testing and it would be an innovative interface.

Still sometimes I do wonder if these insurance firms employ anyone to consider the user experience of their customers.

I get asked this a lot. “What are the best UX books to read?”

In true UX tradition my answer is depends.

It depends on your experience as a UX practitioner, your experience with scientific research methods, psychology, interaction design, user interface design, product or visual design and your level of communication skills.

Still having a list of starter books would be handy.

Yeah sure others have their lists from the likes of Will Evans, Paul Seys and Nick Finck however some of the books on these are either too complex (for someone new to UX) or take way to long to get to the point. Bit like this post.

So here is a list of books I would pick as the must read UX books.

The UX Book List

• The Elements of User Experience: User-Centered Design for the Web by Jesse James Garrett
• A Project Guide to UX: For user experience designers in the field or in the making by Russ Unger and Carolyn Chandler
• Undercover User Experience Design by Cennydd Bowle, James Box
• Thoughts on Interaction Design by Jon Kolko
• Designing the Obvious: A Common Sense Approach to Web Application Design by Robert Hoekman Jr.
• The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper
• A Practical Guide to Information Architecture by Donna Spencer
• 100 Things Every Designer Needs to Know About People: What Makes Them Tick?  by Susan Weinschenk
• Simple and Usable Web, Mobile, and Interaction Design by Giles Colborne
• Measuring User Experience by Thomas Tullis, William Albert
• Understanding Comics: The Invisible Art  by Scott McCloud
• Business Model Generation by Alexander Osterwalder

More Specific Methods and Techniques Tuning

• Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests by Jeffrey Rubin, Dana Chisnell
• Designing with the Mind in Mind: Simple Guide to Understanding User Interface Design Rules by Jeff Johnson
• Web Form Design by Luke Wroblewski
• Mental Models: Aligning Design Strategy with Human Behavior by Indy Young
• Card Sorting: Design Usable Categories by Donna Spencer
• Prototyping: A Practitioners Guide to Prototyping by Todd Zaki Warfel
• Search Patterns: Design for Discovery by Peter Morville, Jeffery Callender
• Communicating Design: Developing Web Site Documentation for Design and Planning by Dan Brown
• The Essential Persona Lifecycle: Your Guide to Building and Using Personas  by John Pruitt , Tamara Adlin
• Information Architecture for the World Wide Web  by Louis Rosenfel, Peter Morville
• Designing Social Interfaces by Christian Crumlish
• Tales of the Field: On Writing Ethnography by John Van Maanen
• Remote Research by Nate Bolt,  Tony Tulathimutte
• Content Strategy for the Web by Kristina Halvorson
• Storytelling for User Experience by Whitney Quesenbery, Kevin Brooks

Let’s Get a Lot Deeper and Serious

• The Myths of Innovation by Scott Berkun
• The Design of Everyday Things by Don Norman
• Heuristics and Biases by Thomas Gilovich
• Design Meets Disability by Graham Pullin
• The Accidental Taxonomist by Heather Hedden
• Doing Anthropology in Consumer Research by Patricia L. Sunderland, Rita M. Denny
• How the Mind Works by Steven Pinker
• The Back of the Napkin: Solving Problems and Selling Ideas with Pictures by Dan Roam
• Predictably Irrational: The Hidden Forces That Shape Our Decisions by Dan Ariely
• Living with Complexity by Don Norman

So what are your killer must have UX books, I’m sure they are few that are different to the list above.