One of my favourite user experience quotations comes from user researcher Harry Brignull, where he writes: "A researcher who is keen to please the design team is useless."

One reason I like this quotation is that it makes the point that as a user researcher you are like the grit in the oyster. In the same way that the grit irritates the oyster into growing a pearl, the user researcher is continually finding problems. These might be problems with the initial design concept, problems with later designs or even problems with the fundamental purpose of the product. Your role is not to please the development team but to push them to do better work by understanding users. 

There's an obvious risk with this however — the irritation can be taken too far. When you start a new job, it's important not to appear like a know-it-all smarty pants and be overly critical of what has gone before. After all, you are not yet aware of the constraints the development team is under. Perhaps some of those 'bad' decisions were in fact the 'least worst' decisions that could be made in the circumstances.

So you've started a new job. How can you irritate your colleagues and still stay friends with them after work?

Week 1: Map the territory

As a user researcher you will interact with everyone on the development team and many people beyond. Part of your job is to connect these people and create a shared understanding of users and their goals. Think of yourself as the glue that makes a good user experience happen. A good way to achieve this is to get all of your colleagues involved in user research, both by observing and taking part in research sessions. And if you've just started the job, this means spending time getting to know people and allowing them to get to know you.

So an effective way to spend your first week is by mapping the territory. What is the product about? Where does it sit in relation to other products? Who makes decisions and whose opinions matter?

You can get this information through informal interviews and meetings. You may need to schedule some of these, especially with the busier members of your development team. But not all of these need to be formal: conversations over coffee or lunch, water cooler conversations or corridor meetings will all work.

Your aims in this week are to:

• Understand the constraints the team is under. What can and can't be done with the technology? What's driving the timeline?
• Get to know your team members. What is their understanding of UX and usability? Have they met users in the past or observed any user research activities? How do they rate the importance of user experience to the product? What is their definition of success — both for the product and in terms of what they want from "user experience"?
• Identify the stakeholders. Go beyond the development team and identify people in the organisation who can make your project succeed or fail.
• Uncover the important business metrics. Hint: "important business metrics" usually include a currency sign, whether it's about making more money or reducing costs.
• Take lunch / coffee with your colleagues but try not to do this with the same people everyday. You need to avoid becoming part of an internal clique.
• Warn people that you need 2hrs of their time for a workshop next week (more of that later). Get it in their diary.
• If you can't prototype, find someone on the development team who can. They are soon to become your best friend.
• Based on what you've learnt, estimate the team's UX maturity.

Week 2: Help your team understand their users

Your most important responsibility as a user researcher is to help your team better understand their users. The team need to appreciate that there are different groups of users, that some of these groups are more important than others, and that one, or maybe two, of these groups will be the design target. Then you need to help the team gain an in-depth understanding of their users' goals, motivations and abilities.

Your aims in this week are to:

• Start compiling the research that has been done with users in the past. This could be research done by the team or organisation or by external researchers, such as universities.
• Run a workshop with the team and get them to create assumption personas. It doesn't matter if these are totally wrong. This exercise is a gentle way of helping the development team realise they are not the user (as well as helping you discover things about users that you may not know about).
• Use this workshop to try to gain some understanding of the users' environments too: for example, which devices do they most commonly use?
• Build a research wall. Claim a whiteboard and start to make your work visible. Put the assumption personas on this wall.
• If there's time and budget, spend 1-2 days this week visiting a handful of users in context.
• If there's little time or a tiny budget, spend a day doing guerrilla research.
• If there's no time or budget for user research, consider moving to another job. In the mean time, read over existing research and analyse any user data that's available (like web analytics or call centre data).

Week 3: Help your team understand their users' tasks

Tasks are the activities that users do with a product in order to achieve their goals. Helping the team think in terms of users' tasks, rather than system functions, is an important step in getting the team to see the big picture. This is because users' tasks almost always require the use of several functions to complete, so it prevents siloed thinking.

Your goal this week is to identify the red routes or top tasks that users carry out with your product. This prevents the team from treating every function as equally important and helps prioritise development.

Your aims in this week are to:

• Speak to team members and create a list of all possible tasks. Then get the team to identify what they think are users' top 10 tasks.
• Take your list of tasks and show it to users. Ask users to prioritise these tasks. You could do this either as part of a field visit to users or by distributing a top tasks survey to a subset of your audience.
• Compare and contrast the task importance rankings made by the development team with the rankings made by users. The more similar the rankings, the better your team understand their users.
• Turn the top handful of tasks (as rated by users) into usability test scenarios.

Week 4: Run a usability test

Running a usability test is always a good early activity to do when you join a new development team because it will help you flush out the influential stakeholders and gauge their attitude to involving users in your work. It will also give you an idea of the budget that's available: is there a usability lab, or are you allowed you hire one? If not, can you do remote, moderated usability testing? Or are you restricted to guerrilla, 'pop-up' usability tests in coffee shops?

In terms of what you should usability test:

• Test the current product or prototype — or if there's no product yet, test the top competitor with around 5 users.
• If the budget is small, do one remote, moderated session then do a handful of remote, unmoderated tests.
• If there's no budget, run a usability test with friends and family.

Your aims in this week are to:

• Get the team to observe at least one session, preferably live. If that's not possible, get each team member to review one of the session videos. And if that's not possible, create a highlights reel illustrating the main findings and present this in a show and tell.
• Involve the team in the analysis of the usability problems. First, get each team member to identify problems from the session they observed. Then, as a group, carry out an affinity sort to combine similar observations and decide which problems to fix first.
• Plan the next quarter: if there are gaps around understanding users and tasks, then consider a field visit. If you need a prototype, plan that. And if your organisation doesn't want you to involve users at all, consider looking for another job.

Parting thoughts

When starting a new UX job, people tend to ask themselves (often implicitly): "How are things done around here?" Then most people, over time, fall into step, or adjust their working practices to fit in — thereby negating the whole point of their being hired in the first place (since you are generally hired for what you can bring to the party — not because you can replicate what the organisation is already doing).

On the other hand, to charge in and try to change things too quickly is a sure fire way to make your team hate you. You need to walk a fine line between irritating your new colleagues and challenging them to become more user centred. Try some of the ideas in this article to see if you can get the development team to create a few pearls.