One of the most important mindset shifts that needs to occur during scoping is understanding that neither product owners or product designers are the end user. Both product owners and product designers naturally have in-depth knowledge about the application, but making the assumption that this knowledge is shared by the target user can seriously affect that user's experience.
In addition, whilst during scoping we want to discuss our opinions and insight, it's crucial to validate all of these conversation points with information from the end user. One of the consequences of not user testing is simply creating a product that the target market doesn't respond to, because the product in question doesn't meet their needs. Often, this situation arises because the people most directly involved in the app creation process did not spend enough time getting to know the end user.
User interviews
User interviews are essential for getting an understanding of the thoughts, feelings and motivations of the target user. For a successful interview, it's useful to set a few goals about what you want to learn and how those learnings will affect the rest of scoping. At WorkingMouse we typically scope against a problem statement which provides a concise summary of the essential issue to be resolved by the app. This assists us in collecting data which is relevant to that problem. User interviews can be conducted with a panel of users supplied by the product owner (for example, the CEO of a company allowing some of their employees to answer questions about an existing process), or a group of anonymous interviewees who are called in.
When it comes to these anonymous groups of users, there are two things that need to happen beforehand. First, the product owner and designers must agree on the target demographics for the end user. Next, the method for calling in these anonymous participants must be devised. Generally, if this is the desired route, a third-party service which specialises in this sort of user testing would need to be contacted so that they can vet the participants.
User interviews, contrary to popular belief, do not need large sample sizes to be successful. Five interviews per study is often sufficient. The key thing to remember is that user interviews should not just be undertaken once. These studies should repeat often with different sample groups. It's not so much about the quantity of data extracted at once, but the consistency of data gathered over time, as well as the analysis of the UX researchers.
User testing
User testing involves sending group of participants either a prototype or a functional version of the application. The participants are then asked to complete a series of tasks using the prototype or app. For example, if you were the owner of an e-commerce website, you probably would want to test how intuitively your users could navigate search results, add items to their cart and proceed to checkout without any distractions. User testing can be conducted in person, with the product designer acting as the invigilator as the user carries out the tasks, or remotely. In this latter case, users will simply run through the list of tasks provided to them and provide feedback using a form, survey or similar. It is often quite useful to record the test so that the footage of a user journey in action can be reviewed at a later date.
As with user interviews, a product owner may decide to test with a panel of current users or an anonymous group that match the target demographics. Both sample groups have their advantages and disadvantages. Anonymous panels tend to provide more 'raw' feedback, because these users might not have ever encountered the application or product previously. On the other hand, because they are not current users or have not been identified as current or first users, they might not be as representative of the target market. If possible, it is good to test with both groups to validate assumptions and identify outlier opinions. Unlike with user interviews, user testing can be conducted with larger groups and because they are less intensive than user interviews, they are easier to schedule in at any time.
