1. There's an unbalanced focus on the "shiny" and not the finished product

Let's face it, the days of hordes of web professionals walking in with black turtlenecks talking about how we are creating "immersible experiences" that don't relate to a return on investment are over.

Many user experience consultants, however, are still focusing on shiny presentations with pretty wireframes without the knowledge to back up their reasoning. They drive up in the fast cars and present fast wireframes in slick presentation folders. They wave their hands around, doing their best impression of Steve Jobs.

There's only one Steve Jobs, and even his opinion on products changes as he sees them evolve. Software and web projects should do the same over time. Companies are expecting well-reasoned solutions that will translate to their bottom line,  improve their brand and will evolve over time.

The Bottom Line:
Great looking wireframes are just that, if there's no depth.

I would almost say never trust a user experience consultant that delivers perfect wireframes. During the process of many projects, wireframes are used as communication tools and should never match the finished product. The real judge of a user experience consultant is the final result: how did the client benefit. If the consultant can't answer this, shiny is useless.

2. The consultant user experience process starts with wireframes.

The ad is posted, the user experience consultant is hired, and there is no discovery process. Within one day, there's a set of wireframes that describes a home page, inside pages, and a few other random pages that are a loose collection of detail and sketches. While it's enough to get the developers started, it becomes clear that the initial wireframes assume a target that does not exist.

It's like designing a house without asking the key questions like how many rooms the house is going to have, how many stories to design for, or even where the house is going to built.

Or – would you build a car without knowing who you're building a car for?

The Bottom Line:
Establish the business and user goals.

It doesn't have to be a very exhaustive process (and shouldn't be in some agile environments), but there should be a target with which to start. One project I worked on, we had a single set of two personas, and from the very outset, it helped the developers identify with the target users. We may have been wrong to begin with, but any project is a journey, not a destination.

3. When asked why something is designed a certain way, many answers are “because.”

The wireframes are being developed, handed over to the developers and turned into something real. Yet, nothing makes sense. After a few sprints, it becomes evident that design decisions made do not make sense; yet when the user experience consultant is asked about why they made those decisions or designed the functionality in a certain way, there is very little critical thought or data to back them up.

A lot of poor design decisions by user experience professionals begin with the usual: "Well, we've always done it this way" or "The last project I did was designed this way." While using patterns from previous project or two is a good place to start…

The Bottom Line:
"Because" isn't good enough.

There should be design patterns, established processes used from other sites or at the very least, guerilla usability studies behind the wireframes that are given to the developers. Design patterns I have used in previous projects are based on established best practices, success of previous projects, or based on real data. Even then, "because of this" may change due to user testing and initial results.

4. Their resume has a list of brands, but they don’t know where the offices are.

One of the oldest tricks in the book: web and graphic designers altering a single graphic or one line of text in the site and claiming credit for the project. It could be even how they presented a single idea to a client, and the resulting claim was how they personally changed the way that company did business. Think of those wonderful Windows 7 commercials in a professional environment.

More examples:
One user experience consultant I know of has never even been to some of the companies she has on her resume, or worked with them whatsoever. Another designer I know took credit for a project where he was one of nine designers.

The Bottom Line:
Ask them to explain what was accomplished for the client.

Whatever documents the user experience consultant has in his portfolio, he should be able to explain in detail what he did, what methodology he followed, and what the result was. The user experience consultant might not have all the pieces, but even if the site was changed he could ascertain why it was changed.

Most large projects should have teams of professionals on them, and I've personally been up front about this on projects I've worked on. Other professionals should do the same when explaining their background.

5. They can't explain the user experience process, other than calling out Cooper or Garrett.

There are a lot of user experience books out there, and many of them make fine reading on cross country flights (I read a Cooper book on a flight I was on recently, and a Tog book before that). However, they are a starting point.

Some user experience consultants follow a certain school or process, bringing up the "this person said this" or "this person said that" approach of reasoning, as if that person is the sole reason why users act a certain way.   Blanket statements like "this technology is bad" don't take into account the context of the application.

The reality is that each project is different and the author isn't the one on the project. User experience professionals have the challenge of adapting to the environment they were working and should act accordingly.

The Bottom Line:
The reason to know the rules is to know when the break them.

The best document I've used with my clients is a modified Gantt chart that shows not only the user experience process but a complete software development lifecycle as a whole. When I sit down with the client, I talk about elements of the process as an example, and then highlight process steps that may not apply.

6. They make the process more complicated than it needs to be.

A friend of mine ran into this when working in her organization. A fellow member of the team said there was this certain tagging process to follow, directly copied from a blog post off a prominent user experience site. The issue: the tagging process would have dramatically lengthened doing work within their environment, requiring much more work to perform the same amount of tasks.

It’s dangerous enough to copy posts from blog entries when there’s no context, but even worse when the post advocates a process that is ill-suited to the group at hand. Most of those processes are designed to be used in academic or enterprise environments, which obviously doesn’t work well for a team of ten.

Before using any method or process, there has to be a careful look at what you’re asking for before you jump into it.

The Bottom Line:
Do just enough user experience gathering to keep the process going.

I’ve done the full-on user experience process, but on one project I worked on, the wireframes consisted of sketches performed on print outs for A/B testing. The tools of user experience are communication tools to an end goal, and nothing else. If the user experience expert does not agree with that, then it’s really time to look for a new one.