Great deck, but really hard to follow this in all environments.

 Comments | Comment

This is republished from Onward Search, where I occasionally blog. Read on.

As a UX professional, it’s almost guaranteed that you’ll be working in a consultancy or contractor capacity at some point during your career. You might work for an agency, or as a solo freelancer, or you may work your way from contract to perm. Consulting is par for the course in user experience, and it’s a great skill to have.

Joining a team as a consultant is much different than coming in as a full-time employee, and has a completely different set of inherent politics. Not everyone is fit for this role, but those that do fit will find that they excel both in consultant roles and eventually back in employee roles. Being a consultant also offers you a great deal of flexibility.

To get you started, here are some tips that I’ve picked up through my years as a consultant:

Know your role

This is harder than it seems, because it changes from one client to the next. With some clients, your role may include just improving and enhancing existing documentation. For other clients, you might provide thought-leadership as you help to define the product, including conducting research that is far and beyond what is normally considered user experience.

Remember, you are the solution to the client’s needs, even if it’s outside of your core skillset.

Baseball is a great analogy: either you’re a high-priced free agent or you’re the callup filling in during the pennant stretch. Knowing where you bat in the lineup greatly helps you judge how you should interact with the client.

Whatever that role is, act accordingly. Fill in that role and fit in with the team as much as possible. The more they like you, the longer they’ll keep you around.

Listen to your client

It’s like a usability test: ask a few questions, and let them talk. That’s why they hired you – so someone will listen to them and give them solutions to their problems. They’ll tell you about everything: how the project is off the rails, politics within the company, what they had for lunch, and so on. They’ll tell you about their weekends, their dating life – I mean everything. And that’s good, because you’ll want to take notes.

As you listen to them, not only will you get information about how they want their project run, you’ll also learn how to navigate the company culture.  You’ll make better decisions – which leads to better results.

This doesn’t mean that you should do everything that the client says.

If you think that the client is going down the wrong path with the product development, it’s okay to follow up with some research. Your job is to offer your expertise to the client. When clients don’t listen, your time might be better spent elsewhere.

Make your client look good

I’ve seen this happen a few times: a user experience consultant is brought into the project, and the first thing they do is screw over the key client contact. They talk about how they don’t know user experience and/or how poorly the project is run. They talk about how the rest of the team isn’t very good. They’ll talk about bad platform choices.

That’s the wrong way the impress a client, because there are a thousand decisions that were made before you got there. You don’t understand the context of the decisions.

Your main goal should be to do everything you can to make the client look like a star.

It means:

• Fitting in with the team
• Presenting your work as a team product
• Talking about the team they have in a very positive way
• Never, ever going above their head, even if their superiors ask questions

Your secondary job is to build a relationship with the person that brought you in – because there’s a pretty good chance they’ll bring you in again if they like you. What you want is for them to endorse you to other people within the company and/or to other companies.

For example, there’s a lot of user experience work to be had with Disney in Los Angeles. If you do a good job for one part of Disney, like Parks and Resorts, there’s a good chance you’ll get recruited to work with another division, like the Disney Channel.

Many of the consultants that work with Disney have worked there for years – just for different divisions.

Clients that feel good about the experience will tell everyone they know. Those that don’t feel good about the experience will also tell everyone they know.

Document everything

I know we’re trying to get to a lean world.

Until that changes, there will be one truth of user experience: we are in the business of deliverables.

Especially if you’re a consultant, which means establishing wireframes and personas so clean you can eat off them.

When you’re brought into a project, there’s a pretty good chance you won’t be working with the developers — they’ll come by later or will be in another country. Clients will bring in resources in phases. This isn’t the most efficient way to do things, but it is the way most projects are run, because clients view this as the most cost-effective method.

This doesn’t stop with the wireframes. Document what’s said in meetings. Document your time in tools like FreshBooks. Document change requests. Document everything.

The minute you don’t document something, there’ll be questions. It might be a meeting note, an annotation — or the worst case scenario, it’s about the bill. There’s nothing worse that arguing over a bill that isn’t documented well, and that can lead to legal issues.

Clients will question everything; if you can provide them with answers, you’re protecting yourself and the client.

Know when to walk

Repeat after me: I am not a fit for every client. I am not a fit for every client. I am not a fit for every client.  Say this several times.

You’ll know when you meet the client – or, at the latest, at the beginning of the project. There are several signs: they think that your job is to document what they want verbatim: the mantra that research is for the weak, or when you see unrealistic deadlines looming. Whatever the signs are, the best way to mitigate this is to agree to a one-month trial period to see if it’s a fit. This way, you’ll get a good idea whether or not working with the client will be successful.

A couple of years ago, I worked with an agency where I was clearly the wrong fit for the project. There were a couple of other mitigating factors (the project manager wasn’t very good his job), but the account manager and I agreed that this job was not for me, and we decided to part ways. In the end, it was the best thing for their client.

One of the best pieces of advice I can give you is this: “Choose your clients wisely.” Having great clients is better than having a bunch of nasty clients whose names you curse as you pound out their coveted documentation. This, more than anything, will determine your success as a consultant.

 Comments | Comment

 Comments | Comment

UXmatters has a great article about building a UX Services team, the qualities a team builder is looking for, and how consultants are “always on stage” when working with clients. When you work with a client, you never really get a second chance like you would in a company.

 I look for four qualities in a UX person working in services:

1. A willingness to travel up to 75% of the time
2. Having a true consultative nature. This means being comfortable talking to an hourly call center employee, then walking into a meeting with the CIO right afterward without skipping a beat.
3. Deep technical knowledge. In services, you are pretty useless as a UX person unless you not only know how to design a beautiful user experience, but actually know what it takes to build it.
4. A solid UX background. This can come from formal training or a lot of experience in the design world.

…

My success in this area stems in no small part from the fact that a client can call me up and be assured that whoever I send from my team is going to do a quality job for them. The first time I fail to deliver on that promise, I will have effectively damaged a relationship and failed to radiate within that client. Deliver poorly on a first project, and any further projects the client is doing will not include you.

Read on…

 Comments | Comment

I love user stories. I hate PRDs. And I love this blog post, because it explains why user stories are superior.

User stories don’t just communicate to engineers what they should build, they communicate why. This is a unique advantage of user stories over PRDs. Yes, there’s nothing stopping you from writing the why into your PRD. And yes, many people write bad user stories, where they forget to clearly define the actor or leave the benefit off altogether. But let’s focus on what we, as product managers, can control.

Suppose I create a great PRD. It doesn’t just explain what the engineers should build, but it provides all the requisite customer knowledge to set the context. Let’s say it ends up at 15 pages. I hand it off to my engineers. What happens?

They might read it through once. After that, they probably will refer to screenshots, or skim for relevant technical bits as they build. What do they ignore? All the reasons why.

Now let’s suppose that instead of writing a 15 page PRD, I write 50 user stories. I hand them to my engineers. What happens? They may read through the list of 50 once. That’s fine. Because what happens next, they start with the first user story and ignore the rest. But if each and every user story, communicates information about the actor, explains the desired action, and the benefit to the user, as the engineers implement each story, they have the why right there in front of them. They never lose sight of the content of why they are building what they are building.

Read on…

 Comments | Comment

When you design something, who’s time are you thinking about, your time or your user’s time?

Great post from Contents Magazine — “10 timeframes”:

You are, as a class of human beings, responsible for more pure raw time, broken into more units, than almost anyone else. You spent two years learning, focusing, exploring, but that was your time; now you are about to spend whole decades, whole centuries, of cumulative moments, of other people’s time. People using your systems, playing with your toys, fiddling with your abstractions. And I want you to ask yourself when you make things, when you prototype interactions, am I thinking about my own clock, or the user’s? Am I going to help someone make order in his or her life, or am I going to send that person to a commune in Vermont?

There is an immense opportunity—maybe it’s even a business opportunity—to look at our temporal world and think about calendars and clocks and human behavior, to think about each interaction as a specific unit, to take careful note of how we parcel out moments. Whether a mouse moving across a screen or the progress of a Facebook post through a thousand different servers, the way we value time seems to have altered, as if the earth tilted on its axis, as if the seasons are different and new.

So that is my question for all of you: What is the new calendar? What are the new seasons? The new weeks and months and decades? As a class of individuals, we make the schedule. What can we do to help others understand it?

Read on…

 Comments | Comment

Nadyne Richmond writes a wonderful blog called Go Ahead, Mac My Day. She published this post a couple of days ago, and I thought it was very relevant to the content that I push out here because of the day job. I asked her if I could republish in entirety, and she was gracious enough to give permission. Read on.

Every once in awhile, I get an unsolicited resume from someone who is in user experience and is looking for a new job.  I don’t mind this — I know that finding a job is hard, and reaching out to people who have previously said that they’re hiring for a position in your field is a perfectly reasonable thing to do.

If your resume is unsolicited, you’ve got to do an even better job than usual of telling me why I should hire you.  If I’ve posted here on my blog or on Twitter that we’re looking for a new researcher or designer, you’ve got a pretty easy opener for your email to me indicating interest and how you would fit into the team and meet the requirements laid out in the job ad. But if I haven’t posted anything like that lately, or if you’re responding to a very old post, you’ve got to work harder.

I’ve had a rash of unsolicited resumes recently.  All of them have consisted of 2 or 3 sentences asking me to consider them for a position on my team.  And I’ll be honest: I don’t even bother opening the attached resume or looking up their LinkedIn profile.  I do respond to say that we don’t currently have any openings that match the type of position they’ve told me that they’re interested in in those 2-3 sentences, but I don’t look at the resume.  If you can’t be bothered to tell me why I should hire you, I can’t be bothered to find out why I should hire you.

Writing a cover letter is hard.  It’s hard enough when it’s for an actual advertised position.  I understand that it’s doubly hard when you’re sending out a blind resume.  But if you don’t even attempt to do so, then I have no reason to consider you.

When I’m hiring, here are a few of the things that I’m looking for:

• Articulate
• Great communication skills
• Can express how their experience and expertise would fit into VMware

If you’re sending me an unsolicited resume with only a couple of sentences, you’re not meeting any of these requirements.  If you don’t meet any of these requirements, it’s not worth my time to try to dig deeper to see if you might meet other requirements.  If I don’t have a position open but I have a great candidate, there’s a lot that I can do to try to create an open headcount.  I can have a conversation with my management about why we should go to upper management or to HR to fight for a headcount.  I can make sure that they understand how awesome the candidate is and that they would add a lot to our team, and that we should try to figure out a way to make this happen.  But this is quite a lot of effort on my part, and it’s probably a lot of effort on the part of my manager too, and it’s all effort that we weren’t planning on expending.

If you’re going to essentially cold call me, you’ve got to have a very convincing story.  If we talk and have a great conversation but I don’t have a position open now, and I can’t shake loose a headcount from my VP, I’ll remember you in the future.  That means that when I do get a headcount, you’ll be one of the first people who I contact to let you know that my team has an opening that might be a good fit for you.  Without that convincing story, you won’t stick in my memory, and I’ll never remember to contact you when a relevant position does come available.

 Comments | Comment

Not such a bad idea.

 Comments | Comment