7 things I’ve learned about building User Groups
The system was starting to show some promise when, for unrelated business reasons, we were forced to put the entire project on hold. For this reason, we were unable to continue process iteration, but I look forward to refining this process on future projects.
Over the course of this adventure, though, there are several things that I’ve learned:
1. Managing the user group should be a owned task
User research can often be a de-prioritized or informally run in part because effective research is time consuming and wrought with logistics challenges. These logistics challenges can often be mitigated – or at least planned for – by making it somebody’s formal task to create and maintain the user group. Some qualities of this person are mentioned below, but the most important thing to remember is that due to the considerable lead time it takes to form a user group, the person in charge of creating it needs to fully understand the weight of this responsibility.
2. Find a local, get them invested in the project
Finding a talented local (either geographically, demographically, or psychographically) is sometimes difficult logistically. Bite the bullet and get it done. If it seems difficult to coordinate finding one local person, imagine how difficult it will be to manage a user group as an outsider! So far, we’ve found the best locals have a strong, often extroverted personality and the ability to understand both the local culture and the culture of your business and easily balance the two. These people are hard to find and immensely valuable – treat them and pay them well and make sure they know that you’re personally invested in their careers.
Also, be cautious. While it is great to have people with cross-cultural knowledge, there is a big difference between a person from a place and a person currently living there. First, a lot of physical interaction is necessary for a role like this, so being in place is part of the job description. Second, design research and validation is often a measure of context and constraints. Constraints are generally felt rather than articulated, so a person’s memory of context will often be shaded by a different bias from a person living day to day under those constraints. This can lead to both missed opportunities and misaligned priorities if not balanced with real user data.
3. Get them involved in the production
There is a good chance that your market or domain expert isn’t going to have a lot of technical knowledge. This is fine (some would argue it is preferable) but it is worth getting them involved in the development conversation as soon as possible. Not only will they have valuble product insights, but if they are managing a user group, it will help them manage release expectations with the participants. In retrospect, I wish we’d gotten this aspect up and running sooner on our project.
4. Train them in Design Research principles and practices – even if just a little bit
While it is good practice to have a trained design research moderator to lead the team, it is important that everyone can speak the language and is familiar with the practice. Many people that will have direct access to current or potential customers will be in sales and marketing. An effective research discussion, however, is very different from an effective sales discussion, and most of the difference will be in the habits of the company representative. In sales, we are creative: we’re trying to craft a beautiful narrative for the person we’re talking to using the product we’re trying to sell. Research values neutrality – we talk just enough to keep the conversation moving, but bringing our own personality or excitement about a product will bias the information we need. This distinction is easy to understand but quite difficult to practice.
5. Help your team understand the type of data you’ll get out of research
Direct answers don’t come out of research. Research can often validate a feature that has already been created, or help us understand and brainstorm about the value of new features. At the end of the day it is important to remember that qualitative research is not statistically significant – it is part of the abductive process, not a scientific validation.
6. Don’t underestimate the logistics
In this project, and in most projects that I’ve been on in the past, the actual interview is a piece of cake compared to the grunt work of finding and scheduling interviewees. Often, a marketing research agency will have a data base that can be leveraged for design research interviews. These are expensive, but tend to be worth the price once the cost of time spent and risk (of not getting user information early) are taken into account. Generally speaking, the more money a user group makes, the harder it is to get an interview with them scheduled. Doctors, for instance, are a pain because they spend a lot of their time getting paid lots of money to save people’s lives. Be flexible.
7…but since you are going to underestimate the logistics…
It is a constant fight to get research done in the beginning of a project, but since this is usually impossible the team needs to have the ability to be productive in the meantime. For this reason, it is crucial to have an effective backlog that can be flexibly changed based on the current business needs. If you’re running scrum, this means a dedicated and qualified Product Owner.
Doing the research for MedicSana has been one of the most challenging and rewarding professional experiences so far in my career and I would love to talk in more detail to anyone interested in our findings and our process. For more information about the different aspects of the MedicSana project as a whole, check out the homepage of this microsite.
All photos of individuals on this post have been formally agreed to at the time of our interviews. If you see your photo here and you’ve changed your mind, contact me through the MedicSana facebook page and we’ll swap it out.
Read More
Read more about the MedicSana project, other design case studies, or more about me on my homepage.