Drupal In A Day (DIAD) is an in-person training event, designed as a beginner-friendly hands-on introduction to Drupal, the open-source content management system. When the University hosted DIAD, several of the UX team took the chance to attend.

As content management systems go, Drupal is one of the mainstays. It’s been around for 25 years and is particularly famed for its robustness, reliability and flexibility – so much so it’s trusted to power websites of enterprises, governments and higher education institutions around the world. It’s open-source so there’s no proprietary lock-in – the functionality, features and innovation available in Drupal comes from a thriving worldwide community of contributors – as individuals, agencies and organisations.

One of the best places to learn about what Drupal is, what it stands for and what it aims to achieve is the blog site of its founder, Dries Buytaert.

Dries Buytaert blog

In 2025, Hilmar Kári Hallbjörnsson taught the first Drupal In A Day on the final day of DrupalCon Vienna.  Hilmar had been teaching Drupal to students at the universities of Reykavik and Iceland for many years and felt strongly that teaching Drupal to new generations, to inform them of its capabilities, and to inspire them of its potential was something the Drupal community needed, as a way to nurture the longevity and sustain the future of Drupal. Through a tremendous effort, he made the first Drupal In A Day happen in Vienna in October 2025. It was very well-received, successfully establishing the Drupal In A Day format going forward.

Read more about the first Drupal In A Day in Hilmar’s blog post from 2025

Drupal in a Day: Vienna 

Hilmar travelled to Edinburgh to deliver Drupal In A Day with our own Web Development Team Manager, Gareth Alexander at the start of June 2026.  Nick (Senior Content Designer), Shlok (AI and UX Innovation Intern) and Hannah (Digital Content Style Guide Intern) from the UX team signed up for the event along with other LTW interns and staff from the wider University with an interest in learning about Drupal. Here, they reflect on their experiences of the day.

Nick’s reflections 

I attended this training to bring my understanding of Drupal up to date. The last time I set up a Drupal site was in the early 2010s, and a lot has changed since then. With Drupal providing the backbone to EdWeb 2, I wanted to get to grips with some of the terminology and concepts that underpin conversations within our team about what our central CMS can do. 

I was particularly interested to learn more about Drupal CMS, a new service that helps you set up a Drupal site more quickly and with less need for technical understanding. 

After getting the required software set up on my laptop (thanks Kirsten), I clicked along with Hilmar and Gareth as they walked us through the various sections of Drupal CMS. We worked through steps to create a new content type and we created different Views to display the same content. We tweaked image formats. We also learned how to attach tags to a piece of content and how these tags can act as a filter for overview pages. 

By the end of the day, I hadn’t suddenly become a Drupal expert. But I did have a better understanding of how EdWeb 2 works behind the scenes. In particular, I felt like I knew more about how EdWeb 2 takes the content you enter when you create a page and presents this in different ways elsewhere on a site. 

Alongside that, I would now feel more confident in setting up a new Drupal CMS site, and I now have a better understanding of what this system offers in comparison to other ways of operating a website. 

Finally, the day gave me a better sense of how the community aspect of Drupal is central to how this project keeps going. Hilmar and Gareth emphasised that there are various events in the calendar where people working with Drupal can meet up and collaborate. That’s a powerful message: that anyone is invited to learn more, become part of the community and contribute to how this system works. 

Shlok’s reflections

Before starting my internship, Drupal was a completely new concept to me. I did not really know what a content management system was, how Drupal worked, or why it was used by universities and other large organisations. Because of that, Drupal In A Day was a really useful introduction for me. 

I thought the format worked well because going through everything in one day helped keep a flow of information. It was quite intense and sometimes fast-paced, but that also meant we were able to cover a lot of concepts in a short amount of time. I would say I was able to follow around 70% of the session, which felt like a good start considering Drupal was completely new to me. 

One of the parts I found most useful was the introduction to Drupal itself. It helped me understand what Drupal is, what a CMS is, and why the University uses it. I learnt that Drupal is valued because it is stable, secure, flexible and open source, which makes it suitable for large and complex websites like those used by universities. This helped me understand why Drupal is still used by many major institutions. 

I also found it interesting to learn about the Drupal community and the different ways people can work with Drupal. Before the session, I assumed Drupal was mainly for developers. However, I learnt that people can build careers around Drupal in different ways. Some roles involve coding and development, while others focus more on design, content, user experience, training or project work. That helped me see Drupal as more than just a technical platform. 

One point that really stood out to me was when we were told that Drupal has a steep learning curve at the start. This was useful to hear because it made the difficulties I was facing feel expected. Since many people find Drupal challenging in the beginning, it was reassuring to know that not understanding everything straight away was normal. It made me feel more comfortable continuing to learn. 

During the practical parts of the day, I learnt about some of the basic Drupal features, such as creating and managing content pages. At first, this was quite confusing because the concepts were new to me. However, as the day went on, I started to become more comfortable with the terminology and the way Drupal is structured. 

Another part that I found very helpful was the follow-up assignment where we had to build something from scratch. After learning so much in one day, I think it was important to have a task that allowed us to apply what we had learnt. It helped me consolidate my knowledge, see which parts I had not fully understood during the session, and become more comfortable with Drupal before starting work on my internship prototypes. 

One thing I would have liked to learn more about was the command line and the use of terminal commands. We touched on some setup and development processes, but I think spending more time on what the commands do and how they fit into the Drupal workflow would have helped me. I would also have liked to learn more about the coding side of Drupal, especially how to build custom Drupal modules. This is particularly relevant to my internship because my work is focused on AI and innovation within Drupal. 

If I could suggest one change, it would be to make Drupal In A Day into a two-day or three-day format. The first day could stay mostly the same, giving everyone a broad introduction to Drupal. The second day could be a slower guided session where participants build something with support from the instructors, similar to the assignment we were given afterwards. A third optional day could focus more on coding and custom module development for those who want to explore the technical side further. 

Hannah’s reflections 

I signed up for the Drupal in a Day training with very little knowledge of the CMS beyond working with existing EdWeb 2 sites, such as when creating prototypes of Style Guide pages or writing blog posts. So, I was interested in increasing my knowledge of Drupal as well as gaining the ability to build a site. Before the training began, I was unsure how well I would follow the instructions as a beginner, but Hilmar, Gareth, and all of the members of the Drupal community who were present at the training were extremely helpful, informative, and patient when it came to giving assistance at points where I was confused or behind. 

Once I had overcome a technical error with my laptop and decided to use Drupal Forge, I was able to follow along with the instructions being provided and replicate the Artist biography pages that Hilmar and Gareth were demonstrating. The course was fast-paced and detailed, and while maintaining this pace was a challenge, it made the course engaging and the product of the day felt like a genuine accomplishment. 

With the knowledge that I gained throughout the training, I feel that I have a strong foundation that will allow me to continue to develop my skills in building a Drupal site further in the future. In particular, I think the example site that we were creating during the training was incredibly useful in that it allowed us to try out several different aspects of building a site with Drupal, such as different content types, tags, and images, as well as exploring some different design options as well. 

I was impressed to learn about how community centred Drupal is, and that contributions and developments to Drupal are made by users and members of the community. Gareth and Hilmar’s explanations of how this works really helped me to understand why Drupal is as adaptive and intuitive as it is (such as in its security and bug fixes), which is that these developments are a direct result of user experience. Furthermore, Gareth and Hilmar also emphasised the flexibility of Drupal, due to the ability to install ‘recipes’ that customise the functionality of sites that you are building. 

Overall, I think Drupal in a Day was an extremely useful and practical training session that has equipped me with the skills to build a basic site and further develop these skills whenever I have the chance.  

Emma’s reflections

When it comes to Drupal, I am largely self-taught – pretty much everything I know has been gleaned from reading, attending/watching sessions from Drupal events, and (predominately) pestering people in-the-know with my questions. When Drupal In A Day came to the University, I pondered whether I should attend. I’ve contributed to the community since 2022. I’m on the Drupal leadership team. Surely I should know Drupal by now? I took a split second to reflect and realise that you never fully know Drupal. There’s always something new to learn, something to challenge what you thought you understood, or something to clarify an area you weren’t quite sure about. Conscious of not taking a space away from a complete Drupal beginner, I opted to sit in on the event, to follow along, while working on other things.

The day combined practical exercises with general Drupal knowledge. Hilmar and Gareth began with the basics, covering key parts of the process to get started and familiarise with Drupal – like setting up DDEV, using Drupalforge and creating a Drupal.org profile. As the day went on, it was great to see quick progression to experiment with some of Drupal’s flagship modules, especially Drupal Views which holds huge power for presenting and displaying structured content in a range of adaptive ways.

Drupal CMS, Drupal’s low-code product provided the playground for learners. Having worked on Drupal CMS since it began, I found it heartening to see it being used to introduce Drupal to new audiences, to help them learn what Drupal has to offer and to help them start ideating on how they might use it. Adopting a UX perspective, I tuned into comments from fellow attendees about Drupal CMS, noting observations to follow up and logging areas for UX improvement to carry forward in my ongoing Drupal UX contributions.

Reflecting on the day as a whole, it helped attendees achieve what is often the hardest thing about Drupal: Getting started. All too often people new to Drupal can find it overwhelming, and they find when everything is possible it’s hard to choose a direction. Drupal In A Day sets learners on a path to start discovering Drupal and making it their own, in other words, planting a seed from which the community can continue to grow.

Our Editorial Style Guide contains many conventions and we know from research that publishers struggle to remember to apply them. Could automation help? We experimented embedding style guide rules into a Drupal module that checked content against the rules in the editorial interface and suggested corrections when the rules weren’t followed.

As part of a concentrated effort to make it easier for publishers to apply our style guide rules, Mostafa Ebid, a student who came to work with us in summer 2025, installed Editoria11y, an open-source Drupal feature and configured it with selected rules from our University style guide. Applying this feature to a site with demo content, he tested it with University staff to see how well it worked, and how useful and usable they found it.

Read more about our ongoing style guide work:

Collection of blog posts about the Editorial Style Guide

Drupal Editoria11y is an open-source accessibility checker

Editorial accessibility ally (shortened to Editoria11y) is a module developed by John Jameson from Princeton University that enables automated content checking directly in the editorial interface. Originally created to help content editors catch accessibility issues, its configurable architecture makes it well suited to embedding other kinds of rules, such as institutional style guide conventions. The checks can run in real time as content authors type, and can also be applied to content in published pages and previews, to flag issues to be corrected.

Editoria11y can include more than 50 built-in content tests covering image alt text, link quality, heading structure, and general content issues. Flagged issues are noted at the page level by an indicator bar, which includes a count and a categorisation of the type of issues (default categories are headings and alt text). Through this bar it is possible to identify the precise inline location of the problematic content with visualisers. Each visualiser is associated with a modal that contains detail about the problem element and plain language tips explaining how to fix it.

In addition to the on-page alerts, it is possible to review issues across a site via a reporting dashboard which can be configured to log recurring issues or most problematic pages, as required.

Read more about Editoria11y on Drupal.org:

Editoria11y Accessibility Checker project page

We designed tests to learn if Editoria11y would be useful and usable to embed style guide rules

Editoria11y presented itself as a mechanism to enable web publishers to check their content against style guide rules, and we wanted to understand the kind of experience this provided in EdWeb2. In particular, we wanted to understand:

• If Editoria11y could effectively check content against our style guide rules
• How Editoria11y presented results of the checks in the editorial interface
• If publishers could use Editoria11y to correct content that misaligned with the style guide

Moreover, we wanted to learn if the addition of Editoria11y to the EdWeb2 editorial interface improved the publisher experience or not.

We picked deterministic rules about dates and numbers for the tests

Like many Drupal features, Editoria11y is very flexible and customisable to fit a range of different use cases. Since it was new to our publishers, we were keen to avoid overengineering it, taking care to configure it to present the minimal information necessary to achieve our testing goals.

The University’s Editorial Style Guide contains between 60 and 70 separate rules, of which fewer than half are deterministic (in other words, can be applied directly without editorial judgement). It made sense to include deterministic rules in the tests, to enable us to accurately assess how effective Editoria11y was at checking them.

Rules in the dates and numbers section of the style guide seemed a good fit for the tests, so these were configured into Editoria11y.

We set up Editoria11y to display an indicator bar, visualisers, modals and a dashboard

The module was set up to display the indicator bar, the inline visualisers and the reporting dashboard. Content that contained sentences with dates and numbers was saved in draft in a demo interface which had Editoria11y applied. In the test scenario, participants were asked to assume they had been asked to review this draft content before it went live and to use a checker tool to help them with this.

Screenshot of the Drupal Editori11y tool in action, showing the yellow indicator bar at the bottom right of the interface, tallying the total number of style guide errors on the draft page

Screenshot of Editoria11y showing on the left, the indicator bar at the bottom right of the draft page, and on the right, the same draft page, but revealing the locations of the style guide errors (activated when the indicator bar is pressed) and an example of the modal giving detail of the error and the suggested fix

Screenshot of Editoria11y showing on the left, the display with the indicator, and on the right, the reporting dashboard summarising all the errors (which opened in another window in the interface)

Watching participants use Editoria11y, we learned what worked and what didn’t

Tests were carried out with seven participants. Observing how they made sense of the different parts of Editoria11y and interacted with it, we were able to draw conclusions about how useful and usable it was to support the context of web publishing in EdWeb2.

Participants understood the relationship between the indicator and the visualisers

The first part of the tests involved showing participants the draft content in the editorial interface with Editoria11y applied. All of them were able to understand that the number of style guide errors on the page were tallied in the indicator bar at the bottom right of the page, and that they could use the indicator bar to reveal precise locations of the errors on the page, together with a modal for each error, explaining the error and the suggested fix.

Placement of the visualisers and modals often made it hard to read the draft content

Taking an overview of the visualisers in the draft content, participants commented that they felt a bit overwhelmed to see so many. Some felt the placement of the question mark visualisers made it difficult to ascertain which parts of the content needed to be corrected, which was slightly helped by yellow outlines around the text. Placement of the modals masked the text beneath, however, meaning participants found it difficult to engage with the original context of the errors to be corrected to assess whether to accept the suggestion or not

Screenshot of Editoria11y showing a view that some participants found overwhelming: indicator bar, question-mark indicators, yellow outlines and an open modal

Descriptions of the errors in the modals were not clear to some participants

Reading the information in the modals, some participants were unclear of the error it was pointing out. Specifically, in a modal describing the rule to write dates without including ‘th’ or ‘rd’ after numbers was written as ‘Write dates without commas or ordinal suffixes’. Some participants were unfamiliar with what ‘ordinal suffixes’ were, but seeing the suggested change presented as a ‘before and after’ tracked change with the error crossed out (in red) and the suggested change presented in green helped participants understand the proposed correction.

Screenshot of Editoria11y showing a modal explaining the rule to not include ordinal suffixes when writing dates

Participants were able to use the modals to correct some style guide errors

When they had read and understood the errors being highlighted, most participants were able to assess whether to accept the suggested fixes and apply them based on the information contained in the modal. Several participants entered into a flow of using the arrow keys in the modals to clicking through the different errors and accepting the fixes, especially when the fixes related to a recurrent error – for example, capitalising the first letter when writing days of the week. They appreciated a notification alerting them that the fix had been applied, which temporarily appeared at the top right of the screen, although some said they would have appreciated this notification to remain for longer as it was easy to miss. They were also unclear whether they needed to save after applying each fix, or if this could be done when they had worked through all of the fixes on the page.

Screenshot of Editoria11y showing a notification in the top right of the interface to confirm the fix had been applied

Not all errors were fixable with automatic rule application – some required interpretation and judgement

Viewing the suggestions in the modals, several participants noted a problem with the fixes being based on automatic application of the style guide rules. Specifically, relating to the rule about omitting ordinal suffixes for numbers, there were several instances where it didn’t make sense to apply this rule directly. For example, a date written as ‘5th of December’ contained a suggested fix to remove ‘th’ but not to remove ‘of’. Another relating to ‘4^th year’ of studies suggested removing the ‘th’ but not writing ‘fourth’ as a way to make the sentence readable, and similarly, another advised removing ‘st’ from ‘1^st floor’ which was an incomplete fix.

Screenshots of Editoria11y showing instances where the ordinal suffix corrections couldn’t be directly applied

Some participants’ trust in the checker waned when they realised it didn’t catch all the errors

Of those who took part in the tests – some were more familiar with the rules of the style guide than others, and this impacted the trust they placed in Editoria11y. When they reviewed the Editoria11y outputs against the draft content and spotted corrections that hadn’t been picked up or flagged by Editoria11y, they were inclined to disregard the tool and check the content for themselves to ensure the text was completely compliant.

Screenshot of Editoria11y showing a style guide error where the pound sign is missing from an amount that the tool has not picked up

Few participants said they would use the dashboard as they felt that was for a site administrator

Navigating through the different options on the indicator, participants were able to access the dashboard interface, which was titled ‘Content Accessibility Issues’. Reviewing what was there, in sections called ‘Top issues’, ‘Pages with the most issues’ and ‘Recent issues’ most participants said they didn’t feel they would use this feature, and presumed it would be for someone with full responsibility for the whole site.

Editoria11y has potential as a style guide helper tool, but would need contextual refinement

Taking the findings together, Editoria11y showed promise as a way to embed the style guide rules into draft content, to avoid web publishers needing to navigate away from the editorial interface to check the rules in the guide itself to then apply them. Participants understood what the indicator bar was there to achieve, and liked the idea of being able to check off corrections to their content through the modals. Some identified areas for improvement included:

• Refinement of the style guide rules embedded in Editoria11y, to include examples, exceptions and applications based on scope and context
• Embedding a more complete set of style guide rules into Editoria11y to help build trust in the tool
• Adaptation of the modal options to include ‘Accept with edits’ as well as ‘Accept’ and ‘Ignore’ to account for instances where editorial judgement needed to be applied to the suggested correction
• A way to show corrections in categories (for example, all those relating to numbers together, all those relating to punctuation together and son on) which could be addressed by the editor in sequence, to avoid overwhelm in the interface
• Suggestions for correcting content when reworked sentences were required – powered by an LLM such as ELM

As well as Editoria11y surfacing style guide rules, there is potential to use it for its intended purpose, as an accessibility checker, containing checks about the heading hierarchy and alt text on images. If this was to be included as well as style guide rules, however, progressive disclosure of the information should be used to avoid the interface becoming too cluttered.

Many of these areas overlap with work currently progressing in open-source Drupal, firstly develop a Context Control Center – as a way of handling rules to enable AI-assisted content production, and secondly to develop an AI Content Review feature, capable of reviewing content against defined rules and conventions.

Read more about these Drupal developments in my related blog post:

Think like a machine: How building a Drupal context-handling feature is providing a new lens on content design and style rules 

AI development keeps evolving as do the ways people seek to use AI. Traditional software development runs the risk of trying to perfect AI features people won’t use. Revisiting our previous AI research helped me tease out new opportunity spaces for AI features to help with content design tasks.

Last summer, Mostafa Ebid joined the UX team for a summer internship and built an AI assistant tool which integrated the University’s main AI provider ELM into EdWeb2, our Drupal content management system. The idea for the tool came from hearing University describe the difficulties they experienced when publishing web content. The tool included the capability to write content, design content and proofread, and was designed to work by typing prompts in a chatbot interface, right-aligned to the main part of the editorial interface. When prompted, an orchestration of AI agents were triggered to read textual content and use ELM to make suggestions for improvement based on what the publisher had asked for. Improved text was displayed in the sidebar chatbot interface for the publisher to review and consider using.

Read Mostafa’s blog post about how he developed the tool:

Integrating ELM with EdWeb – Building an AI tool for publishers

Initial tests of the tool with publishers revealed some potential, but identified the need to do further tests, specifically to understand limitations around the user interface display and to learn if the tool was useful to publishers in the context of content they were familiar with (as opposed to generic stock content that was used in the first round of tests).

Read my blog post about the initial tests of the tool:

Initial insights from UX testing our Drupal AI content assistant tool 

Mel Batcharj accessibility tested the tool, focusing on keyboard navigability, and Nick Daniels ran tests with two publishers in October last year. I recently reviewed the findings of this research to consider advancements in Drupal AI in the past 12 months, to assess whether the original premise for the tool was still valid, and to think about residual content design challenges AI could potentially help with.

Advancements in Drupal AI have resulted in improved AI features

The Drupal AI Initiative began in April 2025 with a group of participating organisations making a commitment to collaborate to build the future of AI in Drupal. As a result of the initiative, various workstreams began to shape Drupal’s infrastructure to support AI, to experiment with new innovations and to improve the UX.

Read more about this workstream:

Drupal AI Initiative project page on Drupal.org

A more accessible AI chatbot is now available as a Drupal recipe

Our original AI content assistant tool was built into a panel of the editorial interface as a custom build, which worked well when using a mouse, but which accessibility testing showed was restrictive when navigating using a keyboard. Since the tool was built, however, accelerated development in the wider Drupal AI community prompted the creation of an open-source AI chatbot freely available to apply. Adopting this chatbot was preferable as it avoided the need to maintain custom code and it was possible to use it with a keyboard only.

There’s an active Drupal issue to address the need for the AI chatbot interface to be expandable

Several of the participants who took part in Mostafa’s tests of the tool last year found it awkward to scroll through the AI chatbot output as it was presented in the narrow left-aligned interface. The same problem had been noted in the wider Drupal community, and therefore I raised an issue to have this rectified, which is being worked on as part of the AI Initiative task backlog.

We did more tests on our AI tool – this time using participants’ own content

In the first round of tests, four participants were all presented with the same piece of content (on the topic of safety procedures) and asked to use the AI tool to improve it in specific ways (such as writing it for user needs, making link text better, and so on). This approach turned out to be limited, as since participants were unfamiliar with the content, they were unable to assess whether the outputs of the AI tool were an improvement on the original content or not.

In a subsequent round of tests we therefore adopted a looser approach – asking participants to supply a piece of content they were already working on, and then asking them to use the AI tool to improve it to suit their needs. The results from these tests were more indicative of how useful publishers found the tool to make content improvements.

Results of these tests highlighted how the AI tool needed to change

Since we placed participants in a situation where they were using AI on content they knew well and could critique and appraise authentically, the results of these second-round tests gave clearer indications of what worked with the existing tool, what didn’t and where AI could be best applied to help with content design tasks.

Participants didn’t notice the content options in the AI tool, or the help text

The tool contained three different content options: Design Content, Write Content and Proofread, presented in a dropdown menu in its interface.

Initially, participants didn’t notice these options and used the default Write Content option.  When they later experimented with the Proofread option they found no discernible difference between these options in terms of outputs, which led them to believe that a simpler version with a single conversational interaction option would be preferable.

The tool defaulted to reading the content on the page, and working on this when prompted. Participants were initially unclear that this is how it worked, and they didn’t notice the help text to enable or disable this mechanism presented in the tool interface. Taken together, this feedback suggested that a simpler version of the AI chatbot, such as the one from the Drupal recipe, would be easier for publishers to use.

Close-up screenshot showing the content options and the help text on the AI tool

The AI tool had some value as a writing partner to suggest restructures to textual content

Responding to the task to experiment with the AI tool to improve their content, the participants quickly got used to how the tool worked, and recognised its use as a writing partner to prompt about their content and receive suggestions for improvement in a conversational way.

Prompts they used to improve a page of content in the body text field included:

• ‘Rephrase copy to condense, highlight key messages and make it accessible to pet owners looking to join practice’
• ‘Proofread copy so that it appeals to pet owners non clinicians’
• ‘Turn this page into web ready content. It needs to be concise, easy to scan, readable to a wide range of audiences’

These prompts resulted in edited versions of the page content, typically including structural elements like headings, bullet points and calls to action, delivered in the chatbot interface.

Side-by-side screenshots showing the prompt entered in AI tool to improve content for an audience (on the left) and after (on the right), with the output response to the prompt.

The tool lacked capacity to tweak or iterate on previous versions of content – which participants wanted

Once they had reviewed the tool’s initial outputs, both participants entered conversational turns with the tool, asking it to perform successive tasks on the content it had previously produced, to edit it further, in line with their specific requirements and rules.

Prompts they used to tweak initial AI outputs included:

• ‘Remove adjectives and exclamation marks’
• ‘Remove brackets’
• ‘Remove any unnecessary words, fix typing errors, suggest improvements for SEO’

With every new prompt in the conversation, the tool produced a fresh output, meaning the publisher was left to review a succession of different versions of the edited content, presented in the chatbot interface, without any indication of what had been changed. Participants found it difficult to review edits, as they would usually do when working on a piece of content, in order to compare the ‘before’ with the ‘after’ – ultimately to assess whether the AI tool outputs were to their satisfaction.

They said they would have liked the tool to have presented the edits in a ‘tracked changes’ format that they were familiar with from word processing programmes.

Side-by-side screenshots showing a prompt entered to improve existing content (on the left) and (on the right) the output from this prompt – showing a new version of the content

Participants didn’t really need the tool in the interface as they tended to edit text content elsewhere

When describing their usual content process, participants said they would usually prepare their content in a word processing programme like Microsoft Word rather than edit directly in the Drupal editorial interface. There were several reasons they chose this method – a key ­­reason being the need to involve others to check (and in some cases, sign off) their content in preparation for the website. They were more familiar with referring others to check their content or proofread it when it was in the Microsoft suite, than when it was in the Drupal editorial interface.

Furthermore, Microsoft Word accommodated the addition of comments and tracked iterative changes to pieces of content which was not possible within the Drupal editorial interface. This content preparation habit suggested that while the AI tool was useful to suggest content edits, this would have been more useful before the content was in the interface, and therefore could be achieved by pasting content to be edited into a browser-based AI tool or app (such as ELM).

Within the interface, the tool only had use as a ‘final check’ mechanism, to catch any typos, errors or style misalignments before the content was ultimately published.

The tool needed to be able handle more than text as pages were typically made of multiple elements

Reviewing the test set-up and comparing it to their usual ways of working with EdWeb2, the participants said the pages they worked on would usually be made up of more than just textual content in the body text field. They would typically work on pages with multi-column layouts, making more extensive use of Drupal paragraphs or including structural elements like accordions, feature boxes and cards. They were interested to know how the tool may make appraisals or suggest improvements for those sorts of pages to help them arrange their content in appropriate ways.

We identified new opportunities for AI content publishing features

Extrapolating on the feedback from the tests, several use cases and scenarios for applying AI to content design tasks emerged, which will help inform our ongoing work to apply AI to make content design tasks easier for publishers.

AI-assisted content structuring

Describing their typical content writing workflow, participants said they found it difficult to move from a text-based editor like Microsoft Word into the Drupal editorial interface where they needed to make use of Drupal Paragraphs as well as page elements like accordions to structure the content. Potential areas for AI development could therefore include:

• A mechanism to convert textual content into appropriate structural elements
• A way to make suggestions for accordion labels or structure
• A feature to ensure uniform creation of cards or feature boxes
• A means of cross-checking style consistency of pages made of multiple elements or with a specific layout

AI- assisted content design for SEO/GEO/AEO

Having their content picked up by search engines or being machine read was something participants wanted, but they were unsure how to write, tag and structure their content to make this happen effectively. Potential areas for AI development could therefore include:

• A way to have their content analysed for SEO effectiveness, based on signals like content quality, scannability and key word alignment
• A mechanism to suggest content changes aligned to specifically defined SEO goals and target user engagement measures

AI assisted content reviews – against specific style conventions and contexts

As well as ensuring their content followed the rules of the University’s Editorial Style Guide, both participants mentioned other conventions that they needed to apply to their content, that existed at a more local website level. For example, one participant’s site had a rule not to use brackets or exclamation marks, or to overuse adjectives, so they would have found it helpful to have a way to cross check content against these rules before publishing.

The Drupal Context Control Center is an emerging feature designed to handle the application of context rules within a site across various scopes and use cases, and Drupal AI Content Review is a related feature, designed to appraise content against given context rules and conventions. Together, these Drupal features may be a good fit to help University web publishers make use of AI to shape their content with the uniformity they require.

Read more about the Drupal Context Control Center and its development in my recent blog post:

Think like a machine: How building a Drupal context-handling feature is providing a new lens of content design and style rules

Read about AI Content Review on Drupal.org

We’re changing the direction of the AI tool based on what we’ve learned

Last summer it seemed certain that an in-interface AI chatbot content assistant helper was what we needed to build. A few improvements to the UI to make it expandable and navigable with a keyboard and it would be ready to go. As it turned out, things had moved on, and these problems were addressed by the wider Drupal community. This meant we could go back to our research findings to re-examine how AI could be best applied to aid content design tasks, and to consider how it could best fit into existing workflows of our publishers to assist them with difficulties they faced. As we continue with internships this summer, we’re excited to re-focus and plan more research to explore some of these emergent opportunity areas. Aligning with in-progress Drupal AI developments, we’re open to learning how we can apply and adopt the work of the Drupal community to our University digital publishing context.

A question has been doing the rounds recently: do we actually need site search?

It’s a fair question and one I have been giving a lot of thought to. With AI-powered summaries increasingly answering queries before users even reach a website, and with navigation that, when it works, can get people where they need to go, it’s reasonable to ask whether a search box is still earning its place.

I want to make the case that not only do we still need it, but that there is more we could be doing to hear what it is telling us, and that in a changing web landscape, the stakes of getting this right are higher than they might appear. This is my take on that question.

The visitors who remain are asking harder questions

AI-powered search, Google’s AI Overviews, Bing’s Copilot, and a growing ecosystem of assistants are increasingly handling the easy, surface-level queries. What are the entry requirements? Where is the main library? When does the term start? Users may well be getting their answers without ever clicking through to a website.

The people who do arrive are doing something more complex. They’re navigating nuance, completing a task, or looking for something specific that a summary couldn’t resolve. They are, almost by definition, higher-intent users, and they are maybe more likely to reach for the site search to find what they need.

This is where the opportunity lives. But there’s a subtler risk worth naming first.

We don’t control what AI says about us, but we control what happens when someone arrives

When a user asks “how much does it cost to study at the University of Edinburgh?” in Google or Bing, the AI summary doesn’t necessarily draw from our content. It synthesises from whatever it finds, and that might include a comparison page from a competitor institution that frames us as the expensive option, or an aggregator working from outdated figures. The user absorbs that framing before they’ve visited us at all.

This matters because users arrive with expectations already shaped. If our site then delivers a confusing, hard-to-navigate experience that doesn’t quickly surface authoritative answers to the questions they came with, we’ve failed twice: once in the AI layer we don’t control, and once on our own platform where we do control the content.

A strong on-site search experience is part of the answer. When users can quickly find accurate, up-to-date information on our platform, in our voice, with our context, we’re not just serving them better. We’re giving them a reason to trust our content over whatever summary brought them here. That matters especially for high-stakes queries around fees, entry requirements, and outcomes, where a third-party framing in an AI summary could genuinely influence a decision.

But here’s the question I keep coming back to: how would we know whether we’re actually delivering that? How confident are we that when someone arrives and searches for fee information, or scholarship options, or how to apply, they’re getting a result that reflects our best, most accurate content and not something buried, outdated, or missing entirely?

That’s where site search starts to feel like something more than a navigation tool.

Site search as a content performance monitor

A search tool you control gives you a feedback loop that no external analytics can replicate. Search logs tell you what people came looking for and couldn’t find through your navigation or from an AI summary. That’s not just useful data, it’s a content audit running continuously, written by your users.

Queries with no good results point towards content gaps. Repeated searches for the same thing might signal a labelling or findability problem. High search volume on a topic you thought was well-covered could mean the content exists but isn’t structured in a way that surfaces it.

Unlike external analytics, which tells you what happened, site search logs can tell you why: what someone was trying to do when they gave up, clicked away, or drilled deeper.

Interrogating both sides of the search

The real power, as I see it, comes from owning the full picture: what goes in, and what comes out.

On the input side, you have user queries, unfiltered, unsanitised, and often surprisingly candid about what your content is missing or getting wrong.

On the output side, you have the results your search returns: which content is being surfaced, how confidently, and whether it’s actually relevant. A query returning weak or irrelevant results is a signal. A query returning nothing is a louder one.

When you can interrogate both ends of that pipeline, you can start to close the loop. You can identify underperforming content before a user gives up on it. You can spot where your taxonomy doesn’t match how people actually talk about things. You can track whether content improvements change what gets returned for a given query. And critically, you can start to test whether your most important content is performing as you’d hope, including the answers to the questions AI is already being asked about you.

This feels like a feedback mechanism that no external tool can give you, grounded in what your users searched for, on your platform, against your content.

There is an argument that site search itself could go further, using ELM to surface AI-generated summaries grounded in our own content, rather than leaving that layer entirely to Google and Bing. But that is a conversation for another post.

Content quality sits at the foundation

Site search can surface problems, but fixing them is a separate conversation, one about content ownership, editorial process, and where responsibility sits. What site search data can change is the evidence base for that conversation. Instead of relying on assumptions about what content is needed, or waiting for user feedback to trickle in, there’s a continuous signal available.

Good titles, clear headings, accurate metadata, and well-structured content aren’t just best practices. They’re what make that signal readable. The better the content is structured, the more faithfully a search tool can reflect what’s actually there, and the more useful its logs become as a diagnostic. It also stands to reason that when AI systems draw on that content, they’re drawing on something accurate and well-framed, rather than leaving the field open to whoever has structured their content better.

Rethinking what success looks like

If AI is handling the top of the funnel, raw session volumes seem to me to be an increasingly unreliable measure of whether a web presence is doing its job. Site search offers a different kind of evidence: did people find what they were looking for? What were they looking for that wasn’t there? Where did the content let them down?

These feel closer to the questions that actually matter, and a well-instrumented site search can start to surface them.

Back to the question

So, do we need site search?

My view is yes, but perhaps not only for the reason you might expect. It’s one of the few tools we control that can tell us, in our users’ own words, what our content is and isn’t doing. When users arrive, already primed by AI summaries we had no hand in, it’s often the fastest route to the authoritative answer we’d want them to find. And without it, we’re largely guessing whether our most important content is performing as we’d intend.

In a web landscape where external signals are becoming less reliable, that feedback loop seems more valuable, not less.

The question isn’t whether we need it. It’s whether we’re actually listening to what it’s telling us.

Last month I was honoured to receive a national award for Outstanding Leadership from industry body UCISA, recognising my work driving positive change through UX. This achievement prompted me to reflect on my experiences leading UX in different realms over the past few years, and to think about what UX leadership means to me.

At the start of 2025 I was asked to step up to a senior leadership position within the global open-source Drupal community. Drupal, the primary content management system used by the University, has a long-standing reputation for being developer-centric and, coinciding with the launch of a new low-code site-building product, they needed help to steer it towards non-technical audiences.

Without thinking too hard, I jumped at the opportunity. I knew it wouldn’t be easy but I was motivated by the chance to use UX as a force for positive change. I didn’t really have much of a plan, but I was confident I could draw on the UX knowledge and experience I had and figure out ways to make things better. Looking back, this represented a milestone in my UX leadership journey and my broader approach to leadership.

I took over running the University UX Service in October 2022. At the start of 2023, I was a UX team of one and I needed to recruit some team members to rebuild and re-establish the service. I was fortunate to be able to bring in some amazingly talented people to work in my team and with their help, and with some successes, failures and near-misses along the way, was able to transform the UX Service into what it is now – a thriving unit delivering sustained value for the University, one improved digital experience at a time. With that behind me, at the start of 2025, I was open to new opportunities to stretch my leadership capabilities. I had accepted that I would get things wrong before I got them right, but I was drawn for the associated learning, which I recognised would help make me become a better all-round leader.

As it turns out, 2025 became quite the year. I won the Women in Drupal Define Award (in October 2025), and the inaugural UCISA Outstanding Leadership award (in March 2026). Taking on the challenge of leading UX in Drupal paid off in more ways than I could have anticipated. Seeing my work bring about positive UX change in Drupal provided me with a renewed sense of purpose in my job leading the University UX Service, as well as in my roles running the UCISA UX Group and contributing to W3C. I’ve boiled down my thoughts on what successful UX leadership looks like for me into three reflections which I’ve turned into action points to take forward as I progress in UX leadership.

UX needs an adaptive leadership approach, and you always need to promote UX value

When I run brainstorms for UX events with the UCISA UX Group committee, ‘Getting buy-in for UX’ is a topic that regularly comes up. How do we get senior decision-makers to invest in UX? Surely making digital services, products and systems more user-centred is something everyone wants?

Well, yes, but it’s complicated. UX can be disruptive. UX research reveals problems, and once problems are unearthed, there’s an obligation to address them, and that requires time, resource and effort which may not be readily available.

Keeping this in mind helps me shape my UX leadership approach. When I’m contributing to Drupal, I take into account that Drupal is a volatile, fast-moving, open-source community, where new ways of thinking and novel ideas are the norm. There is room for UX amongst the many other forces driving change. The Drupal community has autonomy to make changes and is a solutions-powerhouse, ready to react and respond to the needs and demands arising from UX research. Taken together, this mean I can effectively lead UX in Drupal by presenting and talking about UX on a conceptual level, conducting UX research and openly sharing the findings to prompt and rally the community around making user-centred changes.

Leading UX in the public-sector context of the University context needs to be handled differently. Before initiating any UX research activity, I take time to understand the nuances of a situation, to anticipate the context-specific value UX may bring, and honestly assess the resource and commitment required to achieve that value.

The UX Service receives many requests for UX help, but a fraction of the requests we receive are not progressed, meaning digital experiences that could be improved are left unchanged. I recently led a retrospective with my UX team to understand reasons why, and to look for patterns. We concluded that in a number of cases, there is a gulf between people’s expectations of what UX improvement involves and the reality of making improvements happen. This gap is often what causes teams to abandon their UX plans.

This insight shapes how I lead UX at the University. Rather than describing it in purely conceptual terms, I make a point of bringing teams into the practical reality – the sometimes messy, non-linear steps required to achieve improved UX. Leaning on  the persuasive power of word-of-mouth, myself and my UX team take every opportunity to cite and promote successful case studies and testimonials from teams we’ve worked with, demonstrating the real-world value UX brings, and praising teams that choose to apply agency and sustained will to make things better, acting on what they’ve learned from user research.

If you’re going to be a good UX leader, you need to be worth following

As part of her talk at the UCISA Leadership Conference in March 2024, the inspirational rugby player Maggie Alphonsi shared a short video of a person dancing alone at an outdoor event to make a point about leaders and followers. As the seconds ticked by, another person joined the first dancer, and then another and another until a crowd formed. I reflected that being a leader (akin to being the first dancer) is a lonely existence unless people follow you, and that doesn’t come as a given, it all depends on your actions and the impression people have of you, and whether they can meaningfully relate to you.

Since UX is universally applicable, leading it effectively requires more than UX expertise alone. In the service dominant logic model, value only emerges when operant skills (in this case, UX skills and techniques) are applied to operand resources (digital experiences to be improved) through genuine partnerships. Successful partnerships depend on trust and shared understanding, which in turn rest on contextual knowledge and empathy. To lead meaningful UX improvements, I need to retain a constant understanding of what good digital experiences look like, and that means stepping out of the UX bubble to engage with emergent technologies, developing standards, market forces and digital trends.

Distilling down the focus of UX down to ‘making digital experiences better’ leading UX carries a perpetual invitation to innovate, and to seek creative ways of addressing problems. I approach this with a magpie’s mentality – actively scanning to learn about anything that might help me do my job better, whether that’s a change framework, a data modelling tool, an assessment approach. My radar is deliberately wide and I opt not to stay in my lane, always aspiring to grow my sphere of knowledge, influence and connections, motivated by the learning rewards and staying true to the mantra: ‘to get different results, do things differently’.

The breadth of that knowledge pays dividends. As a UX leader, stepping outside familiar territory and taking a genuine interest in different fields puts me in a stronger position to build partnerships across a wide range of spheres — and to respond intelligently to the UX challenges that arise within them. Technology is constantly evolving, as are human needs from it. So I never turn down an opportunity to learn. Furthermore, adopting a humble position of learner means I can absorb knowledge freely, without the constraints of defending expertise I’ve already declared.

Managing and growing partnerships, is of course, just one dimension of UX leadership. In his Driesnote recorded at DrupalCon Chicago 2026, highly-respected Drupal leader (and all-round duderocker and legend) Dries Buytaert reflected on his own leadership journey, describing how his drive and ambition for building and growing open-source Drupal led to him becoming an ‘accidental leader’.  I reasoned that, being an effective leader needs an inherent passion, goal and inner sense of worth, which emulates to others like the energy from the lone dancer, drawing them to follow.

As a UX leader, you’re responsible for shaping future UX leaders

I take my leadership roles very seriously, and I am committed to using my position as a platform to support and encourage widespread adoption of UX approaches and practices. My goal as a UX leader is not just to convince people of UX’s value, but to inspire them to practise it and learn for themselves.

When I was invited as a guest lecturer to speak about running the University’s UX Service to students from the University of Edinburgh Business School, I emphasised the time and effort I devote to building operational capability – in other words, thinking bout the future, and pre-empting needs and demand for improved digital services and developing a strategy to address these in a sustainable way.

A core part of my UX Service strategy is a UX coaching model, built in response to a clear reality – there will always be more user experiences to improve than there are UX professionals to improve them. Coaching others in UX techniques and approaches is an effective way to address the imbalance. When colleagues have the ability to carry out UX research to diagnose UX problems themselves and then apply UX techniques to address them, it’s a win-win. Not only are more  digital experiences improved, problems are caught earlier and UX becomes firmly on the radar.  Democratising UX skills through coaching embeds UX capability, driving a future-state mindset where UX is part of normal software and digital management processes and procedures across the institution.

As well as converting colleagues to the UX cause, there’s the next generations of UX leaders to consider. In summer 2026, the UX Service will continue working with interns and we will grow the number of student workers in our team from three to four. As in previous years, I am excited for the opportunity to support and learn from these emerging UX leaders, to encourage them to bring  their new ideas, provocations and thoughts on how we can do better. Because when it comes to UX leadership, there are always ways to do things better and therefore continual opportunity for motivation and drive.

Here are some photos of my UCISA award and me

I was unable to attend the UCISA Leadership Summit when my award was presented, but it was transported back to me to enjoy and celebrate after the event.

Photo on the left shows the UCISA leadership team and judges with my award for Outstanding Leadership being presented at the Leadership Summit in Liverpool. Photo on the right shows me with my award back home in Scotland.

After Stratos’s blog post last week, I revisited Joshua Mitchell’s experiment asking an AI to simulate what using a screen reader actually feels like, not to replace proper testing, but to generate a transcript of the experience that could be shared with stakeholders who had never encountered one. The results were striking: skip links that went nowhere, navigation menus entirely unreachable by keyboard, and link text repeated identically ten times with no distinguishing context.

Stratos’s post asked whether AI is improving or impeding web accessibility, and ended with an open question to the community: are you already using AI in your accessibility workflows?

I’d just come back from DrupalCamp England, where I’d presented a talk called “Same Image, Different Story”, one I first gave at DrupalCamp Scotland, and will be taking to Drupal Dev Days later this year. It’s a talk I’m deliberately treating as a work in progress, updating it with new thinking and developments each time rather than delivering the same version twice.

And I think I might have part of an answer to Stratos’s question, though it’s more of a diagnosis than a solution, at least for now.

The problem hiding in plain sight

Harvard’s Digital Accessibility Services has a useful guide on writing alt text that includes a section called “Consider the Context.” It shows the same photograph of Hollis Hall used in two different articles. One is about students enjoying the spring weather, and the other is about the building’s famous residents, and it demonstrates that each use case demands entirely different alt text. Same image, different story.

It’s a compelling illustration of best practice and is the cornerstone of my talk. That single example, two articles, one image, two completely different appropriate descriptions, captures the problem more precisely than any technical explanation I could give. But it also quietly exposes an architectural gap: most content management systems, including Drupal, the platform that powers the University of Edinburgh’s EdWeb 2, don’t give editors anywhere to act on that guidance. The image gets a single alt text field. One description, stored once, is applied everywhere the image is used. An article about student life. A seasonal blog post. A facilities page. The same text, regardless of which detail is editorially significant in each context.

This isn’t a quirk of how one editor set things up. It’s a fundamental constraint of how Drupal’s media architecture works. And the consequences reach further than you might expect.

The anti-pattern that reveals the problem

When Drupal introduced the Media Library, it was framed as a shared asset pool designed to encourage image reuse and reduce duplication, and the intent was good. Upload once, use everywhere. But what we’ve observed in practice is editors quietly working around it: uploading the same image multiple times under different filenames, just so they can have different alt text, or set a different focal point, for different editorial contexts.

The platform designed to reduce duplication is inadvertently encouraging it. That’s a significant signal. When users consistently work around a feature, it usually means the feature doesn’t match how they actually need to work.

Where does AI fit into this?

Stratos’s post noted that AI-generated alt text is improving, but inconsistent, and the W3C’s own work on machine learning accessibility is honest about the gap. A bar chart described as simply “a graph with coloured bars” versus one that explains the data in full is the difference between access and exclusion.

There are already Drupal community contributions that tackle this, and they’re genuinely promising. AI may be able to offer a better first draft of alt text to editors to update manually, especially under time pressure.

But here’s the thing that my talk kept circling back to: even if AI could generate better alt text, Drupal has nowhere contextual to put it.

If the media architecture only supports one alt text value per image, then it doesn’t matter how good the AI generation is. The result still gets flattened to a single description, applied in every context, whether it’s appropriate or not. You haven’t solved the accessibility problem; you’ve just automated the production of the wrong answer, faster.

There’s a further constraint worth naming, too: current AI alt text tools work from the image alone. They don’t read the surrounding page content, the article headline, the body copy, or the editorial context, so they have no way of knowing whether the focus should be the students, the architecture, or the changing seasons. The next step in making this genuinely useful is finding ways to pass that subject matter to the AI, so it can generate alt text that’s not just accurate, but relevant to the specific editorial context it’s being placed in.

A practical step we could take today

There’s something worth drawing from Joshua Mitchell’s experiment here. He didn’t ask AI to fix the screen reader experience; he asked it to describe it, making an abstract problem visible and actionable.

We could apply the same thinking to alt text validation. Rather than waiting for the architecture to catch up, AI could be pointed at an existing page and asked to interrogate it: does this alt text accurately describe the image? Does it make sense in the context of this article? Is it serving the reader, or just technically present?

That’s a use case that’s achievable right now, without any changes to how Drupal stores media. And given that EdWeb serves over 600 subsites with around 1,500 editors, the ability to audit contextual appropriateness at scale, rather than relying on individual editors to self-assess, could make a meaningful difference.

The question I’m sitting with

The more interesting challenge, and the one I’m actively exploring at the University, isn’t “can AI write good alt text?” It’s “can we build an architecture where AI can write the right alt text for a specific editorial context, and can the CMS preserve and serve that appropriately?”

That feels like a genuinely solvable problem. The Drupal community is already moving in the right direction with contributions that allow editors to override media properties per-use rather than per-asset. Pair that with AI-assisted generation, editorial context passed as subject matter, and human review, and you start to have something that could meaningfully improve accessibility at scale, across a platform serving over 160 environments and more than 600 subsites, as EdWeb does.

This is part of a broader piece of work I’m developing at the University around AI editorial assistance, focused not on generating content, but on helping editors make better decisions: style guide compliance, accessibility checking, and contextual awareness. It’s early days, but the alt text problem feels like a good place to start.

To borrow Stratos’s framing: keeping the human in the middle means making sure the human has the right tools to make contextually appropriate decisions, not just faster ones. I’ll be updating this thinking as the talk evolves, and as the work here at Edinburgh develops. If anyone else in the Higher Education community is thinking about this, I’d love to compare notes.

Drupal is the University’s content management system and Drupal CMS – its new ready-to-use site-building product – is developing apace. As Drupal UX Research Lead, I’ve used concept testing to gather quick insights that keep interface decisions user-focused and keep development moving.

As part of the Drupal CMS leadership team, I take responsibility for improving Drupal’s UX based on findings from user research. In this blog post, I reflect on how I’ve adapted my research approach to ensure we have evidence to hand ready to guide rapid, iterative product decisions at the interface level, while remaining faithful to the overarching product goals.

Ensuring UX research informs agile product development is a well-known challenge

I first grappled with fitting UX into Agile as UX Lead on the University’s Web Publishing Platform (WPP) project. Defining a UX and Design process to keep the project focused on user needs prompted me to think about how UX research and development complemented each other and the need for data-based feedback.

Dual-track Agile emerged as a good way to align the disciplines – with a UX strand focused on continuous discovery around tasks feeding into a staggered development strand focused on defining features.

Diagram depicting the dual-track Agile process, adapted a diagram by Jeff Patton, from his book ‘User Story Mapping: Discover the Whole Story, Build the Right Product’

When I considered how to implement this in Drupal, I realised the importance of defining a prioritised list of user tasks to act as the target for research and therefore the basis for future feature development.

In September 2025 I blogged about three key task areas on my shortlist for Drupal CMS UX improvement. These included:

1. How people make sense of Drupal interfaces through the Drupal labels on different features and functionalities
2. How people maintain and extend their Drupal sites, to keep things up-to-date and add in extra functionality
3. How people use Drupal AI functionality in a range of contexts within Drupal sites

Keeping these broad task areas front-and-centre helped me remain clear on our research priorities, to ensure I gather appropriate data to pass to the development strand to inform the ongoing build and configuration of the Drupal CMS product.

Read my earlier blog post about aligning UX and Agile:

Making Agile and UX work together – reviewing the UXD process for the Web Publishing Platform project

For the long-term, the Drupal CMS product strategy keeps high-level priorities in focus

When working in tight development cycles, concentrating closely on shaping a product, it is easy to get lost in the small decisions and lose sight of the wider product purpose. When Drupal CMS began (initially as Drupal Starshot), it was launched with a product strategy. Using the framework from the book ‘Playing to Win: How Strategy Really Works’ by A.G. Lafley and Roger L. Martin’ the strategy set out:

• Our winning aspiration: Putting the power of Drupal into the hands of marketers, content creators and other non-technical users
• Where we will play: Focusing on marketers, targeting organisations in the mid-market segment
• How we will win: Prioritise ease of use, ability to grow and scale, directed use of innovative technologies (such as AI) towards marketer and content creator use cases
• The capabilities we must have: interfaces that are intuitive for non-technical audiences, out-of-the-box marketing and content creation capabilities, and simplified ways to extend site functionality

Keeping points of the product strategy front-and-centre has been essential for me to ensure I design the right research approach, to enable learning about what’s most important in the least amount of time to unblock technical development decisions. It has also helped me remain grounded when working in a constantly-changing development environment.

Read more about the initiation of Drupal CMS in my blog post from 2024:

UX leading the newest developments in Drupal – a mindset shift for Drupal CMS

Read more about Drupal CMS in the Drupal CMS product strategy (on Drupal.org)

Read my post from September 2025 setting out the research priorities for Drupal CMS:

UX leadership in open-source Drupal: Insights, lessons and future aspirations

In the short-term, Drupal interfaces can be constantly changing

As content management systems go, Drupal CMS is no ordinary product. The fact that it is an open-source product means the pace of development and innovation associated with it is particularly rapid and changeable as it can be shaped by an ecosystem of factors in a dynamic global community.

Most recently, innovative solution opportunities have arisen due to the development and launch of Drupal Canvas (Drupal’s newest visual page builder). The launch of Drupal Canvas in November 2025 signalled a new approach to creating and handling content in Drupal, and was a perfect fit for Drupal CMS given the target audience of marketers and content creators, therefore it was added into the v2.0 release of Drupal CMS.

Referring back to my three prioritised task areas, the inclusion of Drupal Canvas in Drupal CMS brought considerations of Drupal interfaces to the forefront. I identified the need to understand how target audiences would make sense of Drupal features and functionalities based on how they were presented in Drupal CMS.

Read more about Drupal Canvas within Drupal CMS in the announcement of Drupal CMS 2.0 on Drupal.org

Concept testing gathers user insights quickly, to support a fast pace of development

Given the rate of change in Drupal, I realised I needed a fast way to seek user feedback on interface designs, so I could feedback findings while development was in flight. Concept testing is a research technique deployed to test product ideas to assess whether they are worth progressing, to sense-check understanding of content and interaction patterns, and to gauge how people instinctively react to interface layouts and arrangements. This approach follows the Lean UX methodology – doing the least amount of work to learn the most important thing – and is particularly valuable in new product development, to avoid wasting effort and time developing solutions or heading in directions which may not align with user expectations.

Access the Lean UX Canvas (Jeff Gothelf)

By continually capturing ideas as visual mock-ups, I’ve built up a bank of concept testing material

Drupal’s flexibility lends itself to experimentation and many ideas and concepts arise from people setting up a Drupal instance and playing with the functionality it provides. Following the progression of Drupal innovations I have started the habit of collecting screenshots of the concepts being mooted on the fly. As things progress, I have been able to use prototyping and wireframing to turn the screenshots into visual representations for test participants to look at. Developing appropriate test scenarios around these visuals, I have been able to run quick online sessions with test participants to gather insights to feed into ongoing development.

Findings from my concept tests with users have provided direction in ambiguous circumstances

Over the past 6 months, I’ve completed multiple rounds of concept testing, drawing on my network of contacts for help shaping appropriate scenarios and recruiting participants that match the Drupal CMS target audience. In some cases, the sessions have focused on engaging participants around a single concept (sometimes referred to as monadic testing), in others I have asked participants to view multiple concepts in sequence to make comparisons and contrast.  My test findings have helped guide Drupal CMS interface choices in changing circumstances – I’ve summarised a selection of the learnings and the decisions made.

Changing the label ‘CMS’ to ‘CMS Content’ will improve understanding while we work out the wider architecture

Drupal Canvas was included in the release of Drupal CMS v2.0, however, it was not technically feasible for Canvas to replace the form-based node-editing content interface traditionally found in Drupal. Therefore, in v2.0, both types of content creation mechanism needed to be present and it was unclear of the best way to present these options, recognising that the architecture could change. Distilling the different possibilities into a series of mock-ups, I ran several tests to find out which made most sense to users. One test sought to discover whether the label ‘Pages’ to access the Drupal Canvas editing interface and the label ‘CMS’ to access different content types was something users would understand.

In a test scenario, I asked participants to imagine they were responsible for a website and needed to look at content that had been published to review it. I presented them with the mock-ups and asked them to talk through what they would expect to find by selecting the different options in the left-hand menu. When they had described their expectations, I showed them what they would actually find, in order to check alignment.

Results of the test revealed that participants associated ‘Pages’ with an editor for individual pages, indicating that it was an acceptable label for entry into the Drupal Canvas editing interface. Participants were less clear of what to expect by choosing ‘CMS’, and they did not associate it with content. When they saw the content types they would find by selecting this label, they grasped the concept. These findings affirmed ‘CMS Content’ would be a better signifier for users, at least in the short term until bigger architectural decisions were made.

Screenshot of Drupal CMS showing the ‘CMS’ label and the screen that appears once ‘CMS’ is selected

Removing icons  for menu labels will reduce ambiguity and cognitive load

As the test participants analysed and commented on the different menu labels, I took the opportunity to seek their interpretation and understanding of the icons associated the labels themselves. There was no clear consensus on the icon meanings from the participants, therefore the decision was made to remove the icons in the interim, to avoid unnecessary confusion or misinterpretation.

Screenshot showing the different icon options for the ‘Pages’ and the ‘CMS’ menu labels

Removing ‘Create’ will make the menu options simpler in the interim

In the same series of tests probing users’ understanding of the labels for the different content options, I asked test participants when they thought they might choose the ‘Create’ option compared to the ‘Pages’ and the ‘CMS’ options. From their responses, it emerged that they were unclear when they would choose ‘Create’, signalling that this label was a ‘nice to have’ rather than a necessity. In the interests of decluttering the interface and making it easier to access content options, this label was removed.

Screenshot showing side-by-side Drupal CMS dashboard designs, the one on the left has the ‘Create’ menu option (outlined in red), the one on the right has the ‘Create’ menu option removed.

Using a vertical arrangement of filter options provides more flexibility than an horizontal layout

Engaging participants further in the test scenario, I sought to gather their preferences for finding content using the Drupal CMS interfaces. By questioning them about their usual search and filtering approaches, it became clear that there were many different facets and factors they could draw on to find content. It became clear that arranging these in a horizontal way would lead to unsightly wrapping and a clunky interface design, which prompted a decision to opt for a vertical filter arrangement.

Reflection: Concept testing is delivering strong returns for minimal effort

Findings from my short series of experiments demonstrate the value and usefulness of concept testing as a research approach, and I am keen to apply it in more areas of my work. The ease with which it can be executed highlights it as an excellent entry-level UX research technique, and as such I am especially motivated to work with both technical and non-technical colleagues in the community to coach it so that others may realise the benefits for themselves.

On the last weekend of February, I made the trip to Salford for DrupalCamp England 2026. It is only its second year, but already an event I have found myself looking forward to returning to. I came away with a notebook full of ideas, some genuine food for thought about the direction of AI, and a renewed appreciation for what these community gatherings actually provide.

My talk: Same Image, Different Story

I co-presented “Same Image, Different Story: Why Drupal Needs Contextual Architecture” with Tony Barker. The talk grew out of an investigation into AI-assisted alt text generation in Drupal. It evolved, specifically, from the discovery that properly accessible shared images aren’t straightforward to provide. Without sufficient contextual information, AI-generated alt text tends to be descriptive rather than meaningful. A technically correct description of an image is rarely the same thing as an accessible one. The talk illustrates this with a deceptively simple example: the same image can represent entirely different things depending on context, and the alt text should reflect that choice rather than just the image itself. The same photo of Shaun Ryder, for instance, could have been used because he’s the frontman of the Happy Mondays, because he’s from Salford, or because he was at the Brit Awards, happening just down the road that same day. Three very different reasons that each require a different alt text. The talk unpacks how an architectural gap in Drupal affects accessibility compliance, editorial workflows, storage efficiency, and media management across complex platforms. The discussions it sparked afterwards were well worth the journey south, with plenty of conversation around how AI could potentially be part of the solution.

The Keynote: Augmented, Not Artificial

Dr. Phininder Balaghan delivered the keynote, “The Augmented Future: Winning with AI,” and it set the tone for much of the day’s conversation. The central argument was a reframing: stop thinking about Artificial Intelligence and start thinking about Augmented Intelligence. The distinction matters. The companies genuinely winning with AI aren’t the ones that replaced their engineers with it. Klarna, being perhaps the most cited example, had replaced 700 employees with AI before quality declined, customers revolted, and they found themselves hiring engineers again. The productivity gains are real, but they flow to skilled people, not instead of them. Tools amplify human expertise; they don’t substitute for it. As someone building AI-assisted workflows here at the University, this framing resonated strongly. Though it’s worth noting that the human cost for those caught in the middle of these experiments is often more complicated than the optimistic retelling suggests, which made Antje Lorch’s session later in the day feel like a necessary and timely counterpoint.

With three tracks running in parallel in places, there were some tough choices to make throughout the day, and I’ll admit that on at least one occasion I found myself in a talk I hadn’t actually intended to go to, a hazard of being so engrossed in a conversation that I simply followed the crowd through the nearest door. But that’s arguably the point. Some of the most valuable thinking at events like this doesn’t happen in the lecture theatre at all; it happens in the corridors, over coffee, and in those animated discussions between sessions where ideas get challenged, refined, and sometimes born entirely. The fact that there were videos recorded and released later is something I am so glad about, not least to catch the sessions I missed, planned or otherwise. Antje’s talk was one of the casualties of that scheduling conflict, however.

We Need to Talk About AI (The One I Missed)

As I said, unfortunately I didn’t manage to catch “We Need to Talk About AI” in person, but after the questions the keynote left rattling around in my head, it’s firmly on my watch list when the video appears. From the description alone it covers ground I think is really important: the environmental and energy costs of AI, the effect on global chip markets, and the implications for people in vulnerable situations who depend on services increasingly shaped by these tools. In an open source community that prides itself on values, this is exactly the kind of session that belongs at a DrupalCamp, and as someone actively building AI-assisted tools at the University, I think it’s worth sitting with those questions rather than just pressing ahead with enthusiasm. More to say on this once I’ve watched it, but it also makes me genuinely glad of the hard work going on to provide ELM.

Other Highlights

A few other sessions worth calling out. James Abrahams showcased the Flowdrop UI for Agents module, a no-code visual AI agent builder for Drupal CMS that allows anyone to build AI agents, using an AI agent, which feels like a glimpse of where things are genuinely heading. If you’ve ever seen Jamie speak, you’ll know that his talks are as much an experience as a session, his passion for the projects he champions is infectious, and it’s genuinely hard not to get swept up in the enthusiasm. Whether the technology delivers everything he promises is a question for another day, but you’ll leave the room believing it will.

Maria Young’s session on keyboard traps, focus failures, and ARIA fixes was a practical deep-dive into the accessibility edge cases that catch even experienced developers off guard.

It was also great to spend some time with University colleagues during the day, Emma Horrell gave an update on Drupal CMS covering what’s shipped, what’s coming, and the UX research driving it, while Aaron McHale presented “Growing a Team to Transform a University Website” alongside James South from manifesto, covering their multi-year collaboration to deliver a new student-centred web presence for the University of Edinburgh, and one well worth sharing with a wider audience.

People and Community

Beyond the sessions, it’s the people who make these events worth attending. Catching up with old colleagues, reconnecting with former clients from my agency days, and meeting new people who share the same passion for open source and the web. The conversations that carry on over a drink at the BrewDog social in the evening, for example, are often where the most honest and unguarded thinking happens. These are the moments that remind you why the Drupal community is something worth being part of.

Drupal in a Day (Sunday)

Sunday for me was given over to the Drupal in a Day training session, which I helped facilitate. It is a structured, hands-on introduction to Drupal for newcomers, and a genuinely excellent format, and I’m already hoping to bring it to Edinburgh. The logistics of how to run it here are in progress, and the next step is making the case properly. I hope to be able to demonstrate its value and articulate the benefits for a local audience. Beyond onboarding our existing interns, I can see real potential in opening it up to prospective interns too, by giving candidates a meaningful taste of the platform before they ever apply. Those who engage well self-select, arrive already sold on Drupal, and hit the ground running from day one. It becomes less of a training day and more of a pipeline: attracting the right people and filtering out those who aren’t the right fit, before either side has made a significant commitment. And with DrupalCamp Scotland on our doorstep, there’s an obvious opportunity to run it there too, reaching an even broader pool of prospective talent while giving something back to the local community. Who knows, maybe some other staff members will want to get involved, too. Watch this space.

The Bigger Picture

What started as a single day in Cambridge last year has grown into a full two-day programme, and the community energy that filled the venue was a reminder of why these events matter. If you’re a Drupal developer in the UK, or want to visit the UK, and you haven’t been to one yet, put DCE 2027 in your list of things to look out for next year.

Six months ago I joined the Web Development team at the University of Edinburgh. I know Drupal well, but I also know it’s like a huge bag of Lego bricks, its power lies in how those bricks have been assembled, and every codebase assembles them differently.

Testament to those who came before me, EdWeb 2 is a remarkable feat of engineering. One codebase running across over 160 environments, serving more than 600 subsites, curated by close to 1,600 editors. Getting up to speed quickly meant finding a way to navigate that complexity without getting lost in it.

Where AI proved its worth

When you’ve worked in Drupal for a while, you develop instincts. So when one of our environments started reporting slow load times, I had a hunch: somewhere, a block cache or menu cache wasn’t being set correctly, meaning every page visit was being built fresh from the server and database rather than served from a fast cached version.

The telltale signs were in the response headers for anonymous users:

x-cache: MISS, MISS, MISS, MISS and x-cache-hits: 0

I knew something was setting cache-control: max-age=0

A straightforward search of the codebase turned up nothing. This is where AI really earned its place. I described the problem, and the tool went to work scanning lines of code far faster than I ever could.

After several searches, we got there. A piece of code was, in certain circumstances, failing a check and returning false. When applied to the cache control setting, that false was being treated as 0.

This effectively switched caching off. The variable wasn’t being set to the wrong value; it wasn’t being set at all.

A targeted fix, a bit of defensive programming, and the problem was resolved. While AI helped locate the issue, the diagnosis and the fix were mine. Could I have found it manually? Eventually, probably. But describing the problem in plain language and having AI work out what to look for saved hours, if not days of scouring the codebase.

Of course, there’s no substitute for getting deep into the codebase over time, and that’s very much still the plan. But problems don’t wait for new team members to find their feet, and having AI as a tool to bridge that gap means issues can be tackled with confidence while that deeper knowledge is still being built.

The uncomfortable side of AI

I’ll be honest, I’m an advocate, but also a sceptic. I’ve been reading about the energy and water consumption of large AI data centres, and it’s hard not to feel conflicted. A data centre the size of Manhattan isn’t an abstract concern, there seems to be a real cost that sits behind every query.

The Drupal community has some vocal voices on this too, and I find myself nodding along even as I reach for these tools. That tension hasn’t gone away.

Part of that discomfort was closer to home than data centre emissions. Commercial AI tools had made themselves very easy to reach for, but reaching for them felt at odds with what I actually wanted to be doing. I knew ELM was the right choice, it just took more effort to get into my workflow. So rather than defaulting to the convenient option, I found myself holding back, using AI more sparingly than I might have otherwise.

Getting ELM Onside

The recent University’s AI Town Hall was exactly the energy injection I needed. A conversation with Andrew Hayward was the spark, hearing that others across the university were already making progress coding with ELM gave me the push to try again. Bart Pohorecki then pointed me to Codex CLI, which can be configured to work with an ELM API key, and a bit more digging led me to Codex CLI launcher built for PhpStorm. Suddenly ELM was running directly inside my IDE, with access to the codebase and no files being sent to unrestricted external services.

The result is a setup that feels like a genuine step forward: the productivity benefits I’ve come to rely on in my community projects, with considerably less of the guilt. Using a University-backed model feels meaningfully different, the privacy guardrails and University oversight address enough of the concerns that had been giving me pause.

I’m still at the early stages of exploring what ELM can do in this context, but I’m genuinely optimistic. If you’re curious about getting set up with Codex CLI and the PhpStorm plugin, feel free to get in touch, I’ll be happy to share what I’ve learned so far.

It’s also a reminder of the value of events like the AI Town Hall, tech conferences such as Scottish Web Folk, and community gatherings like DrupalCamps. They’re not just opportunities to learn what others are doing, they’re a way to recharge your own thinking and find the motivation to push past the inertia that can build up around good intentions and get some much needed excitement of experimentation.

Back in November (yes, I know — this post is fashionably late), I attended Drupal Camp Scotland on 7th November 2025. It was a full day of interesting, insightful and genuinely useful talks. From the moment I arrived, greeted by friendly faces over morning coffee – there was a strong sense of community. 

As my years working with Drupal add up, I’ve found myself thinking more about how I fit into this community. I spent around 20 years as a Graphic Designer, and during that time I dabbled in Drupal, theming and site building. It wasn’t until I joined the Web Development Team almost exactly six years ago that Drupal became my day-to-day focus. I think I’m finally starting to feel comfortable calling myself a “Web Developer” — and events like this definitely help with that. 

As the title suggests, connection felt like the main theme for me. Yes, connecting with other people in the Drupal world, but also connecting with the topics being discussed. Out of the nine presentations, there were three in particular that lined up closely with work I’m involved with right now. 

1. Using Storybook to Preview Single Directory Components

As part of my work exploring Single Directory Components (SDCs) and how we can integrate them into our platform, I was already familiar with Phil Norton’s (Web Developer at Code Enigma) article on the subject. I had previously followed his guide and had good results, so seeing him present the topic in person was incredibly valuable. 

SDCs give us a self-contained, tidy way of organising components and keep us aligned with Drupal’s long-term plans. Since they’re going to be part of Drupal Canvas, this direction makes sense for the future of theming in EdWeb. 

While the Web Development Team doesn’t maintain our pattern library EdGel, every now and then we need components that don’t yet exist. Storybook could make those situations much easier by giving us a way to build, preview and test components quickly — and maybe even offer editors a preview before they use components on their sites. 

Phil’s talk provided a great recap of the value of SDCs and offered practical insight that will feed directly into our ongoing investigations.

2. Same Image, Different Story: Why Drupal Needs Contextual Media Architecture 

As a primarily frontend developer, this talk caught my attention immediately. I’m currently working on a large piece of work around how images are used across our platform — from performance and quality to accessibility and editorial experience — so the timing was perfect. 

Gareth Alexander (from our own team) and Tony Barker (Annertech, LocalGov Drupal and more) raised really important points about how Drupal handles media. For example: 

• Drupal stores a single alt text value per image — but what if an image needs different alt text depending on where it’s used? 

• Can we store multiple focal points for different contexts? 

• How do we improve the editorial experience around this? 

These are questions we’ve been hearing from our own users, so it was encouraging to see others thinking about the same issues. Since Gareth sits just a few desks away, I’m sure I’ll be asking him a lot more about this! 

3. “So… I heard we don’t need junior devs anymore now that we have generative AI?” 

Hilmar Kári Hallbjörnsson delivered this talk with so much energy that it was hard not to be completely pulled in. He spoke about teaching Drupal to university students, so they graduate with the skills junior developers actually need. He teaches a course called Developing Open-Source Web Software, with PHP and Drupal, and with the help of others started the Drupal Open University Initiative to share teaching materials with other teachers. 

As someone who works closely with students this really resonated with me. We take on two 12-month placement students every year, plus internships, and I enjoy supporting and mentoring the students. They always bring so much enthusiasm, curiosity and a willingness to dive into challenges. Many have gone on to Drupal roles after working with us, which is great to see. 

Hilmar’s message was clear: AI can support development, but it cannot replace the creativity, critical thinking and collaboration that junior developers bring to a team.  

The human side

I’ll finish off by mentioning Jochen Lillich’s presentation, “GenEI over GenAI – The Human Side of Website Delivery,”. His focus on empathy — on the humans at the heart of everything we build — struck a chord with me.  

Coming from a design background, thinking about audiences, tone and voice is natural for me. But at the university, our “audience” isn’t one neat group — it’s editors, site owners, staff, students, parents, guardians… all with different needs. As developers, it’s easy to focus on the technical side and forget the bigger picture, so I appreciated this reminder. 

Drupal Camp Scotland 2025 was a great mix of inspiration, reassurance and community spirit. It highlighted the technical challenges we all share, but more importantly, it reminded me how human our work really is. 

On the podcast today we have Chris Reynolds.

Chris is a developer advocate at Pantheon, where he brings nearly 20 years of experience in the WordPress community, as well as deep involvement with Drupal and open source technology at large. Prior to his advocacy role, he worked at some of the top WordPress agencies like Human Made and WebDevStudios. He’s been active at events like DrupalCon, PressConf, and WordCamps.

In this episode, we set aside the usual WordPress-only focus, and turn our attention to two CMSs, WordPress and Drupal, what makes them tick, where they excel, and where they might have something to learn from each other.

Chris draws on his unique perspective working closely with both platforms, as Pantheon is one of the few hosts with a 50/50 split between WordPress and Drupal sites, and has a significant footprint in both ecosystems.

We discuss the similarities and differences between the two open source CMS communities, from the mechanics of flagship events like WordCamps and DrupalCon, to the ways these projects organize their contributors and support community initiatives.

Chris explains how Drupal’s model, with its association-run funding and project governance, compares to WordPress’s approach, including how each community approaches plugin and module development, and what role agencies and companies play in contributing to Core and the broader ecosystem.

If you’re curious about how open source projects organise themselves, how their communities navigate growth and challenge, and what WordPress can learn from Drupal (and vice versa), this episode is for you.

Useful links

Pantheon

 Ampache

 DrupalCon

PressConf

 WebDevStudios

 Human Made

 Acquia

 Dries Buytaert

 Automattic

Solr

 Elasticsearch

 Composer

 Chris on a previous episode of the WP Tavern Jukebox podcast talking about Composer

 DrupalCamps

Solving the Maker-Taker problem

 Dries Notes – State of Drupal presentation (September 2024)

 Drupal Association

Drupal  Yoast module

Drupal CMS

Drupal Views

Gravity Forms

Five for the Future