Data is everywhere these days, every second we generate copious amounts of data and these data are mere numbers and indicators which don’t make utter sense until we make it usable. Data products help realise the data and make it usable, allowing us to take actions. For example: we may not have thought of Google maps as a data product, but if we look in detail, maps and way finding apps use GPS positions to navigate us through a busy city or find us delicious meal options nearby, all by crunching data.

If we couple data generated by multiple systems with data science and apply the user lens, we can build robust data products that can help users in their quest of reaching their goals.

The three layers of data products

Data products are broadly made of three layers. The three layers combined is what we need to build to create a usable data product. Let’s look into the layers in detail.

The first and the base layer is the data layer. Data layer is composed of raw data generated from different sources. Data layer would need to use different data collection methods to gather data. Data layer in isolation would not be useful unless you’re a data scientist or a SME with the required skills to understand the data.

If we take the map application example, the data layer would consist of the latitudinal and longitudinal co ordinates. Though the data layer is mere numbers, the data needs to be indicated by markers to be used later like the GPS coordinate is of the user or the approaching bus.

The second and the median layer is the data science layer. This layer is what makes sense out of the data that is collected. It maybe required to join the data from other sources to make meaningful data to be consumed by the last layer. Also, data collected previously need to be correlated to arrive at conclusions. We can also call this layer as data intelligence layer as it applies machine learning and artificial intelligence to assimilate data and come up with information that could be used directly.

In my experience of designing products, I worked with a retail forecaster who creates sales forecast for a big retailer in the US. The task was to create a product that aids in accurately forecasting sales with the help of AI/ML techniques. The forecaster uses traditional spreadsheets and macros to create a forecast that is 95% accurate. A forecast of 95% accuracy is considered phenomenal in the retail industry. This result also comes with the tremendous experience the forecaster possesses. When I looked into forecaster’s process, they combined data from multiple sources and applied simulations to come up with a forecast. For the forecasts to be accurate, the sales predictions need to be arrived from previous sales data correlated with the recent situations and influencing events that impact also called as the impactors.

For example the sales forecast for a period continuing a hike in prices of eggs would look similar to a period in the past when egg pricing was hiked. We also need to look at most recent data accounting for inflation and demand, cannibalisation by alternative products etc. to come up with the accurate prediction.

The third and the top layer is the user layer. This layer consists of information that the user understand and the actions or choices to make. We need to apply the user context and their behaviour to the data in order to give usable information. We also need to account for the users’ domain knowledge, their skill and their level of understanding of the data. We can call this layer as presentation layer as well since it is the layer that is visible to the user and enables them to take action. It is also important to note that this layer provides control to the user to even rectify or inform the system about data inaccuracies and corrective actions.

While I was designing the forecasting tool, I found that the forecasters use a certain type of simulations during certain days of the week and other simulations on other days. This behaviour was important because some of the simulations are necessary for the promotions to hit the retail stores on time. I presented the same information differently at varying scales to give control to the forecaster to determine the action providing them with simulations grouped together for a specific outcome. This approach when tested gave results with better accuracy and reduction in the time spent on forecasting.

While we are at this, it’s also good to note that not all data products have a presentation layer. Some could host APIs to be presented on another applications.

Role of designers in a data product

By now it would be clear that the designers’ role in a data product is not restricted only to designing the presentation layer. Designing a data product is a team effort, designers need to involved all through the layers starting from how the data is getting collected. For instance the data collection methods should not be intrusive in nature so that it becomes a hurdle in the users’ journey. Designers also need to work with the data engineers and data scientists to identify the relevant data that is to be derived and combined with other data sources to achieve the output that is meaningful for the users.

Approach to designing data products

Common design principles and methodologies work well for building data products as well. The most perfected method of Design thinking could be very well used as most of the problems solved by data products are wicked unknown-unknown problems where we don’t know the cause and impact of the problems.

Now the question comes to us, where and how to start to solve a data problem – is it yet another chicken and egg problem and we don’t know if data comes first or the user needs? In reality, data problems are user problems and the user needs come first. We need to go down from the user to the data and not the other way round to build a data product that’s usable. That’s why the best way to start with approaching a data problem is by starting with user research. I can point our readers to another article on how we can include continuous discovery in our product organisation. This applies to data product organisations as well.

A data product need not feel like one

Data products are now an integral part of our lives. We may not have considered some of the products that we use daily are actually data products because they have been designed so well that it becomes something beyond a data product for the users. So it’s a reality that the lines are getting blurred between a data product and a consumer product.

In another example of working with an Edu tech company that provides Management Information Systems (MIS) to most schools in the UK, MIS is an one stop shop for all things related to school operations. It holds all of the school data including the student profile that we were working on. One of the takeaways from the initial round of user researches is that the teachers wanted the application to not feel like a database. For us this translated into ‘Create an application that captures the student data like profile information, attendance, performance, activities, allergies, medical information, special needs etc and presents the information at the right time when we need it and in a way that we understand rather than forcing us to look at multiple places just like querying a data base’

In conclusion, a data product does not mean to have only dashboards or a series of database queries. It is much more than dashboards to help the user achieve their goals by providing them with the needed information in a way that’s understood by them.

Exploring the differences between the terms and techniques.

In my experience of running futurecasting workshops, I have seen many leaders confuse between futurecasting and futurespective. Even the most seasoned leaders are no exception to this. The major reason for this is that they are not exposed to the term futurecasting whereas futurespective is a well known exercise for many. The misunderstanding is also prevalent in certain industries compared to others. Futurespective is a known tool among the product industry and agile practitioners.

Futurecasting is fairly known in the design industry atleast among the recently graduated designers, Thanks to design curriculum of major design schools and organisations like superflux and frog actively promoting and inspiring the industry. Sadly futurecasting is considered as a technique under speculative design. My reservation against speculative design is that speculative design as a term does not instill confidence. While futurecasting is more strategic in nature, it should be considered a strategy technique.

Coming back to the original discussion on futurecasting vs futurespective. While futurecasting and futurespective are both approaches used to explore and anticipate future possibilities, but they differ in their focus and methodology. Here’s a breakdown of the key differences between the two:

1. Definition

Futurecasting: Futurecasting involves creating scenarios or projections of the future based on trends, data, and extrapolations. It aims to make predictions about potential future outcomes.

Futurespective: Futurespective is a technique that focuses on exploring and understanding the implications and consequences of current actions and decisions on future outcomes. It involves examining the present to shape future possibilities.

2. Time Orientation

Futurecasting: Futurecasting is typically focused on long-term future scenarios, ranging from a few years to several decades ahead.

Futurespective: Futurespective tends to have a shorter time orientation, focusing on the near-term future and how current actions and decisions can impact it.

3. Approach

Futurecasting: Futurecasting often involves a more speculative or imaginative approach. It may use methods like trend analysis, scenario planning, and extrapolation to generate potential future scenarios.

Futurespective: Futurespective takes a more practical and pragmatic approach. It involves examining the present situation, evaluating options, and considering the potential consequences of different courses of action.

4. Purpose

Futurecasting: The primary purpose of futurecasting is to anticipate and prepare for potential future changes, challenges, and opportunities. It helps organizations and individuals plan and strategise for the future.

Futurespective: The main purpose of futurespective is to inform decision-making in the present. By considering the potential future implications of current actions, it helps guide choices and prioritise efforts.

5. Methodology

Futurecasting: Futurecasting often involves a combination of data analysis, trend monitoring, expert opinions, and creative thinking. It may also incorporate tools like scenario planning, forecasting models, and simulations.

Futurespective: Futurespective relies on reflective thinking, critical analysis, and strategic foresight. It encourages considering multiple perspectives, conducting impact assessments, and engaging stakeholders to shape future outcomes.

In summary, futurecasting focuses on predicting and envisioning future scenarios, while futurespective emphasizes understanding the consequences of current actions on future outcomes. Futurecasting tends to have a longer time horizon and uses various methods to generate future scenarios, while futurespective is more focused on the near-term.

Simply put, futurespective is like taking an exit from a highway to reach a destination but futurecasting is like predicting the different destinations you’ll reach from different directions you would take.

Then, there is this other thing called futures thinking. It is considered the next best thing to design thinking. Hope it doesn’t get exploited just like design thinking was exploited. Futurecasting is a technique that might fall under the umbrella of futures thinking and it has all the similarities to be considered as a futures thinking approach.

What is futures thinking?

Futures thinking is an interdisciplinary approach to explore and understand possible future scenarios and developments. It involves the systematic analysis of current trends, potential challenges, and emerging opportunities to make informed predictions about what the future might hold.
Futures thinking combines the best worlds of design thinking, systems thinking and data to come up with future worlds or scenarios. Anna Roumiantseva has shared an article explaining the differences between design thinking and futures thinking and why it is necessary to combine both approaches to create futureproof products.

In the subsequent articles, I’ll share how I used futurecasting methods to help product leaders to come up with strategic directions and how we can continue to use futurecasting to come up with a compelling product vision.

Introduction to continuous discovery

Continuous discovery is an iterative and ongoing process of understanding customer needs, validating assumptions, and generating insights to inform product or service development. It involves regularly gathering feedback, conducting research, and testing ideas to ensure that the organisation remains aligned with customer expectations and market dynamics. Continuous discovery enables teams to make informed decisions, prioritise efforts, and deliver products or services that provide maximum value to users.

Rather than relying on a one-time research phase at the beginning of a project, continuous discovery emphasises the importance of ongoing learning and adaptation throughout the product development lifecycle. It recognises that customer needs and market conditions evolve over time, and organisations must continuously validate assumptions, explore new opportunities, and address emerging challenges.

We will get to understand how to practise and embrace continuous discovery in a product organisation in the upcoming sections. Before that let’s look at what it means to do continuous discovery and the benefits of doing so.

What it means to do continuous discovery

Ensuring customer satisfaction holds paramount importance for companies pursuing product-led growth, and continuous discovery stands out as a well-established approach for consistently enhancing delivered value. Renowned product expert Marty Cagen, as cited in his book “Inspired,” emphasises the significance of robust product teams conducting a minimum of 20 user research sessions each week. This underscores the need to build products with unwavering conviction and validation to ensure users receive genuine value.

According to Teresa Torres in her book Continuous discovery habits, mentions continuous discovery, is governed by two contradictory beliefs. One is that the customer is king and they know the best and the other is what Steve Jobs talks about that the customer doesn’t know what they want. She says both the statements are true to some extent.
Regarding the belief that customers don’t know what they want because they wouldn’t have seen or known what is possible. Consequently, it falls upon the product team to translate users’ wants into their genuine needs and craft innovative solutions to meet those needs.

From my standpoint, I view a product team’s collective knowledge as constrained by their known information sources, forming what I term the “cone of knowledge.” As interactions with users expand and insights accumulate, this cone of knowledge steadily widens. Marty Cagen succinctly sums up Continuous discovery as continuously discovering the product and continuously delivering the discovered product to the users, hinting at enhancing the cone of knowledge as we go building the product, all while expanding the cone of knowledge throughout the product’s development journey.

Fig.1 Cone of knowledge

The adoption of continuous discovery practices empowers organisations to mitigate the risk of developing products or services that fail to resonate with customers. It facilitates early problem identification, expedites iterative processes, and enables agile pivoting based on user feedback. Continuous discovery ultimately empowers organisations to provide solutions aligned with customer needs, elevate user satisfaction, and enhance their prospects for success in the market.

How is continuous discovery practised across organisations?

Dual track model is by far the most commonly used framework to bring in continuous discovery. The dual track model is also seen as a given for practising agile methodology. Dual track model has two tracks the first one being the discovery track which is the forerunner in identifying the opportunities followed by the delivery track which delivers the discovered value.

Fig.2 Dual track for product development

Source: Adapting Usability Investigations for Agile User-centered Design by Desiree Sy and made infamous by Jeff Patton & Marty Cagan

Jeff Patton explains it as dual track model not duel track model as both the track needs to work in parallel and not as opposing tracks. But it might happen that the team gets exhausted working on both the tracks in parallel. This needs a lot of planning so as to make the entire process seamless.

Before we get into understanding the sequence of steps needed to bring in continuous discovery, we may need to understand how discovery flows into delivery in a product life cycle.

How does discovery flow into delivery?

Just like it is important to understand how designers hand off to developers on a team, it is equally important to understand how the discovery handoff happens to the delivery track. While the delivery track starts with the delivery backlog, discovery track would start with the discovery backlog and all the activities related to delivery backlog are valid and true for the discovery backlog.

There is an important step/stage between the discovery and delivery handoffs which is the ideate/test/learn loop. While the insights from the discovery could build the larger picture, the ideate/test/learn loop gives the confidence and validation to move to the delivery phase.

Fig.3 How discovery flows into delivery

In the validation stage of ideate/test/learn loop, research insights are integrated into the design process to create user centred solutions. In this stage, designers leverage research findings to inform the creation of user personas, empathy maps, and journey maps, which guide the development of user interfaces, features, and functionalities and come up with prototypes. You can use the prototypes to further test with the users and validate the solutions. The feature list for the validated solutions can be directly added to the delivery backlog.

Continuous discovery — Our adaptation

Fig.4 Continuous discovery — Our Adaptation

Our adaptation of continuous discovery follows a simple three step process of discovery, experiment and delivery. In theory, it is an extension of the design thinking process with multiple iterations of the same exercise. We start with the large picture of the customer informed by previous research, market studies or by conducting an experience mapping activity. We will understand how the experience mapping could be used to define the initial backlog in the next section. The backlog that is created is prioritised and conducted over time to arrive at the insights and also to enrich the large picture.

The next step after arriving at insights is to create the problem statements and get into the design phase to ideate solutions. The solutions identified will be validated using prototypes to gain confidence to move to the next step of delivery. The delivery starts from the delivery backlog filled in by the validated solutions and after the build is ready it is required to test it with the users identified before releasing the product/enrichment.

It is important to note that there may be solutions that would get discarded in the process. A product team’s maturity is defined not only by the delivery of the product but also by the discarding of unusable solutions early on.

A product team’s maturity is defined not only by the delivery of the product but also by the discarding of unusable solutions early on

Understanding problems with current research practices

There is a common practice among product teams of doing a heavy weighted user research during the start of the project or towards the end. Introducing continuous research to the product teams who are not aware of the value of doing research might be a daunting task. It takes a lot of effort to show the value of meeting users and often. More complex scenario is when the team feels that they know the users very well and they don’t need research to tell them what they know.

The first step is to get away from the denial that we don’t need research to inform us. The next step is to understand the product team’s rhythm of doing user research. We may need to start by evaluating the product delivery life cycle and their current research practices. Understand what’s stopping people from meeting the customers often.

Create a checklist of gaps identified in the current process and assign owners to come up with solutions to fix the gaps. Often the gaps would be in the area of user recruitment for the user research or it can be the budget allocated for research. Assigning owners within the team to accomplish the tasks to mitigate the problem would help take off some burden of the researchers’ shoulders. This is easier said than done. Sometimes the gaps identified may be related to the ways of working of the organisation or it may be something that could be fixed by bringing a documentation process. Every gap identified needs to be handled differently considering the scenario.

Fig.5 Example of gaps identified by a research team
Source: https://blogs.gov.scot/digital/2021/07/14/making-the-most-of-user-research-findings/

While this helps in fixing the problems and operationalising continuous research within the product team, there are a few steps which a team can follow to embrace continuous research in their product lifecycle. We will look at it in the upcoming section.

Steps to implement continuous discovery in your organisation

Step 1: Creating the initial discovery backlog using experience mapping

Experience mapping is a valuable tool that helps organisations gain a deeper understanding of the customer journey and the overall user experience. Here we use the experience mapping activity to create the initial research backlog. One can use the existing research output to create the experience map or run a specific research to create the experience map.

For an experience mapping activity, it’s important to have a multidisciplinary team with diverse perspectives to ensure a holistic understanding of the customer journey and to drive effective improvements in the user experience. Typically, in most organisations, the product trio (Product manager, Designer/user researcher, Technical Lead) gets involved in the creation of an experience map.

Running an experience mapping activity involves several steps to gather insights about the customer journey and identify areas of improvement. Here’s a step-by-step guide on how to run an experience mapping activity:

Define the Objective: Clarify the purpose of the experience mapping activity. Determine what specific aspect of the customer journey or user experience you want to focus on, such as onboarding, purchase process, or customer support.

Identify Customer Segments: Identify the relevant customer segments that will participate in the experience mapping activity. Consider demographic information, user behaviours, and different user personas that represent your target audience.

Gather Data: Collect relevant data and insights about the customer journey. This can include customer feedback, user research, interviews, surveys, customer support logs, analytics data, and any other sources that provide information about the user experience.

Create an Experience Map Template: Design a visual template that represents the customer journey. Typically, this template consists of a timeline or a series of stages, such as pre-purchase, purchase, and post-purchase, this is in relation to a retail experience. Add touch points, emotions, pain points, and other relevant elements to the template.

Fig.6 Components of an Example Experience Map Template

Conduct Workshops or Interviews: Organise workshops or conduct interviews with representatives from the customer segments you identified. Provide them with the experience map template and guide them through the process of mapping their journey. Encourage participants to share their experiences, thoughts, and emotions at each stage of the journey.

Populate the Experience Map: With the input from the workshops or interviews, populate the experience map template along with the product trio. Capture the touch points, emotions, pain points, and other relevant information at each stage of the journey. Use visual elements like icons, colours, or labels to represent different aspects of the experience.

Analyse and Identify Insights: Analyse the populated experience map to identify patterns, trends, and insights. Look for recurring pain points, moments of delight, or areas where the user experience can be improved. Consider both quantitative and qualitative data to gain a holistic understanding.

We need to understand experience mapping is an ongoing process, and it’s essential to regularly update and refine the experience map as you gain more insights and make improvements. The experience map would also serve to record the large picture of the customers’ experience, their pain points, emotions and a record of the insights.

The experience mapping activity would provide a variety of output that will be valuable for the product team/organisation. The identified pain points and opportunity areas during the experience mapping activity can be directly moved to the ideation stage. However, there could be some areas which might need further research. These could be added to a discovery backlog. The discovery backlog thus created can become the starting point for the continuous discovery process. It can also happen that some product teams might have interrelation with other product teams and the research is common across the two, it is advisable to have separate tags to identify such common items.

Step 2: Create a research calendar

Creating a research calendar is an effective way to plan and organise your research activities over a specific period. It helps ensure that research efforts are well-distributed, aligned with project timelines, and cover key research objectives.

Define Research Objectives: Start by clarifying the research objectives for your project. This is preceded by the research backlog created. From the research backlog, it is needed to identify what specific research methodology needs to be employed and what questions you need answers to? What insights are you seeking to gather? Clearly define the goals and outcomes you aim to achieve in the research backlog story.

Identify Research Activities: As mentioned previously, based on the research objectives, you can identify the specific research activities that will help you gather the necessary data and insights. These activities can include user interviews, surveys, usability testing, competitive analysis, data analysis, and any other methods relevant to your research goals.

Determine Research Timeline: Consider the project timeline and determine the duration for your research calendar. Decide how much time you can allocate to each research activity and set realistic deadlines. Consider the dependencies between research activities and any milestones or deliverables that may affect the timing of your research.

Prioritise Research Activities: Assess the importance and urgency of each research activity and prioritise them accordingly. Some activities may require early-stage insights, while others can be conducted later in the project. Prioritisation ensures that you focus on the most critical research activities first.

Allocate Resources: Determine the resources required for each research activity, including the team members involved, tools or software needed, and any external support required. Ensure that you have the necessary resources in place to conduct your research effectively.

Create a Calendar: Create a calendar template that suits your needs. You can use a digital calendar tool like Google Calendar or a spreadsheet to visualise your research schedule. Include columns for dates, research activities, responsible team members, and any additional details or notes.

Schedule Research Activities: Assign specific dates and times to each research activity in your calendar. Consider factors like participant availability, project milestones, and any other scheduling constraints. Spread out the activities evenly over the designated timeline to avoid overwhelming periods of research or bottlenecks.

Communicate and Coordinate: Share the research calendar with relevant stakeholders and team members. Ensure everyone involved is aware of the research activities, their roles and responsibilities, and the overall timeline. This promotes collaboration, alignment, and effective coordination.

Flexibility and Adaptation: Remember that research calendars are not set in stone. Remain flexible and be prepared to adapt the schedule as needed. Research needs can evolve, and adjustments may be necessary based on unexpected findings or changes in project priorities.

Regularly Review and Update: Continuously review and update your research calendar throughout the project. Regularly assess the progress of your research activities, adjust timelines if required, and incorporate new insights or changes into your plan.

By creating a research calendar, you can ensure that your research efforts are structured, organised, and aligned with project goals. It helps you stay on track, manage resources effectively, and maximise the value of your research activities.

Step 3: Create a participant pool for research

Recently, we used this in one of our research projects, we realised that creating a participant pool helps in solving major bottlenecks in research recruitment. Creating a participant pool for research involves building a database or group of individuals who are willing to participate in research studies. This participant pool plays a crucial role in conducting continued, effective and efficient research. Here’s how creating a participant pool helps:

Access to Target Audience: By building a participant pool, you can ensure access to individuals who represent your target audience or user base. This allows you to gather insights from the people who are most relevant to your research objectives. Having a diverse pool of participants can help capture a range of perspectives, experiences, and preferences.

Efficient Recruitment: With a participant pool in place, you can streamline the recruitment process for research studies. Instead of starting from scratch for each study, you can reach out to the participants who have already expressed their interest and willingness to participate. This saves time, effort, and resources in recruiting new participants for every research initiative.

Faster Data Collection: Having a participant pool enables faster data collection since you have pre-qualified individuals who are ready to participate in research activities. You can quickly reach out to the pool and schedule research sessions or distribute surveys, reducing the lead time typically required for recruitment and increasing the speed of data collection.

Longitudinal Studies: Participant pools are especially valuable for longitudinal studies that require repeated interactions or follow-ups over an extended period. You can engage the same participants over time, tracking their experiences, behaviours, or opinions, which provides valuable insights into user journeys, product usage patterns, or evolving needs.

Targeted Recruitment: When you have a participant pool, you can target specific subsets of participants for different research studies. If your research focuses on a specific user segment or persona, you can select participants from the pool who match those criteria. This targeted recruitment ensures that your research captures insights from the right individuals, enhancing the relevance and accuracy of your findings.

Relationship Building: A participant pool allows you to establish relationships with participants over time. By maintaining contact with them and involving them in multiple research activities, you can build rapport and trust. Participants who feel valued and engaged are more likely to provide rich and honest insights, enhancing the quality of your research data.

Cost Efficiency: A major benefit of creating a participant pool is that it can contribute to cost efficiency in the long run. Rather than spending significant resources on ad hoc recruitment efforts for each study, you can leverage your pool of participants, reducing the need for extensive advertising or incentives. This can cause cost savings and improved research budget management over time.

Panel Management: A participant pool also provides the opportunity to manage and maintain a panel of individuals who are interested in ongoing research involvement. This panel can serve as a valuable resource for future studies, allowing for easier recruitment and engagement.

Step 4: Prioritise and conduct research iteratively

Now the final step, you are all set for the research to be conducted. You can now go about doing the usual stuff of prioritising and conducting the research continuously with the participant pool identified. It’s imperative that all the steps that are needed to manage a delivery backlog are valid for the research backlog as well. Research backlog needs to be groomed, prioritised and run iteratively. It is also important to showcase the output from a research story for the larger team to understand.

Remember, some research may not conform to the sprint timelines. They may need to be handled as individual research projects. I would expect the product team to consciously prioritise the research item with the resources at hand. At times, it is beneficial to use the help of a user research team to take up larger pieces of work outside of the product teams.The next action would be to run iterations of conducting research, design and delivery.

Running iterations of discovery, design and delivery

Running iterations of discovery, experiment, and delivery for continuous research requires a systematic and agile approach as mentioned in the previous section on how research flows into delivery. Once the research phase is complete, the design process begins. Ideas are generated, wireframes and prototypes are created, and usability testing is conducted to refine the design. The key here is to involve users at every stage and gather their feedback continuously. After iterative design improvements, the development phase kicks in. The product or feature is built, integrated with user insights, and tested rigorously. This iterative cycle doesn’t stop at launch; it continues post-launch, with ongoing monitoring, user feedback collection, and rapid adjustments as needed. This iterative approach allows teams to respond to changing user requirements, market dynamics, and technological advancements effectively, ensuring that the product remains relevant and user-centred in the long run.

Advantages of embracing continuous discovery in product teams

In summary, streamlining the research process necessitates close collaboration with product teams to align with their roadmaps. Continuous discovery is an ongoing investigation into customer behaviours and motivations, providing valuable insights for guiding product development based on validated hypotheses and discernible patterns. Integrating continuous discovery into the product life-cycle empowers organisations to create better products that effectively address the ever-evolving needs of their users.

The introduction of continuous discovery proves to be a transformative force within product teams, fundamentally reshaping how we approach innovation and user-centered design. This iterative and ongoing process significantly heightens awareness of user needs, preferences, and pain points, enabling teams to make informed decisions at every stage of product development. The regular influx of insights does not only streamline workflows but has also foster a culture of adaptability and responsiveness. As a result, products align more closely with user expectations, leading to enhanced user satisfaction and increased product success. Continuous discovery is an invaluable cornerstone, propelling teams towards excellence in delivering solutions that truly resonate with users.

Usually user research or testing is to be done at the user’s location in the place where she works/performs the action. Basically for the very reason that, users do not perform the actions or use the product in isolation, there are multiple factors that affect the users’ behavior. As user researchers, you need to read and understand the user’s body language and know where it is appropriate to probe and when. This may not be possible while you are remotely watching the user perform the actions.

While in-person user testing is not possible all the times, which may be due to multiple reasons like saving time , lesser budget for travel etc. It is better to have them conducted remotely rather than not having a user testing sprint at all. For testing products whose users are geographically dispersed, scheduling a series of online remote user testing can be preferable and far less costly than travelling and performing them. This would save not only some of your budget but also saves you time to concentrate it on building the product.

So your travel does not have to be coordinated, and you need not have to carry the testing facilities all over the globe. Further, participants can be from any geographic area rather than concentrated in one location, which makes recruiting faster and easier and all your needs sorted out by remote user testing.

Remote user testing allow the users to use their own computers for the study, letting you see how they set up their desktop (If they are willing to share), navigate between programs, and use tabs, for instance . This gives insight into how people work with their machines and also what interaction they have with other programs while they use the product. Also there are many tools that can make remote user testing as close to in-person user testing, which I would be explaining shortly. Here are a few things to consider before getting into the tools for remote user testing.

1. Create scenarios — Instead of giving the users tasks to perform, it would be better to give them scenarios. Design the scenarios in a way we can achieve multiple interactions with the product. This would also make sure that we are testing with humans not with some robot asked to perform some tasks.
2. Persona match — While designing the scenarios, make sure that the scenario is for the user persona you are testing with. Giving wrong scenario for a wrong persona would mean wrong results plus frustration for the user.
3. Mock test — Before conducting a full fledged user testing with the end users, it is better to have a round of mock user testing with team members or product owners who may not directly know the whereabouts of the system you are developing.
4. Fix a time and Calendar invite — Better to have the time fixed with the user and do send a calendar invite as reminder to avoid no shows.
5. Check audio and user access — Before getting into the user testing session, check the audio systems so that you don't miss those vital things the users say. Also check if you have better network connectivity or else might lead to users to get frustrate with you and the product. Most importantly check if the user has access to the system before hand.
6. Get users’ consent — Always let the users know what the user testing is done for and what you would be using the recordings for. Send in a consent form for the user to read and agree to it.
7. Incentivise the user— Nothing comes without a price tag, Incentivise the user to take up the test, like amazon coupons or beta licenses for the product etc. You may add it in the screener for recruiting the users.
8. Moderate it — While many people suggest unmoderated user testing for remote user testing (Selection of the method of user research also depends on what you intend to get out of it.), In my personal experience I have seen moderated user testing fetch more understandable results than unmoderated ones. It gives flexibility for the user researcher to probe when a new user behavior is spotted right then and there. But caution is to be taken not to ask leading questions to the user.
9. Win users’ confidence — A key to get desired results from the user testing is to win the users’ confidence. Users would open up and let you know answers for questions which you need not have to ask them.
10. Think aloud protocol — While the user is performing the actions, ask them to think aloud that is to talk about what they are doing. This will help you understand what the user is trying to do and why.
11. Follow up — If the user has asked some questions which you do not have answers, make sure you do follow up and answer them.
12. Feedback & Retrospect — Get feedback from the users about the session and retrospect so as to make necessary changes.

While there are many online tools for unmoderated remote user testing, for moderated user testing a simple online meeting tool like GotoMeeting is enough. Yes! you have read it right, GotoMeeting, the tool that you use daily to connect with folks around the globe is a wonderful tool for performing moderated user testing remotely. One word of caution if you have upgraded your mac to Yosemite, use only the latest version of GotoMeeting (6.4.7 or more). Otherwise the video recorded would not get converted to usable format.

You have performed the user testing, now what? The actual work of a user researcher would start only after this. You need to analyse the results, watch the user testing video over and over again, understand the users’ actions and pain points. See if there is a pattern of user behavior appearing across different users whom you have tested. It is said that you just have to user test the product with only 5 users to get a pattern of behavior.

Having heard to answers for the why’s and how’s of remote user testing. Now the question comes up when to conduct the user testing sessions? It is better to have the user testing as part of a research sprint before the actual sprint starts. This should answer open questions for the upcoming sprint and verify if the previous sprint produced a usable product. The necessary changes for the product that came from user testing can be accommodated in the upcoming sprint as well. However having guerilla user testing sessions conducted during the iterative development of the product is also good enough, just we need to make sure that the necessary changes for defects or needed enhancements that came out of user testing results are tracked and implemented.

Next I would write about research sprint and how to go about running a research sprint.