User research is a team sport as many user research teams – particularly those working in agile development teams, such as the GDS User research team – have discovered. This discovery is perhaps due to the growing realisation that user research in the agile software development cycle has the greatest impact when it isn’t ‘owned’ solely by the user researcher or the user experience team.

At Redgate , although user experience (UX) is everybody’s business, there are still times when project teams (usually consisting of developers, testers, a project manager and a product manager) tend to see user experience as being ‘owned’ by the UX folks.

In my role as a usability engineer, I’ve often been consulted by various members of project teams to create personas, conduct UX tests, create surveys, etc. In other words, any activity which has to do with research to discover user wants and needs. While in the past all this love made me feel special and wanted, it still hid the fact that the project team thought that these activities were not something they could or should do.

They aren’t necessarily wrong to assume this, given that there are a plethora of techniques and methods in a user researcher’s tool kit, and each tool needs to be used at a particular time and in a specific way.  It can be quite an intimidating venture to go on! Also, realistically speaking, members of the team have their own workloads to keep up with.

However, the unfortunate outcome of this notion is that it may put project teams off from doing more user research, especially when there aren’t too many user researchers going around. The obvious solution would be to employ more user researchers but that takes a lot of time and a lot of effort.

         A more pragmatic and long-term approach would be to involve the development team in user research activities.

The benefits of this immersive approach is echoed in an interesting article by Jared Spool, ‘Fast path to great UX’, where he describes increased exposure hours by a development team as the silver bullet for creating awesome user experiences.

I’d like to share my experiences of making user research a team sport and the benefits of doing research collaboratively.

Making user research a team sport

At Redgate, I have involved the development team in my work by not only inviting them to attend various user research activities, but by also getting the team involved in the entire process of user research. For example, planning research, conducting various activities, and even analysing data. The process of user research truly becomes a team sport, and there are some great benefits as a result. Collaboration allows us to open up the problem space. It allows participating members to examine the problem with various lenses, and explore it in ways that wouldn’t be possible when working alone. Even better, it allows us to come up with different solutions by giving the whole team a platform to voice opinions and, ultimately, to collectively come up with a solution.

The key is to have frequent yet light interaction with the team.

Using gamestorming techniques to help facilitate the process, I have involved various members of the project team in activities such as creating surveys and questionnaires, remote usability testing and site visits. Their involvement was not limited to merely reviewing material, but rather they were directly involved in actually generating questions to be included in research material. Also, when conducting user interviews or remote usability evaluation sessions, I have had project members attend sessions to help ask questions and take notes which were then collectively discussed and analysed.  The key goal in all this has been to constantly look for opportunities to actively involve team members in the entire process of user research.

How to be collaborative?

There are several ways to be more collaborative, and they range from being simple and almost mundane (e.g. having a traditional meeting), to highly active, participatory sessions with a sense of play, as seen with the methods described in Sunni Brown’s gamestorming.

The key is to have frequent yet light interaction with the team. In my experience of making user research collaborative, I have found that there are some key aspects to collaboration that help facilitate the process irrespective of the medium used to collaborate:

  • Making work visible and easily accessible by using post-its, posters, or whatever your team prefers to track work in the open. Even work-in-process can be made visible to the entire team. Using collaborative tools such as Google documents to create material is another simple way to involve the team.
  • Having a competent facilitator (hopefully someone with experience), especially when involving team members in activities that use collaborative games/techniques to help guide the group effectively.
  • Mutual participation by all team members is key. Without the shared commitment to participate, a collaborative exercise soon becomes a waste of time.

 What did I learn from being collaborative?

By approaching user research as a collaborative exercise, and as a member of the team, I experienced several advantages:

  • A shared sense of ownership, as everyone in the team is involved in the entire process, and their opinion was valued.
  • Increased communication during the process, and we knew we had a platform to share disagreements openly.
  • A shared understanding of the data we gathered and analysed together.
  • Reduced bias when preparing, carrying out, and analysing data.
  • More robust research, thanks to our collective perseverance at being more collaborative. On the whole, we felt a lot more confident of our research process due to the number of times work was reviewed by various people in the team.

I have found that most aspects of conducting user research lend themselves quite easily to being a collaborative exercise, but there are still some aspects which are best done alone. Data analysis, in particular, was an exercise that was better done when working alone since the nature of the task itself requires a great amount of reflection. However, it can still have some amount of collaboration by involving one or two other people to help bounce off ideas and review findings.

I have found that collaborating with project teams while doing user research has helped the team appreciate user research more and also helped me be a much better researcher. User research really doesn’t need to be solely owned by a user researcher or the user experience team and it is indeed best done when done as a team!

What have you learnt from your experiences of making user research a collaborative effort? I’d love to hear your stories, the good the bad and the ugly! Feel free to comment or tweet me @revnathaniel.

Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Related posts

Also in UX Design

Sometimes, you don't need UserVoice to give users a voice

Several years ago I was introduced to UserVoice, the online forum that enables direct contact with users, allowing you to collect their feedback and build the features they vote for. At the time I had...

Also about Collaboration

Infographics: communications on steroids

I am eager to share with you some of the challenges my team faced in the last few months and how infographics helped us to solve them, optimize our internal communications, and ultimately increase o...

Also about teamwork

Architectural Principles of a DevOps Team

Trying to tame complexity

Over the last few years my team ("DevOps" - the name's not entirely accurate, but close enough) have been putting together a handful of charter-like documents that we can ...

Also about User Experience

Time to talk accessibility

We have a few of these clocks dotted around Redgate and I find them difficult to read, while impossible to read from across a room. They look stylish - minimalist and simple, but are far from being ...

Also about User research

What SQL Lighthouse beta, spaghetti sauce and The Mom Test have shown us about ways to deploy database changes

Spaghetti sauce and variation

Note: SQL Lighthouse is now called DLM Dashboard. 

There’s no one-size-fits-all answer to the challenge of implementing an automated database deployment pipeline. Th...

  • Matt

    I have found that involving all disciplines in the bigger picture of the project, from the outset, creates a far greater sense of ownership.
    OK, my specialty is web development, but if I understand WHY the other teams feed back to me with the changes they do, I can begin to second-guess them. I can move towards making my work better, by understanding their view-point and empathising with it when I first shape my code, rather than having the substance over style argument that “back-room” techies sometimes have with non-techies.