This article will focus on how we worked together on a project. This project's goal was to figure out what a new way for our customers to work could look like. We won’t be providing specific details, but we'll cover how we collaborated. This case study should give you ideas on how to research something that doesn't exist. It'll give you ideas on how we collaborated well together as a Product Manager and UX Researcher. This article is packed with information, so there will be a follow-up article with lessons learned from each of our perspectives, and the outcomes of the project.

If you find this interesting, helpful or want to give a hint to your collaborators, share this article.

Share

If you’re not yet a subscriber you might be missing out.

Source: XKCD

Project Faster Horses 🐎

This project was focused on looking into introducing a paradigm shift. It would be a completely different way of thinking and working for our users. As a result, we had to draw inferences about what our customers needed. Asking customers what they want for a concept that did not exist as a project challenge.

How can you ask someone if they would like or need something if they are very entrenched with how your product currently works?

Asking someone if they want something is like outsourcing your work. It’s the product development team’s job to figure it out based on needs, behaviour, hacks and other data.

There is the alleged Henry Ford quote around if you ask what people want they will ask for “faster horses”.

To sum it up our challenges were - 

• Validating an entirely new concept with our customer base. They are very accustomed to the current product. Customers are less likely to think about a new way of working if they are very familiar with our product. Many have a mature and highly embedded setup based on our current product features. If they were thinking about this new way of working, they would either be using a substitute product either wholly or partially.

• This new concept could change how our organisation thinks about and organises its services. there’s a potential to have a big impact on the corporate strategy and other products.

• Working on a high visibility project with multiple stakeholders, with their own opinions.

Project team - essential cast and supporting crew

Direct team members: User Researcher, Product Manager, Product Design

Supporting team members: Engineering 

How we kicked off the project - with a lot of debate and discussion

Establishing early who does what

This is important, particularly when involving a UX Researcher and a Development team. Sometimes there’s an expectation that a research project can be handed over to a UX Researcher completely. We were lucky to have an active stakeholder group. The team understood that knowledge can be and should be gained as the project progresses. There were no surprises when the research report was completed. All insights were actively carried and recalled throughout the project by the team.

Having a clear goal for the project

The project could have gone in many directions - we could have validated a hypothesis early and gone narrow prematurely. Opportunities for making something really innovating would have been limited.

Ultimately we wanted to use the time and effort to capture existing behaviour, needs and workarounds which give us an indicator of needs.

Have a clear prioritised list of hypotheses and user personas

These drove how we ran the project, including methodology and recruitment. This step is so essential. If we are not aligned on who the ideal customer is, we could be collecting data from the wrong set of customers. Recruiting incorrectly would increase the likelihood of the research being disregarded.

Method

Choosing the method was an interesting discussion. We wanted to spend time assessing needs and introducing a new concept. Communicating the idea would be a challenge. Surveys and user interviews, the most popular methods of user research would not work.

As a project team, we analysed the pros and cons of the methods against our goal. We narrowed down on the Storyboard method because the concept was new. We could introduce an idea by showing the overall experience whilst having our customers discuss what would work and what wouldn’t. The good thing about this method was it left a lot of room for our customers. They wouldn’t be shown a very narrow concept or design to give us feedback. This would be vague enough for customers to infer their own needs. For tools, we used Miro to map out the concept and flow.

How we actually worked together

Divide and conquer

It was very clear who did what. In every session we had someone running the session, note-taking and an extra person.

Different perspectives - each member of the team was focused on a different aspect

Having 2-3 team members participate in sessions meant that those perspectives were balanced out.

Utilising each team member's strengths

We had a team member who spoke Mandarin Chinese and a customer who only felt comfortable conversing in Mandarin. We had that team member run the session with an Engineer who was also bilingual.

Synthesising/processing/reflecting on feedback together

We made sure we had multiple people involved in either transcribing or on the go analysis. An added bonus that helped the project wrap up in a timely manner.

Using the same set of tools and consistent documentation

We purposely set up things in a very streamlined and structured manner. No matter who met the customer, the interview questions were very standardised and note-taking methods were agreed upon. The analysis was done right after the sessions with some fixed and agreed upon keywords using a spreadsheet.

Thanks to the setup, we had flexibility to use the same set of information in different ways

For example the design team could use it to drive design specific decisions. We were also able to extract the data and real quotes to be attached to a customer journey map.

We recruited a diverse set of global customers

We made sure to go beyond our timezone and customers who only spoke English to get a truly international perspective. The goal was to have a global product so we should involve global customers. We didn’t want to get caught up with a specific regional point of view that may not reflect average users or needs.

Everyone in the core team tried to attend every interview

It would ensure that we hear the feedback directly. 

We would try to record the interview if we had permission from the user

One of us would be the note taker. At the end of every session, we would spend 30 mins debriefing and synthesising the feedback. 

So, what happened to the project 🐎? We will share more in our next article. Make sure to subscribe so you don’t miss it.

Thank you for reading the article! You can help us:

• Subscribe using this button

• Share this directly with your peers and others who will find this helpful

Share

• Share this article on your Social Media (Twitter (we’re @readaskwhy), LinkedIn)

• Suggest topics or questions in the comments