Round 1.1: Test user understanding of the difference between Modules and Recipes

Problem/Motivation

Research has indicated that users who are either non-technical or unfamiliar with Drupal (including technically skilled users without Drupal expertise) struggle to differentiate between the concepts of “Modules” and “Recipes.” This lack of clarity creates a barrier to understanding and effectively using these features.

Objective

To assess whether separating the two concepts is necessary and, if so, identify an alternative terminology that resonates with and is easily understood by new users without prior Drupal context.

Hypothesis

Simplifying or unifying the terminology for “Modules” and “Recipes” will improve comprehension for new users, reduce cognitive load, and lead to a better onboarding experience. Testing alternative labels will help identify the most intuitive option.

Important note:
This issue is about conducting user research to identify where users face challenges and how Drupal can better communicate key concepts. It’s not the place to propose new names for extensions, modules, or recipes. If you’d like to help, we’d love your input in defining or running the tests, or sharing insights that directly support the research. Join us on the Drupal Slack channel #drupal-cms-ux-marketing. For general ideas or naming discussions, join us there and open the discussion there or open another issue. Thanks for helping us keep this focused and productive!

Conclusions and next steps

This piece of research helped us gain some valuable knowledge about our target audience perceptions of extend, recipes and modules, and raised further questions about next actions. Taking the findings from round 1 together, conclusions can be drawn to highlight several areas in need of ideation and improvement, to be prioritised alongside the product goals, timeline and roadmap for Drupal CMS. Considerations arising from the research are framed as problem statements below.
1) Our target audience doesn’t associate ‘Extend’ with a way to add functionality and capability to their site. How might we clarify the path to enable users to install new features and functionalities so they can see how to do this from the dashboard?
2) Our target audience recognises recipes as ‘less-technical’ than modules and therefore something they would use to add in features to a site. Are we happy to accept this? If not, how might we change the display of recipes to align with the modules?
3) Our target audience deemed modules ‘for developers’ on account of their labels, descriptions and varying logos. Are we happy to accept this, and if not, and we want all modules to be available to our target audience, how might we adapt the display of modules to be inline with something our target audience feel they could use?
4) Some of our target audience felt recipes were more Drupal-integrated than modules on account of the different logos. Are we happy with this distinction?
5) Our target audience expected that by selecting ‘install’ on recipes they would see a set of instructions or a step-by-step process. How might we design tests to understand if recipes in their current form meet these expectations?
6) Our target audience said they would want to know more about what they would get from installations of recipes and modules as they were unable to make sense of what the functionality offered (this was particularly pertinent for modules if they didn’t recognise the module name). How might we make it clearer what individual recipes and modules do to help our target audience make installation decisions?
7) Our target audience felt the current display of recipes and modules represented a ‘mixed bag’. Are we happy to accept this or do we want to ideate to think of ways to better display modules and recipes rather than an alphabetical list?

Recruiting test participants

It was important to test Drupal CMS with people representing the target audience, therefore we specifically recruited participants with minimal or no Drupal knowledge and experience to complete the tests. All participants were used to creating content for marketing and communications purposes and all worked for Higher Education institutions.
To ensure we maximised the opportunity to learn from the participants and to use their time most efficiently, in some cases we asked participants to complete multiple tests. All tests were completed online over Zoom.

Designing and running the tests

Specific tests, including scenarios and associated tasks, were designed for each area we wanted to learn about. To gauge understanding of extend, recipes and modules, we asked them to talk aloud about a mocked-up environment including screenshot screens.
To learn what participants understood by the Drupal terminology used to describe adding site capabilities and functionality, we designed tests that asked participants for their thoughts at different stages, mimicking the Drupal CMS onboarding process, revealing context progressively for each of the concepts ‘Extend’ ‘Recipes’ and ‘Modules’.

Stage 1: Dashboard: How would you add extra capability or functionality into your site from here?

To start the test, participants were shown a mock-up of the Drupal CMS dashboard and asked to look around and say they would go if they wanted to add extra features to their site.

Stage 1: Results: Most participants did not select ‘Extend’ to add in functionality

Participants reviewed the options in the dashboard, but few picked out ‘Extend’ as their first choice to add in functionality. They all identified the dashboard as a place where they could make changes to their site, such as adding in content types, but they were unsure whether ‘Extend’ would be the appropriate option – stating ‘Structure’ and ‘Configuration’ as other places they may try to do this. Reflective comments included:
· “I am not sure what Extend would be for...” (participant 2)
· “Extend. I don’t know exactly. Could be for plug-ins or something like that?” (participant 4)

Stage 2: Extend page: What options would you expect to see here?

Continuing from the first stage, the participants were asked to imagine they had clicked ‘Extend’ to add in functionality to their site, and were shown a mocked-up page that contained the page title ‘Extend’, and the search bar, as well as top-level menu items ‘Browse recipes’ ‘Browse modules’, ‘Update’, ‘Update Extensions’ and ‘Uninstall’. They were asked to describe what they thought this page would contain.

Stage 2: Results: Participants were not sure what an ‘Extend’ page would contain

Some participants struggled to articulate what they would find on an ‘Extend’ page, which was perhaps unsurprising given their unfamiliarity with what the terminology meant; however, their descriptions did indicate that their expectations were aligned to what the Extend pages do contain. Reflective answers included:
· “When I think of extensions, I think of like those Google Chrome extensions, you know, ad blocker, for example” (participant 2)
· “Could be something that was elsewhere doing work behind the scenes—separate to the website—like pulling data from somewhere else—so like a widget?” (participant 1)
· “Maybe this could contain extensions related to the published content I already had on my site—like ‘you might be interested in this—or just some of the most common ones, like a calendar like people would know how to use that—then I imagine you could get some more like niche specific ones for specific site uses.” (participant 1)
· “I would expect something to pull data related to X or an organisation.” (participant 4)
· “I wouldn't know what to search for because I'm not really very sure.” (participant 3)

Stage 3: Browse recipes page: what do you understand by recipes, and what do you think you can do on this page?

Building on the previous stage, participants were shown a mock-up of the ‘Extend’ page populated with recipes and asked how they might act on the information on the page.

Stage 3: Results: Participants expected recipes to contain instructions to follow

When they saw examples of recipes displayed, participants were able to make more sense of what recipes were. Some said they would appreciate more detail to be able to decide whether to install them or not. When questioned what they would expect from installing one of the recipes, all said they expected to be shown instructions to follow in order to obtain the functionality described. Reflective comments included:
· “I think installing a recipe like the webform one would give me instructions to follow to get that set up” (participant 3)
· “Google Analytics caught my eye, so I'm assuming I'd click install and then it would give me the instructions needed to put this feature into the site's code so it runs.” (participant 2)
· “I would expect [at installation] to have another administrative screen that would ask me what kind of fields I want, what type of information, I don't know exactly, but it would ask for more information to make it more specific to my needs.” (participant 4)
· “I might want to click on it [install] and know a bit more about it, maybe see some examples to know what it was, because there's some that are maybe less obvious what is going to appear like or what it's going to do” (participant 1)

Stage 4: Browse modules page: What do you understand by modules and what do you think you can do on this page?

Stage 4: Results: Participants thought modules were technical, aimed at developers that could be installed in the background

When they saw examples of modules, having previously seen examples of recipes, the participants shared their perceptions of what they thought modules were and what they thought installing a module would entail. Most felt that installing modules was a technical, background process requiring minimal user input, perhaps resulting in a completion notification.
Representative comments:
· “To me that [module screen] looks like you would install it and it would kind of take care of itself. You know, like when you do an update on like Windows” (participant 3)
· “Here [on the module installation option] I would expect nothing. Maybe just an explanatory page that says this is done and this is how you use that additional functionality in your page. Something like that.” (participant 1)

Stage 5: Comparing recipes and modules: What do you think are the differences?

When they had seen both the ‘Browse recipes’ and ‘Browse modules’ pages, participants were asked about their perceptions of the differences between them.

Stage 5: Results: Recipes seem ’less technical’ than modules, and contain instructions.

Most participants deemed modules to be more specialist and developer-focused, and by contrast, perceived recipes to be aimed at a ‘less-technical’ audience, characterised by step-by-step instructions to enable the user to implement the functionality they wanted. They felt installing modules would align to a more automated action. Several questioned why the modules page seemed better equipped to help users choose features (with filters, verification status and data about numbers of installations) and said they felt the features offered by both recipes and modules seemed to offer a very mixed collection of functionalities and could be organised more logically. Representative comments included:
5.1 Perceived differences of how modules and recipes would work:
· “Recipe sounds like it's helping you build something. It's like it feels like here's a set of instructions or script to help you build something so you can you'll be able to make your own changes throughout, so it's kind of like here's basic steps. Module seems more fixed. So just add it in the background” (participant 2)
5.2 Perceived differences of the sorts of functionality offered by modules vs recipes
· “Maybe the recipes are more fundamental and then the modules are what goes on top of it” (participant 4)
· “Like this [recipe] I would expect would be added to the sidebar [left-hand nav] or somewhere in the admin but this [module] would only be available to certain people in a certain bit of the site” (participant 1)
· “Recipes seem a bit more integrated. Modules are a bit more sort of add-on”(participant 1)
5.3 Perceived differences of who modules vs recipes are aimed at
· “These [modules] seem more technical - with development status maintenance, security …I think that would only apply if you were really sort of on top of the development tech side of things” (participant 1)
· “This seems to be more developer focused from what I'm looking at I see I see meta tag and that's HTML, Chaos Tools, C-Tools API. It's a lot of developer language so I'm assuming this is mainly for developers” (participant 2)
5.4 Perceived differences of the verification status of modules vs recipes
· “Because these [recipes] all have the Drupal logo, I'd assume that they were all verified. So I wouldn't have to check if they were legit[imate]- I wouldn’t have to look at reviews to check if these were safe to use like you do in Google Chrome” (participant 1)
· “These [modules] are maybe out with Drupal, things that are connected, but are external” (participant 1)
5.5 Perceptions of sorts of functionality on offer from both modules and recipes
· “Accessibility tools essentially help me review the website content to let me know its level of accessibility, but then there's the blog here, which is a blog post content type so for me that sounds different because it has more direct impact on what is visible on the front end” (participant 4)
· “There is a bit of a mixed bag here. Are they just alphabetical? If I was thinking about building a page, I'd maybe look for like a section that had like forms and events and profiles and things like that. To me, Google Analytics and accessibility tools - these are things that you would think about after you've got a page put together, so they would be separate” (participant 3).
· “See some of these are seen like content types, which confuses me a little bit because AI Assistant Google Analytics that seems more technical” (participant 2)