According to the annual GreenBook GRIT study, communities have been the fastest-growing and most successful market research innovation of the last decade. But this success also means they are a complex concept, with important variations such as size, the balance between qual and quant, the balance between external and internal services, and the decision about whether to create a short-term (or pop-up) community versus a long-term community. Like many complex decisions, the key to making them is to start properly, by defining what you need and having a clear implementation plan. The same is, of course, true for a redesign, especially if the redesign is also being seen as a relaunch.

In this article, I set out a framework that we use to ensure a design or redesign process for a community is optimised efficiently. This framework relates to ongoing, long-term, or longitudinal communities only, as pop-up communities can use, and indeed need, a somewhat truncated design process.

The Framework

1. Assess stakeholder needs, and their ability to contribute to the solution.

2. Assess your ways of working, eg. agile, iterative, democratised, integrated, etc.

3. Assess the outputs you need to create, eg. qual, quant, dashboards, reports, stories, video, etc.

4. Assess the features you need, such as platform community size, service levels, sample sources, etc.

5. Select a system(s).

6. Bring it together into a design or redesign plan.

Assessing Stakeholder Needs

Organisations conduct research to help the business make better decisions. Any design or redesign has to start by assessing what the business needs to achieve, in order to make better business decisions. The process should also assess whether there are other relevant needs, such as the need to create or strengthen a customer-centric approach. Broadly, there are two categories of needs; those that are being met, and those that are not being met.

Met needs: For each of the met needs, the framework calls for the existing solution to be assessed. Could the need be met more effectively, efficiently or inexpensively via a community? Being flexible during this process is important, for example asking questions like, “If we could provide answers faster, with more qualitative depth, but with a smaller sample size, would that be equally good, or an improvement, or less favourable?”

Unmet needs: What decisions are currently being made without the right information, or with less information than is desired? What sorts of information would support better decision making? How much would those answers be worth (ie. what budget might be available)? How fast would the information be needed? What would the information look like (eg. qual or quant, data or stories, recommendations or dashboards)?

Some of the met needs and some of the unmet needs will be the core items to build the community design or redesign around. These are the base of the pyramid, upon which everything else is built. We don't start by describing what the system should be able to do, we start by defining what is needed, then we define what is required to meet those needs.

Assess your Ways of Working

Is the community going to be managed and operated by an agency (the full-serve model), is it going to be operated by the insights team, or is it going to be a democratised system with many players, from many teams, all accessing the system? In all likelihood, it is going to be a blend of all three. Is this project going to be a true community, putting the customer at the heart of the company, or will it be more of a research resource, ie. more of a panel?

Assess the Outputs that are Needed

Armed with the list of needs from the first step in the framework, we are now in a position to define the sorts of outputs that will meet those needs. Here the term outputs includes: tables and dashboards, the sorts of sample sizes desired, the type of members that need to be researched (eg. demographics, customer status, value, etc.), as well as findings versus recommendations. One key factor is the turnaround time that is wanted/needed, what is the target gap between a request and a delivered result?

When defining the outputs, it is important to explore new and innovative options. One of the reasons to change your system is to leverage the benefits of new ways of doing business, and new ways of communicating results.

Assess the Features that are Needed

When we assess features, we need to create a prioritisation, and our preferred option is the MoSCoW method. The features, such as DIY, online qual, surveys, tables, dashboards, sample size, languages, etc. should be scored as being one of the following:

• M – Must have

• S – Should have

• C – Could have

• W – Won’t have

Key features that need to be determined are:

• What sort of quantitative research do you want to conduct? What sort of surveys, what sort of analysis, what sort of sampling? How simple does the system need to be? How complex does it need to be?

• What sort of qualitative research do you want to conduct? Discussion groups, online focus groups, smartphone ethnography, etc.? What balance of simple and complex do you need?

• What sort of engagement tools do you need? For example, newsletters, social media, gamification, incentive schemes, etc.

• What sort of communication tools do you need? For example, email, messenger, SMS, apps, etc.

• What sort of security do you need?

• What systems do you want to integrate with, for example Big Data systems internally and third-party research tools externally?

• How are system migrations going to be handled? Can you start a system fresh, or will it need to pick up existing projects, samples, communities, etc.?

Select a System(s)

What often happens here is that you discover two unpleasant truths:

1. No system currently available delivers everything you want. Many times, there is not even one that meets everything on your ‘Must Have’ list.

2. The systems that come closest to meeting your ‘Must Have’ and ‘Should Have’ needs may be too expensive.

This starts two reviews. Firstly, talk to your potential suppliers to ask what changes they would recommend in order to make it possible/more affordable. Secondly, review the MoSCoW prioritisation, to see what you can trade down.

One decision you will need to make is whether to adopt a single system, from a single supplier, or whether to blend two or more tools. For example, one common option these days is to blend a community platform and a specialist qual tool or video-research tool.

Creating the Community

Once a system has been selected, the fun work can start using the assessment information collected above. Detail who is going to be recruited, and how they are going to be engaged and motivated. Set up a method for booking projects, for reporting projects, for measuring the ROI, and for shouting about the availability and success of the community to the rest of the business. Put into place the links between the community and the stakeholders within the business.

This is where the tone of the community is established, including such elements as its look and feel, the name, the messaging, the style of reporting that will be used, and the internal and external messaging of why the community is there, what it is for, and how it helps the business.

For more thoughts on how to run a community, check out our Manifesto for Communities.

Want to know more?

Obviously, a post like this can only scratch the surface of the framework we use to optimise community design and redesign practices. If you want to know more, then here are two options:

• Sign up for one of our webinars on this topic – we have several over the next few weeks, in English, French, and German

• 1 June, French, 10am London (11am Paris/Berlin) See link here

• 17 June, English, 10am London (11am Paris/Berlin) See link here

• 17 June, English 3pm Sydney See link here

‍

Contact us via HX@Potentiate.com and ask us to present the steps in detail and discuss how they might be applied to your business.

‍