In this post, User Experience team intern Hannah Watson shares her work over the summer researching digital content accessibility with the EdWeb 2 publishing community.

Introduction

As part of my internship with the User Experience Service, I have been investigating digital accessibility at the content level across University web pages, particularly on EdWeb 2 sites. Digital accessibility at the content level is about applying principles of accessibility to how web content is written and formatted. This includes, but is not limited to, content features such as heading levels, links, and alt text. It does not include anything that is not involved with content design or that is controlled at a higher level by the Content Management System (CMS), such as font, font size, or colour contrast.

Research aims and scope

The specific research questions for this project were:

• How do web publishers learn about digital content accessibility?
• What do web publishers know about digital content accessibility?
• How do web publishers implement digital accessibility requirements and principles in their content?
• What challenges do web publishers face in creating digitally accessible content?

More comprehensively, I was investigating the accessibility of:

• Heading levels
  • Ensuring that heading levels are used correctly
  • Not using heading levels for emphasis
• Links
  • Clear and concise link text which describes the linked destination
  • Link text which makes sense on its own
  • Avoiding URLs on web pages
• Lists
• Alt text
  • Clear link text that describes the image
• Images
  • Ensuring that all images have appropriate alt text
  • Avoiding images of text
• Videos
  • Including human-corrected captions with any videos uploaded to web pages
  • Making sure that transcripts are available for all videos uploaded to web pages
• Italic, bold, and underlined text

For more detailed guidance on these topics, please refer to the University of Edinburgh editorial style guide.

Editorial style guide | Information Services

This research has been necessary for the User Experience team as it allows us to identify which areas of content accessibility are challenging for web publishers. From this, the team can adapt guidance and training to provide extra support on these more challenging areas where possible.

Research methods

Interviews with web publishers

I started my research by setting up short, informal interviews with six University web publishers. In these interviews, I asked the publishers about their experiences of creating digitally accessible content. The aim of these conversations was to understand how publishers learned about digital accessibility and what challenges they face when making content as accessible as it can be. During the interviews, we referred to web pages that these publishers work on to get concrete examples that illustrate the topics we discussed. Through these interviews, I was able to identify a number of trends, particularly in the challenges that the interviewees and their colleagues face.

Survey of EdWeb 2 publishers and the Web Accessibility Special Interest Group

Following these interviews, I created a survey to further investigate the findings and collate more supporting evidence for these findings. The survey consisted of 10 questions, three of which were demographic based as a filter, with a final question asking permission to follow up with those who responded.

The other six questions asked about:

• which actions the participants took to make their content digitally accessible
• what resources they used to do so
• what challenges they face in doing so

The findings from the survey were effective in making the information gathered in interviews more robust and provided further evidence for some trends that were identified previously.

To publicise this survey, I sent a brief statement explaining my research into two Teams channels, the Web Accessibility Special Interest Group and the EdWeb 2 Community. Overall, the survey received five responses, and while this is a limited number, I found that it helped to support the findings from the interviews.

Analysis of Effective Digital Content workbooks

The final method of research that I used to learn about the digital accessibility of content on University web pages was by looking at pages that were submitted within Effective Digital Content workbooks as part of the course. The course requires learners to choose pages from a University website and assess the effectiveness of the content. By looking at the pages that learners selected, I was able to use active examples and make note of content accessibility issues that were present on live pages. This process also highlighted a number of trends.

This method of research was also useful in that it provided two separate sources of data. Firstly, the answers in the workbook helped me to gauge learners’ understanding of the principles covered in the course. Secondly, the web pages linked by those taking the course allowed me to have live examples of content to assess against content accessibility principles. While there was not necessarily overlap between the answers in the workbook and the pages submitted as part of the workbook (as some people may not have been fully or at all responsible for the content on those pages, or the content could have been updated since the workbook was submitted), it was useful to see these things separately.

Findings about accessibility

Combining findings from all areas of research for this project, I have identified a number of trends in the accessibility of digital content.

Headings, alt text, and links are the principles most often put into practice by participants

In the interviews and the survey, participants were asked what principles of accessible digital content they actively used when designing content. More than half of participants mentioned three principles in particular, with all participants mentioning at least two, which were:

• using the correct heading levels
• adding meaningful alt text to an image
• writing clear and descriptive link text

Interestingly, while these principles were mentioned frequently by participants, and evidenced by the websites that we discussed in interviews, they are also principles that are often missed on University web pages. This is discussed in more detail in the corresponding sections further on in this post.

PDFs are hard to avoid

One standout finding from the interviews was that web publishers sometimes struggle to find an effective alternative to PDFs. While PDFs are not necessarily accessible, they do have benefits which make them useful for publishers. For example, they are downloadable, searchable, and cannot be easily edited without permission from the owner. There are ways to make PDFs more accessible, such as avoiding decorative images, adhering to accessible content design principles within the PDF, and checking colour contrast. However, the interviewees were more in favour of finding a way to turn their content into a webpage as this is more likely to result in accessible content.

Out of the survey responses, three also mentioned that they had recently chosen to publish content as a web page rather than as a PDF, highlighting their knowledge that a web page is preferable in terms of accessibility. However, their personal preferences or how difficult they found this is unknown as I was unable to follow up with these participants.

Heading levels are often skipped and headings vague

Across web pages that I assessed for correct heading levels, there were several which skipped heading levels throughout the page content, such as going straight to a heading 3 without that heading being nested within a heading 2 section. Additionally, headings on the University web pages that I investigated were often generic, instead of being specific about what a page or section will contain, which is the recommended approach.

The fact that the web publishers who were interviewed and surveyed were aware of the importance of correct headings levels and specific headings, and that the majority of these publishers have attended a staff training or used the editorial style guide, suggests that the guidance provided is accurate and useful for publishers.

To increase the use of correct heading levels, as well as clear and descriptive headings on web pages, participant responses suggest that increasing the reach and engagement of existing training and resources involving headings would be effective. This includes training provided by the User Experience Service, such as Effective Digital Content or Content Improvement Club, and the University of Edinburgh editorial style guide.

Alt text is well written but sometimes missed

In three of the interviews, and in two survey responses, participants mentioned that they struggled to find the time to add alt text to images on their web pages. However, participants in the interviews also stated that they understood the importance of alt text, and what writing meaningful and clear alt text involves. This is reflected in the answers in Effective Digital Content workbooks. The course contains a question asking learners to write meaningful alt text for two images, and this question is often answered well. This suggests that web publishers understand how to write alt text, and that the obstacle in doing so is more likely to be related to time and resource.

One way that time constraints on adding alt text could be improved is to reduce the number of images on a web page, which will not only make this task more manageable but also is also more sustainable.

Explaining acronyms and abbreviations is common

All five responses to the survey stated that they had explained an acronym or abbreviation recently. Although this did not come up in the interviews often – only once – the survey responses suggest that this is common practice for web publishers who are familiar with digital accessibility principles.

Link text is frequently inline or not descriptive

Participants stated that they understand the importance of clear link text as a principle and make effort to implement this into their content. However, similar to headings, this sentiment is not reflected across numerous University web pages. In some of the pages submitted as part of the Effective Digital Content workbooks that I investigated, there were frequent occurrences of inline link text, or link text that does not clearly describe the linked destination.

To increase the writing of link text on a separate line, as well as clear and descriptive link text, participant responses suggest that increasing the reach and engagement of existing training and resources involving links would be effective. This includes training provided by the User Experience Service, such as Effective Digital Content or Content Improvement Club, and the University of Edinburgh editorial style guide.

Findings about staff experience and engagement

A trend from both the interviews and survey responses is that for many of the people involved with this research, their knowledge of digital accessibility started with a personal interest. Specific examples of this that participants mentioned include learning about accessibility as a student (and then going on to be an accessibility advocate for a student society) and working with disabled students and learning through experience.

During the interviews, multiple staff members mentioned that they believe, through their experiences, that a large part of issues with creating accessible digital content at the University surrounds communication. A combination of factors was discussed that had communication at the centre, including:

• the importance of digital accessibility not being widespread enough.
• consistency about expectations between schools or areas of the University, such as one page being edited by multiple schools or areas and having different standards.

Job-based constraints were also mentioned frequently, such as limited time to add alt text to all images on a web page and working on a page where the lead publisher takes a design forward approach which can sometimes clash with accessible content principles. These answers were also reflected in the survey responses, with all of the responses mentioning either one or both of these problems.

What resources do web publishers use for learning about and developing their digital accessibility skills?

The primary resource that participants mentioned using to learn about digital accessibility and develop their skills was University-provided staff training, with 10 of 11 participants mentioning this. Effective Digital Content was specifically mentioned twice, and Content Improvement Club three times. In the interviews, two participants mentioned more general staff training, with one survey response saying the same. In the survey responses, three participants also said that they used training provided by the Disability Information Team.

The Web Content Accessibility Guidelines 2.2 (WCAG) is another resource that was frequently mentioned by participants, with six in total saying that this is a resource that they use as guidance on accessibility.

The University of Edinburgh editorial style guide was mentioned by five participants as a resource that they used to provide guidance on digital accessibility, in which the guidance reflects what publishers learn in training courses, meaning that information they take from the style guide is in line with accessibility and content design training.

What I learned from researching content accessibility approaches in EdWeb

I learned a lot during my time researching how web publishers at the University of Edinburgh approach creating accessible digital content. I thoroughly enjoyed the opportunity to work with staff from a variety of different areas of the University. This helped me to learn how to identify commonalities in interview and survey responses despite the areas of work being distinct. I also enjoyed this because I was able to learn much more about the work that goes on across the University and what the work of other teams involved.

I also particularly enjoyed the format of my internship being a combination of individual work and working with other members of my team and the Disability Information team. This balance allowed me to set my own goals while still getting the opportunity to work and learn collaboratively as part of a team, prioritising my tasks between my own and those that I was working on with others.

A limitation of my work was that it was much easier to contact and work with staff who have a genuine interest in the subject area of accessibility, which does not lead to research that is representative of how University staff approach digital accessibility as a whole. Having done the research that I have so far, a continuation of the research would be most beneficial if it focused on the experiences and approaches of staff who are less familiar with digital accessibility requirements and principles, as this would create a more well-rounded understanding of web publisher accessibility approaches at the content level.

Furthermore, another limitation of the work was the time constraints which have restricted my ability to develop solutions to issues identified during the research period. This was expected to a degree, as the solutions depended on the outcomes of the research, which has taken the majority of the 12-week period. The positive outcome of this is that the research and findings will provide the User Experience service with information that allows for both further research and for adaptations to guidance and training if it is deemed necessary.

Conclusion

This research has helped the User Experience Service to assess their training and the resources that are available for publishers to learn more about digital content accessibility. Keeping in touch with the publishing community through projects like this helps the team to direct their effort to real challenges that publishers face on a day to day basis.

The research completed throughout the duration of this project will be supported and advanced by further investigation, particularly by communicating with web publishers who are less involved with digital accessibility as a whole. This will likely help in providing more concrete solutions to digital content accessibility issues across EdWeb 2 pages.

Content audits are a long-time staple of the user-centred website toolkit, but they take time and effort to complete, which many website owners struggle to find. In my ongoing AI experimentation, I tried using AI tools to help me with auditing web content.

Every day brings a raft of new AI developments. When choosing how to use AI, I’m less sold on getting it to do creative tasks for me because I like doing those myself. Instead, in pursuit of freeing up my time, I prefer to use AI to help me with the tedious tasks I never get around to, the ones I know will take me longer than I think, the ones I put off again and again. Here’s looking at you, content auditing.

Websites are easy to grow but difficult to keep in check

When people come to the UX Service for help with their websites, they tend to use several phrases to describe their site. These have included:  ‘It’s a mess!’ ‘It’s a bit out of control’. ‘It’s grown arms and legs’. None of this is unusual when you consider the lifecycle of websites. Over time, websites change hands. Pages once carefully crafted are easily forgotten as new editors take over. New content is created without knowing what’s already there. Very often, content needs to be published to a deadline and it’s quicker to publish a new page than seek out and amend an existing one. Seldomly do publishers want to get rid content that’s taken time and effort to produce.

Read some thoughts on content housekeeping by UX Service team members (current and past):

Digital housekeeping – applying content management practices to improve digital sustainability by me

Be a gardener by Ari Cass-Maran

Content Audit Findings and the 100k Challenge by Milo McLaughlin

How to get a grip of your website (and then keep hold) by Neil Allison

A content audit is the best place to start improving a website (not the homepage)

When people seek to bring order to disarray on a website it’s difficult know where to start, so typically, they start on the homepage with ideas to change images or add new content. While this gives sites a superficial makeover, it doesn’t really help site audiences in search of content. Fewer and fewer website audiences are starting out on homepages, instead they’re parachuting directly into site content from Google search and increasingly, from AI summaries. What does this mean? It’s more important than ever to make sure your web content is up-to-date, accurate, useful and relevant for your website users. Here’s looking at you, content auditing.

Read more about getting your content ready for AI from a recent Content Improvement Club session:

Auditing a website needs a methodical approach (which is where AI can help)

If audits are so important, why are they so easy to put off? Short answer, they can take prolonged amounts of time and concentrated effort. The larger and more complex your site is, it’s likely that there will be more content to review, and the more difficult it may be to maintain a consistent auditing approach. Going through multiple, long pages of web content, it can be easy to run out of the time you’ve allocated for your audit. Breaking the audit into chunks may lead to different results from different sessions as biases creep in. Bringing colleagues in to help can share the load, but can also introduce new perspectives and contradictory auditing decisions. There’s a need to maintain ruthless objectivity, to counter human subjectivity and avoid errors infiltrating. Here’s looking at you, AI.

If you can plan and describe a website content audit, you can ask AI to help you do it

Website content audits can be done for many purposes, but commonly, doing a content audit involves making decisions about what content to keep, what needs to go and what needs to be changed – all in pursuit of reaching a future state of your website. A good way to decide what content to keep is to consider who it’s for and the purposes it serves. If a piece of content doesn’t meet audience needs and doesn’t align with the site purpose, then it’s probably a candidate for deletion. A good content audit of a website therefore typically requires several things:

1. An inventory of every piece of content in the site. Typically arranged in a spreadsheet, with one row per webpage. Can be organised into sections or content types, or grouped by root URL
2. A note of the site audiences, ideally in order of priority (answering the question ‘Who is this site primarily for?)
3. A list of the main reasons those audiences visit the site (answering the question ‘What tasks do people complete on this site?’) together with a list of the main goals of your site (answering the question ‘What do we want people to do on this site?’)

Considering each of these things as different pieces of data, where item 1 is data to be audited, items 2 and 3 are factors or auditing criteria used to decide what happens to those data (typically one of three outcomes: ‘Keep’, ‘Delete’ or ‘Modify’), I reasoned that I could give AI these data, tell it what a content audit was and and ask it to complete this process for a given website.

I experimented with ELM to help me do a content audit of a website

The University’s AI platform, ELM was the natural place to start experimenting with applying AI to aid content auditing. The ELM interface allows you to input a prompt, as well as add additional files and data sources. It also allows you to select different models to handle queries. I was curious to see the differences between the different models – both non-reasoning ones and reasoning ones so I needed to design a prompt that would work for both.

Read more about ELM and its models

ELM website

ELM new model guides (University log in required)

Being mindful of the environmental cost, I wanted to start with a small AI model (Llama 3.3)

AI comes with a significant environmental cost, which is highly dependent on the LLMs you use. Powerful models with more reasoning power are especially resource-intensive to run, so to avoid unnecessary wastage of tokens and other resources I’ve found it’s sometimes best to start with a smaller model and size up accordingly, as the need arises. The trade-off is that smaller models have limited reasoning power, however, so the responses they provide and the tasks they are able to complete can be limited.

Based on my previous experience of using AI and thinking about its potential application to a typical content auditing process, I had a hunch that providing a small model with something like a site inventory (such as a XML sitemap) and detailed data about website audiences and purposes could overload its context window and produce inferior results.

I therefore decided to begin with a lightweight prompt ‘Can you help me do a content audit of this website? (with a link to the website)’ to give a small model something manageable and learn how it approached handling the query. I chose a website that the UX team had recently worked on, so I was familiar with its content, and I entered the prompt, starting with the Llama 3.3 model – an open weights model (costed on computing power rather than per-token usage) which is hosted in University data centres (instead of being cloud-based). I toggled on the option to include web search so ELM was able to access the website.

The same prompt to different ELM models produced varied results

Having starting with Llama 3.3, I moved on to other models: Open AI’s GPT 5 and then Anthropic’s Sonnet 4.6. To assess and critique responses from each, I adopted the mindset of a person reluctant to begin a content audit and looking for AI help to kick-start action on this, and used this as a roleplay to review and compare the responses.

The response from Llama 3.3. was too generic to convince me to start auditing

Despite a glitch in formatting the response, Llama 3.3. provided some general information about content auditing. Its response included an initial assessment of the site, which made objective judgements of the homepage (assessing it as ‘well-structured, with a clear introduction’), the navigation menu (labelling it ‘easy to use with links to key sections’), content quality (noting it as ‘high-quality, informative and engaging’) and accessibility (pulling out that the site had an accessibility statement).

The response then acknowledged that in order to do a thorough content audit on the site in question there was a need to provide guidance on the aspects to focus on, and rounding off, the response noted some of the aspects a typical content audit would examine: content quantity, content quality, accessibility and consistency across different parts of a site.

Reviewing this response, I felt that if I was a site owner looking to improve my site, this response could very easily persuade me that I didn’t need to bother auditing it at all – and I wasn’t left any wiser about how to meaningfully provide guidance on the aspects to focus on if I did decide to proceed with an audit.

Likelihood to convince me to audit: 3/10

Open AI’s GPT 5’s response was detailed and thorough but a bit overwhelming

As would be expected from a reasoning model, the response when I used GPT 5 was more detailed than Llama 3.3’s. Arranged in two sections, the first part included preliminary observations using the site URL provided – which were split into the following categories:

• Information architecture and navigation – commending the site’s positioning on user intents, yet suggesting improvements with more explicit audience pathways and call-to-action signposting
• Content coverage and freshness – using the site’s range of content types to assess content structure and assessing freshness based on recency of news items
• Call to actions – acknowledging that the site had were multiple calls-to-action which could be combined into primary CTAs for each audience
• Accessibility and usability – calling out the need for more meaningful and less duplicated alt text on the site images
• Trust and governance signals – recognising the role of the site’s strong branding to demonstrate authenticity
• SEO – suggesting the site’s page titles and meta descriptions were reviewed for relevance

The second part of the response outlined a plan for a full audit. The plan began by posing three questions to be answered:

1. What are the primary goals? e.g. increase visitors, boost traffic, showcase outputs
2. Who are the priority audiences? (with suggestions of the different groups)
3. What’s in scope? (suggesting either the entire site or specific sections)

The response then provided a suggested series of 7 steps to follow to complete the audit:

1. Inventory and crawl (with detail of the inventory to start with and the tools to complete the crawl)
2. Editorial quality review (with detail of criteria to score each page – such as inclusivity, accuracy, audience-fit etc)
3. UX and IA review (with suggestions to evaluate navigation labels and connections between content and pathways to achieve top tasks)
4. Accessibility (with suggestions of accessibility checking tools to use as well as manual checks to complete)
5. SEO and technical (with suggestions to check data points like metatags, internal links, robots files and performance)
6. Analytics (with suggestions to use analytic data such as bounce rates, page views, site searches etc)
7. Recommendations and roadmap (detailing prioritisation measures to make the identified site changes)

It rounded off suggesting a template structure for the content inventory (and offering to create this template as a Google Sheet), an idea for a scoring rubric, and reiterating different tools to use (naming products like Screaming Frog, Google Analytics and SEMrush). To conclude, it offered to do the audit, requesting answers to the three initial questions and asking for access to a sitemap, external tools and governance documents (such as style guide and brand voice guidelines).

Reviewing the response, which was presented as text content, I found it a bit too much to scan and digest, and putting myself in the place of someone facing content auditing with some reluctance, it felt that this large amount of detail could be off-putting to even start the process. I could appreciate the relevance of suggesting of external tools, but knowing that each of those would require setting up accounts and logins, as well as going through a process to integrate with Open AI, it had the effect of making me mentally push content auditing to the bottom of a to-do list.

Likelihood to convince me to audit: 6/10

Anthropic’s Sonnet 4.6’s response gave structured guidance which was easier to follow

The output from the Anthropic model stood out compared to the others from ELM since it was not just plain text, instead, it had been structured with headings, tables and icons. This made scanning and digesting this response much easier than the others.

The response was structured into 10 sections, as follows:

1. Site overview – table summarising the site name, owner, primary purposes and date of confirmed content
2. Information architecture – list of the top-level navigation elements with an assessment of what worked well and issues identified in a bulleted list
3. Content inventory – table of pages, with noted audiences, details of last update (if known) and inferred status (on a red, green and amber scale)
4. Calls to action – list of CTAs on the homepage, with assessments and recommendations
5. Content freshness – table containing list of most recent items in each section and related assessment
6. Accessibility – list of accessible features that were present, table of items that needed checking and recommended accessibility tools to make the assessment
7. SEO and technical – table containing an SEO assessment, considering elements like meta descriptions, structured data, mobile responsiveness – each with an allocated status, associated notes and combined recommendations
8. Content quality and tone – list of observations and recommendations
9. Priority recommendations summary – table of priority actions with an effort/impact score
10. To complete the full audit I need – list of requirements to complete the full audit (including sitemap, CMS page list, Google Analytics data, etc.)

Content within each of these sections was comparable to that included in the GPT 5 response, but in the Sonnet 4.6 response, these sections referred directly to information from the site in question – for example, instead of making general assessments of site aspects like navigation and content coverage, it contained direct detail about the site itself with mention of specific pieces of content, noting what was already known (for example, referring to issues noted in the accessibility statement). Arranging this in tables with use of icons and red, green and amber priority indicators made it easy for me to pinpoint what to address and with what urgency, and having this consolidated in the final table was easier to parse than reading it in text format (as in the GPT 5’s response).

Reviewing this response from Sonnet 4.6, it was the best of the bunch from ELM, it contained enough detail to help me get started but not so much that it was overwhelming. Putting myself in the position of a time-poor site owner unsure where to start, I had clear pointers of the priority areas and a mix of quick wins and bigger tasks to choose from.

Likelihood to convince me to audit: 7/10

As well as ELM, I experimented with Chat GPT and Claude to provide content audit help

Models within ELM can also be accessed through interfaces provided by AI products. Two of the best-known AI products are Chat GPT (by Open AI) and Claude (by Anthropic). I was curious to see the responses each of these products would provide in response to my query asking for content auditing help so I prompted each of them in the same way. In both cases I used the free versions.

Chat GPT gave a suggested approach and produced initial findings

The response from Chat GPT was comparable to the output from ELM choosing an Open AI model, but the response was structured and annotated with tables and icons, in a style similar to the Anthropic response. It began with a suggested audit approach which set out different areas to consider and related questions. In the next section (headed ‘Initial observations’) it contained an analysis of the site itself, which included site strengths and highlighted the following six areas for improvement on the site in question:

1. Homepage is quite academic – pulling out some audience questions that would be relevant to be answered on the homepage instead of the content that was there
2. Navigation could be more task-focused – noting that the current navigation was driven by organisational structure rather than tasks users would want to complete
3. News archive – picking out the need for recent articles
4. Calls to action – acknowledging that many of these are worded to provide information not prompt an active response
5. Content consistency – advising a uniform page structure for easier reading
6. Audience segmentation – recommending clearer delineation between groups of site users

The response concluded with an example audit table and some content recommendations, organised under ‘Keep’, ‘Improve’ and ‘Review’.

Reviewing this response as a whole, I liked the up-front suggestion of an auditing approach and the example audit table which was then supplemented with detail about the site itself and recommendations relevant to different aspects of the site in question. This helped me visualise what the audit outputs could look like, and I could see ways to get there.

Likelihood to convince me to audit: 7/10

Claude presented interactives to actively take me through an audit process

Anthropic’s Claude interface took a different approach to the other AI products, immediately asking about the main goal of the audit with options to pick. I picked ‘full inventory’. It then asked the desired breadth of the audit with another set of options, from which I picked ‘full site crawl’. The next screen asked me about the output format, and I picked ‘spreadsheet’.

After approximately 2-3 minutes, with a running commentary of what was being done, Claude presented a list of ‘headline findings’ of bugs, orphaned content, out-of-date content and broken content (dead links, incomplete calls-to-actions etc). It also produced a downloadable Google Sheet with two tabs – the first containing a summary of the issues to be fixed, their locations and a reason why they needed to be fixed, the second with a full inventory, with one row for every URL in the site and columns logging the page title, content type, date, status (with colour-coded options: ‘Keep’ (green), ‘Update’ (amber), ‘Rewrite’ (dark amber), ‘Review’ (blue) and ‘Critical’ (red)) and recommended actions for each page.

 

Reviewing this response, it was by far the most effective at making me feel I was starting the content auditing process and supporting me through it. Being presented with the opportunity to answer questions upfront meant I could control how the audit went, and having a spreadsheet created for me to review saved a lot of effort making this from scratch by scraping the site for a sitemap and page metadata.

Likelihood to convince me to audit: 9/10

Conclusion: If you’re putting off auditing your website, try getting AI to help

If you’re looking to improve your website, doing a content audit is one of the best steps you can take – working out what you have, what’s working and what’s not will put you in a strong place to move forward and make positive changes. Depending on how well you know your site, and how much time and resource you have to spend on it, you may appreciate some help to get started auditing its content.

From my quick experimentation with the different AI tools available I learned that, with the exception of the small non-reasoning model, each AI product offered something to help initiate the content auditing process of a website. At a basic level, asking AI to look at your website will pull out something you may not find yourself such as an out-of-date page, an irrelevant CTA or an accessibility glitch. AI can also take a zoomed-out look at your site that you may be too close to adopt yourself – such as reviewing your navigation pathways, appraising your audience segmentation or analysing the consistency of your content voice and tone.

If you’ve never audited a website before, AI can offer a lot of guidance to get you started, and whether you choose to do it yourself taking recommendations from the AI on tools and/or processes or whether you prefer to hand the heavy-lifting to AI to get your audit spreadsheet started – leaving you to deal with the more nuanced decisions that require specialist knowledge and experience, these tools can save you time and effort and may just be the nudge you need to do this all-important website maintenance task.

 

It’s been a year (and two months) since I started to migrate Curious Edinburgh, and the newborn website is live!

To re-introduce, Curious Edinburgh is an open access platform which houses digital tours of Edinburgh and the Lothians. The tours are broken down into Community, Coastal and tours on the History of Science, Technology and Medicine. All 26 of them, long and short, highlight a particular dimension of Edinburgh’s cultural and scientific heritage. Users can walk the tours physically, using Curious Edinburgh as their guide, or virtually. 

Here’s an overview of how Curious Edinburgh migration progressed throughout this time and the discoveries I’ve made along the way.

What changed

My assignment was to migrate CE tours from WordPress to ArcGIS StoryMaps. As with any digital migration, I sought to improve content and functionality – not simply transfer them. I particularly focused on upgrading the project’s digital accessibility and user experience. On top of designing a new layout for the webpages, I incorporated interactive maps into each tour. They follow along with the text, situating the user geographically, and allow for easier navigation. All tour points are also assembled into interactive Maps of Contents at the head of each tour. Maps apart, I smoothed the creases and filled in the gaps: proofread every line, sourced new images, replaced or enhanced sources, created feedback sections, and wrote alt text to each image, video, map and embed. Besides accessibility, this has enhanced CE’s cohesiveness and visual appeal. 

Excitingly, just as I was wrapping up migration in early June, Curious Edinburgh received a request from the Consulate General of the US in Edinburgh to host a new tour. The tour would celebrate the 250 years since the Declaration of Independence was signed and the United States founded in 1776. 

This task marked a change of pace, giving me an opportunity to create a tour directly on StoryMaps. I was happy to be more actively involved with the content planning side of CE. In a back-and-forth with the Consulate, we’ve outlined the tour’s contents. The stop order in particular took careful arranging, since the trail spans the architectural heritage of Old Town, New Town and Leith. By 4 July 2026, we delivered a new publicly available tour, the USA 250 Anniversary Trail. It highlights the diplomatic, intellectual and labour connections between Edinburgh and the United States.

Rapid-fire stats 

Tours on CE: 26

Tours migrated: 25

Tours created: 1

Best tour (highly subjective): Granton, all the Coastal tours, History of Public Health

Maps created: 422 

ArcGIS products used: 4 (and more by the EDINA team, who created the landing website of the new platform).

Content highlights

Out of all trails, the tour around Granton was the largest and most daunting to migrate. Granton is one of Edinburgh’s northern waterfront districts – less visited than Leith, less gentrified than Newhaven. It has many new apartment buildings and a B&M home store. What could there be to see?

That’s what I thought, too. 

Turns out, Granton is a remarkable hub of Scottish industrial heritage. From quarries to street art, this tour takes the reader through centuries of history and modern-day change. Besides, the tour is assembled by Grantonians themselves, narrated with warmth and illustrated by archival images and local artwork. I migrated it with great pleasure, if gritting my teeth at 100-something images that needed fresh alt text. 

History evidently doesn’t discriminate – it happens everywhere. Yet, if you ask an Edinburgh resident ‘Have you ever been to Granton?’ chances are they will say no and maybe follow up with ‘Is that in Fife?’

Maybe the Granton tour will make amends. 

 

 

People highlights 

Luckily I have crossed paths with many new people during my internship. I would like to highlight two things.

The first one happened when I reached out to an independent Edinburgh tour guide, asking to reuse his photo for the History of Public Health tour. I expected a ‘no’ or a ‘sure’. What I didn’t expect was an enthusiastic response which acknowledged the significance of CE for Edinburgh’s heritage and tourism experts. I got my copyright permission and positive feedback to boot. It’s nice to be working on something people actually use.

My second highlight is last summer’s cohort of interns, many of whom returned to LTW this summer. Apart from being great company, they were also the first test subjects for my working webpage designs. Throughout last summer, upon my request, they submitted ingenious test comments for the tours (through Survey123), so that I could create initial data sets for setting up feedback moderation (in Experience Builder). In fact, these test comments were so creative that one of the CE team members asked me, very apprehensively, if we had accidentally catapulted the webpages into public access.

 

 

What’s next for Curious Edinburgh?

As the migration breathes new life into the project, Curious Edinburgh remains a living database for the Scottish capital’s past and present. A tour on the history of AI, currently in the works, should make a good addition to its history of technology section. I am also hopeful that soon CE users will be able to explore Edinburgh’s volcano more closely as a tour on Arthur’s Seat geology is integrated into the project. Finally, as 2026 marks the 300th anniversary of the Edinburgh Medical School, CE stays an excellent place to explore the history of the city’s healthcare sector.

Parts of the migration process were out of my scope, but could be tackled in the future. Here is just a glimpse of them. Digital sustainability: compared to the WordPress version, many webpages have increased in weight (mainly from heavy scripts). Mobile-friendliness: CE has an app which was not migrated/renovated, which leaves the question of a truly mobile-adapted Curious Edinburgh in the air. And a user-friendly mobile version is quite important for a walking guide. Digital preservation: how should the WordPress version be managed and maintained?

Waving goodbye

With the handover documentation completed, editing access transferred, and the latest tour completed, it is time for me to wave goodbye to a year’s work and ISG, and move on with a new project. We’ll see what that’ll be. (Exciting.) 

There is a lot of knowledge to be gained from Curious Edinburgh, and more still from its creators and contributors. I’m certainly grateful for the opportunity to find out.

You can pay Curious Edinburgh a visit here.

 

 

Curious links

• Coastal tours
• Granton tour  
• Curious Edinburgh on ArcGIS Online
• WordPress version
• Architecture of Edinburgh – Windows Into the Past 
• Old Tolbooth Records, 1657–1686

Earlier this year, the User Experience (UX) Service researched how colleagues find and use the University’s Inclusive Language Guide. This post explores why we used scenario-based research, what it revealed about colleagues’ behaviour and how the findings are improving the guide. 

The Inclusive Language Guide is only useful if people can find it 

The Inclusive Language Guide sits within the University’s Editorial Style Guide and provides practical guidance when writing about disability, race and ethnicity, and sex, sexuality and gender. The guide was developed in 2022 through a co-design process involving colleagues from across the University.

Inclusive Language Guide 

Having useful guidance is only part of the challenge. Colleagues also need to know it exists and be able to find it when they need it. 

More recently, we reviewed the Inclusive Language Guide to understand how discoverable it was for colleagues creating digital content. Emma Horrell has written about how this work prompted improvements to the guide’s visibility and signposting across the University. 

You don’t know what you don’t know: Improving the way we position inclusive language at the University

Why we used scenario-based research 

We wanted to understand more than whether colleagues were aware of the Inclusive Language Guide. Awareness alone does not tell us what people do when they need support, so we used realistic scenarios to observe how colleagues responded to situations where they might need guidance. 

We focused our research questions on four areas: 

• How colleagues approached decisions about inclusive language. 
• Where colleagues looked for support and whether they could find relevant guidance. 
• Colleagues’ awareness of the Inclusive Language Guide and what they expected it to help with. 
• Any gaps, ambiguities or areas of confusion. 

These questions shaped the structure of the interview and activities we designed. 

Researching colleagues approach to inclusive design decisions 

We combined semi-structured interviews with scenario-based activities to understand both colleagues’ existing experiences and how they approached real content decisions. 

We spoke to nine colleagues who create digital content 

We carried out nine interviews with colleagues in different roles across the University. Participants had a range of experiences creating digital content, including two student interns who brought perspectives of those newer to the University’s digital landscape. 

We began by exploring participants’ existing experiences 

Before looking at the scenarios or the guide itself, we asked participants about the types of content they create and whether they had ever needed to check terminology or wording before publishing. For example, we asked whether they had been in a position where they needed to consider how to word something to make sure the language was not excluding anyone. 

This helped us understand the approaches colleagues already used and the sources they relied on when dealing with these topics. 

Realistic scenarios showed how colleagues look for guidance 

We introduced a series of realistic scenarios based on everyday content tasks. 

Rather than asking whether participants knew about the guide, the scenarios allowed us to observe how they approached these situations in practice.

Example scenarios included: 

• writing promotional content about a Pride initiative and wanting to ensure the language used was fair and respectful 
• writing about someone who had experienced trauma and wanting to avoid misrepresenting them 
• checking the preferred terminology for the chair of a company board before publishing a news article 

In posing the scenarios, we gained insight into where participants would usually look for this type of guidance, how confident they felt making language decisions and what they understood by the term ‘inclusive language’.

We adapted our scenarios as we learned more 

One of the original scenarios asked participants how they would write about someone elected to lead a company board. Rather than focusing on terminology, several participants described how they would research the individual or organisation before publishing. 

While this reflected realistic editorial practice, it did not help us answer the research question we were exploring. 

For later sessions, we refined the scenario so that it focused specifically on checking the preferred terminology for the role before publication. This encouraged participants to think about language choices and produced richer insights into where they expected to find guidance. 

What we learned: Four themes around finding and using inclusive language guidance

Across interviews, there were four themes that emerged consistently. 

Colleagues valued inclusive language even when they had not heard of the guide 

Across the interviews, participants consistently demonstrated that they valued using respectful and inclusive language. They were already thinking carefully about inclusive language, but they did not always know where to access University specific guidance.  

Many described that they would check terminology with colleagues or seek advice from specialist teams when writing about unfamiliar topics. They wanted confidence that they were using appropriate language. 

Awareness of the importance of inclusive language was much higher than awareness of the Inclusive Language Guide itself. 

Colleagues expected to find guidance through different routes 

The scenario-based activities helped us understand where colleagues naturally looked for support. 

Participants frequently described turning to colleagues, managers, Equality, Diversity and Inclusion (EDI) resources, staff networks and external websites. A few participants did eventually land on the guide, but they had not recalled it or looked there first. 

Several participants also relied on previous examples when writing content. Others spoke about balancing official guidance with lived experience and perspectives from the communities being represented. 

This highlighted an important consideration. Colleagues expected inclusive language guidance to be connected to the places they already look for support, linked from elsewhere rather than existing solely within the Editorial Style Guide.  

Improving signposting therefore remains just as important as the guide itself. 

Colleagues understood the phrase ‘inclusive language’ in different ways 

Participants interpreted the phrase ‘inclusive language’ in different ways. 

Some described it as “using the correct terminology”, while others framed it more broadly as “not leaving anyone out”. Those with accessibility backgrounds often drew direct connections between inclusive language and accessibility. 

Despite these differences, the term ‘inclusive’ was recognisable, with several participants using it unprompted when working through the scenarios.

Colleagues looked for practical guidance first 

After exploring how participants would approach different situations, we asked them to navigate the Inclusive Language Guide. This helped us understand whether the structure matched their expectations when looking for support. 

Several participants were unsure where the practical guidance began. Some mistook the introductory blog post for the guide itself, while others expected the examples and practical advice to appear much earlier on the page. 

Although participants valued the context and principles behind the guidance, they prioritised practical information they could apply immediately. The examples within the guide were consistently highlighted as the most useful content. 

The research continues to inform improvements to the Inclusive Language Guide 

Our findings have allowed us to identify some key areas for improvements to the Inclusive Language Guide.

Making practical guidance easier to find 

One area of focus is the guide’s landing page. We are reviewing its structure so that practical guidance is easier to find while retaining the contextual information that participants found valuable. 

The findings highlighted that the current structure does not always support the way colleagues use the guide. Participants wanted to move quickly to practical guidance while still being able to access the wider context when needed.

We are also reviewing page titles, navigation labels and the ordering of content to make it clearer where the guide begins and how it relates to the wider Editorial Style Guide. We’re considering how to better support both first-time and repeat use, making it easier for people to quickly find practical guidance while still providing the context and principles that many participants found valuable.

We’ll also consider how best to surface practical examples and support the different ways colleagues use the guide, whether they are reading it for the first time or returning to quickly check terminology and writing conventions.

Improving connections with related guidance 

The research also prompted us to consider how the guide connects with related guidance across the University’s web estate. 

Participants frequently expected to find inclusive language guidance within EDI resources or other specialist guidance. Improving discoverability means not only improving the guide itself, but also making sure it is connected to the places colleagues naturally go when seeking support.

As outlined in Emma’s blog, since completing the research, we have worked with colleagues responsible for complementary guidance across the University’s web estate to improve signposting between services.

This work will help ensure colleagues can find appropriate support regardless of where they begin their journey. 

Scenario-based research helped us understand behaviours 

The research reinforced an important principle in content design: guidance needs to be easy to find as well as useful.  

By combining colleagues’ existing experiences with scenario-based activities, we gained a better understanding of how people approach inclusive language decisions. These insights have already informed improvements to the Inclusive Language Guide and will continue to shape how we approach future content research.

I introduce QuillMark, a Drupal prototype designed to help web publishers check content against the University’s editorial style guide. I reflect on how I developed and tested the tool with publishers, focusing on what their feedback revealed about usability and how it will shape the next version.

Introduction

My name is Shlok, and this summer I am working as an AI and UX Innovation Intern in the Information Services Group (ISG). During my internship, I have been developing QuillMark, a prototype tool designed to help web publishers check their content against the style guide. This blog post explains the problem I was trying to solve, how I built and tested the prototype, what I learned from publishers and what I plan to do next.

 

The problem

Our style guide contains more than 60 rules covering areas such as spelling, punctuation, tone, formatting and terminology. Previous research showed that web publishers found it difficult to remember and apply every rule while writing and editing content.

 

This is understandable. Publishers are often working under time pressure, and checking a page manually against dozens of rules adds a significant cognitive burden. Even experienced publishers can miss small details, particularly when they are concentrating on the meaning and accuracy of the content.

 

I began exploring whether a tool could make this process easier. The aim was not to replace publishers’ judgement or rewrite their content automatically. Instead, the tool would identify possible style-guide violations, explain the relevant rule and allow the publisher to decide whether to apply or dismiss each suggestion.

 

This became QuillMark.

 

Read more about the Style Guide

 

Why I built the prototype in Drupal

Drupal is where publishers already create and edit web content, so it made sense to build the prototype directly into that environment rather than create a separate tool.

Before starting development, I attended Drupal in a Day to understand the platform, its content-editing interface and how a custom tool could fit into an existing publishing workflow.

 

Building QuillMark within Drupal meant publishers could check their content without copying it into another system. It also allowed me to test the tool in a realistic environment, using the same types of fields, buttons and interactions that publishers encounter in their day-to-day work.

 

Read more about Drupal in a Day

 

Planning the checking process

Before writing the prototype, I planned the system in detail.

 

One of the main design decisions was that QuillMark should highlight individual issues in the existing content instead of generating a completely rewritten version. Rewriting an entire page could introduce unnecessary changes and would require the publisher to audit every sentence. Showing individual findings makes it clearer what the tool has identified and keeps the publisher in control. This also prioritises the HITL (Human-in-the-Loop) framework, which I intend to use in my AI-based projects to ensure that people remain involved in reviewing decisions made by AI.

 

The system design proposed three types of checking:

1. Deterministic checks for clear violations that can be identified using code or regular expressions, such as prohibited words or spelling conventions.
2. A smaller AI model for relatively straightforward issues that require more context than a simple text search.
3. A larger language model for more complex, judgement-based rules involving areas such as tone, structure or plain language.

 

The plan also used a MapReduce-style approach. Rather than asking a language model to apply all 60–70 style-guide rules in one prompt, the rules would be divided into smaller groups. Each prompt could then concentrate on a limited number of rules before the results were combined. This was intended to reduce the risk of the model overlooking instructions because it had been given too many at once.

 

The original design included an additional AI step to remove duplicate findings and resolve overlaps. I left this out of the prototype because duplicates were expected to be relatively uncommon, while the extra model request would increase cost and complexity.

 

Read more about the technical system plan: https://blogs.ed.ac.uk/website-communications/quillmark-the-technical-details-behind-my-drupal-style-guide-assistant/

Coding the prototype

I developed the prototype iteratively, beginning with a small number of style-guide rules and expanding the checks once the basic workflow was working. For development, I used Codex. I gave it my plan and asked it to design the architecture. After reviewing it, I asked it to proceed with the implementation.

 

The first stage used deterministic checks for issues that could be found reliably without AI. These checks searched the content for recognisable patterns and returned the location of the issue, the relevant style-guide rule and, where appropriate, a suggested correction.

 

The second stage used a large language model to identify issues that depended more heavily on context. I divided the rules into smaller prompt groups so that the model could focus on a manageable set of instructions during each request.

 

The prompts asked the model to return structured findings rather than a rewritten page. Each finding needed to include enough information for QuillMark to:

• identify the relevant content;
• explain the problem;
• show the related style-guide rule; and
• suggest a possible correction.

 

Publishers still had to approve or dismiss each finding. This human-in-the-loop approach was intentional. Style rules can depend on context, and an automated suggestion will not always be appropriate. QuillMark was designed as a decision-support tool, not an automatic editor.

 

Watch a video demo: https://media.ed.ac.uk/media/t/1_yozad8ie

 

Designing the usability test

Once the first iteration was complete, I adapted an existing usability-testing template to create a test for QuillMark.

 

I conducted three sessions with web publishers. Participants were asked to work through a series of tasks covering the main parts of the prototype, including running the checks, understanding the two stages, locating an issue in the editor, reviewing a rule and applying or reverting a suggested fix.

 

I observed how participants used the interface, where they hesitated and whether the information on screen matched their expectations. I also asked how they might use the tool as part of their normal publishing process.

 

The purpose was not only to find technical bugs. I wanted to understand whether the concept itself was useful and whether the interface communicated how the tool was intended to work.

 

What publishers told me

The publishers thought the tool would be useful as a final check before publishing. They said they would still use their own judgement and would not automatically accept every suggestion.

 

Most of the feedback was about the usability of the tool. Some parts were unclear, such as the difference between the two stages and some of the button labels. There was also too much information on the screen, and some issues were repeated. The publishers also wanted to see what a suggested fix would change before applying it.

 

What I learned

The testing suggested that the core idea is useful, but the user experience needs to become simpler.

 

Publishers do not necessarily need to understand which checks use regular expressions and which use an AI model. They need to know what issue has been found, why it matters, what the proposed change is and what action they can take.

 

The sessions also reinforced the importance of designing for scanning. More explanation does not always create more clarity. In a publishing workflow, concise labels, clear states and well-grouped findings may be more valuable than displaying every piece of supporting information at once.

 

Next steps

My next step is to refactor and review the prototype code before making changes based on the usability feedback. This will include reviewing the AI-generated code to check whether each section is needed, whether the same result could be achieved more simply, and whether any parts repeat code that already exists. I will compare the generated code with the rest of the codebase so that it follows the same structure and does not add extra functions or files without a clear reason.

 

Where the code is longer than needed, I will simplify it by removing repeated checks, combining similar sections, and reusing existing functions. I will also keep individual files to a manageable size, generally no more than 1,000 to 3,000 lines depending on the file. Larger files will be split where this makes the code easier to follow, and hardcoded rules will be moved into the database where possible.

 

The next iteration will focus on:

• clarifying or simplifying the two-stage workflow;
• reducing repeated and overwhelming findings;
• improving button labels, status messages and colour distinctions;
• previewing changes before they are applied; and
• making the interface more concise and easier to scan.

 

UX Scotland is an annual two-day conference for people working in user-centred design. This year, I went along to the John McIntyre Centre to hear about the latest developments in UX. In this post, I’ll write about my highlights from the conference.

Object-oriented UX in action: rebuilding a public sector website with structured content

The challenge: dividing up content and naming groupings

Out of all the talks I saw, this was the one that I found the most interesting. Joey Gartin, a content designer at Renfrewshire Council, told a story about a multiyear project to redesign the council’s website. It started with a familiar situation: the council had a large website that people found confusing and hard to use. Users couldn’t find things, and when they could, it wasn’t always easy to understand.

Renfrewshire Council needed to work out a better way to divide up and group the content on their website. Then they needed to name those groups in a way that made sense to people.

I enjoyed hearing about this because this is one of those problems that never seems to go away. When we work with digital content, whether that’s designing a homepage or tidying up a shared set of folders and files, we’re constantly looking for ways to group things. Then we’re also constantly looking for names for those groups that will make sense to people.

OOUX involves favouring nouns over verbs

Renfrewshire Council approached the problem using methods from Object-Oriented User Experience (OOUX). This is an approach to digital product design that focuses on establishing the things (or ‘objects’) that matter to your users. The approach emphasises the importance of working out the nouns involved in your service before you move on to the verbs. I’d read a bit about it a while ago on Duncan Stephen’s blog:

Duncan Stephen writes about how the Scottish Government have used OOUX approaches

The argument in favour of focusing on nouns is that this approach is more closely aligned to how people think. When you walk around a supermarket, you have a shopping list of objects. To reflect this, a supermarket is typically organised into sections that reflect broader groupings of those objects: Fruit, Vegetables, Pasta, Cake, and so on.

In a similar way – the theory goes – people often approach websites with a list of nouns in mind. They are therefore scanning webpages for keywords that match these nouns.

But many council websites use a hybrid of verb-based groupings and noun-based groupings. So you get sections called Pay, Apply, Report and Request forming a core part of their information architecture. Here are two examples.

The City of Edinburgh Council:

West Lothian Council:

 

Renfrewshire have not adopted this model. While their page titles often start with verbs, the groupings for these pages overwhelmingly use nouns:

Renfrewshire Council

Joey cited the City of Sydney as another public body using this approach:

City of Sydney

OOUX helped Renfrewshire Council to create templates

With your objects figured out, the next step of an OOUX approach is to work out:

• the relationships between objects
• the calls to action that objects offer users
• the attributes that make up objects

Joey talked us through this work. He also talked about how Renfrewshire Council used this as a foundation to create templated designs for common page types.

For example, take these two pages, both categorised as ‘service requests’:

• Report a housing repair (Renfrewshire Council)
• Graffiti (Renfrewshire Council)

Because they’re both service requests, you can see common sections on both pages.

For example, on the ‘Report a housing repair’ page, you have sections called:

• Before you report a repair
• How to report a repair

And on the ‘Graffiti’ page, you have:

• Before you report it
• How to report it

Joey showed us how this works behind the scenes. Renfrewshire Council use custom content types in Drupal to help structure the content writing process. So if you’re a content editor writing a service request page, you’ll be prompted to add a section on ‘Before you report it’. This helps content writers know what they need to include in a page. It also brings consistency to the website, which ultimately benefits users.

My reflections on how templates could work at Edinburgh

At Edinburgh, we use content types in our Drupal-based CMS EdWeb to create News and Event pages. So it was interesting to see another public sector website using a more extensive set of content types in Drupal. It made me reflect on how this approach might work for us. The context is so different: at Renfrewshire, it sounded like they had a more centralised approach to content management. The bulk of Edinburgh’s content publishing model is more devolved, which makes templated approaches to content more challenging. But there are clearly benefits available when you can make it work.

So lots to chew on from this talk, and it was a fun presentation to boot.

Other highlights

Sara Wachter-Boettcher on burnout

Sara Wachter-Boettcher’s keynote, “You don’t need more grit: breaking the burnout cycle in UX” was a run through of how and why burnout affects designers working in tech. It was a useful reminder to appreciate the limits of our influence within an organisation, and to be careful not to attach too much of ourselves to our job. It was cool seeing Sara in person. Her book Content Everywhere was one of the first things I read when I started in my role, and I thought it was really good.

Sara Wachter-Boettcher

Craig Abbott on AI and accessibility

Craig Abbott spoke about the risks and opportunities of using large language models for website design and fixing accessibility issues. One point that stood out was that LLMs are trained on some pretty ropey data. WebAIM estimate that 95% of the top million websites have detectable WCAG 2.2 failures, and these are the kinds of site that LLMs are trained on. So if you ask an AI to create a website, it will often produce something that superficially looks ok but is packed with accessibility problems.

The WebAIM Million: The 2026 report on the accessibility of the top 1,000,000 home pages

Craig showed us an example of a website he’d quickly created with AI and talked through the accessibility problems. He also showed us his other experiments. He’d had inconsistent results using AI to detect heading level failures or write alt text that took the context of an image into account. But he’d had some successes with using AI to complete more technical tasks with testable results.

Craig Abbott

James Chudley on digital sustainability

James Chudley presented on bringing sustainability practices into digital design. The highlight for me was seeing his experiments with visualising page weight across a website. Taking inspiration from an infographic using colour bars to illustrate rising global temperatures, James had applied a similar idea to visualising where a website is using more energy-intensive design choices.

James has posted his slides here:

James Chudley: Presenting ‘Beyond human centred design’ at UX Scotland

Another great conference

UX Scotland was a good chance to hear from some leading lights in the field, catch up with people and hear about some case studies that are relevant to us at Edinburgh. The two days were well organised and it gave me a lot to think about as we continue to support UX and content work at the University.

UX Scotland

My time at the Forrest Hill office as an Information Resources intern began four weeks ago under Edinburgh’s summer brilliance. Working as a part of the Portal Services team, I am responsible for creating and improving existing information resources about MyEd (the University’s online portal), including editing EdWeb2 pages, producing instructional videos, and refurnishing help and support SharePoints.  

Experiences designing promotional graphics, videos and syllabi for societies and events since high school made me a veteran of CapCut and Canva. It didn’t take me too long to get the gist of less familiar platforms like SharePoint and EdWeb2 (the University’s content management system) either, thanks to the self-paced online training courses. Freshly equipped with all the essential tools, I hit the ground running with high spirits. Like in any independent projects and commissions I did before, my creative visions, personal judgements and the mere intuition of “I like the look” carried me through the planning and proposal stage. I audited the existing EdWeb2 pages about MyEd to propose improvements, planned the refurbishment and new structure of the SharePoints, and storyboarded for the upgrade of the “How to use MyEd” video. Everything progressed beautifully smoothly and swiftly. The big frameworks and ideas were set up and ready to go.  

 

When “I like the look” starts to fail  

But as they say, the devil’s in the details; mine was waiting right around the corner at the execution stage.  

I was the most ambitious and eager with the upgrade of the “How to use MyEd” video, as it would be my first time creating official video for an organisation rather than for smaller commercial causes. My initial aspiration for upgrading this video was to make it as eye-catching and engaging as the promotional videos made by big companies like Substack: intricate transitions, animations, and rich colours. I wanted it to not only be informative, but charming enough to excite the new students about university life and this new portal system they’re starting it with. I spent nearly a week adapting to the PC version of CapCut, learning new transition techniques, and adjusting the properties of millions of key frames for about the millionth time until the movements are natural and the timings are perfect. With fondness and personal satisfaction towards the visual, I submitted the first draft for review.  

My manager responded:  

“Have you reviewed it with the accessibility checklist?” 

That’s when the design I was so proud of began falling apart like a house of cards. It became clear to me the first time that I’m no longer designing resources for a class of 30, but a community of 53,000+ students within a large institution. “I like the look” hardly stood valid against objective, rational standards like the WCAG (Web Content Accessibility Guidelines) and the University’s editorial guide for effective digital content. The sliding animations I designed turned out to be rather disruptive, as they create moving backgrounds under the text. This compromised the minimal contrast requirement (as text might blur into background) and created more challenges for users with attention or vestibular disorders. After re-reading the WCAG sections on video accessibility, I reduced the speed and frequency of motions on screen, avoided all-caps titles (which troubles users with dyslexia), and carefully checked font size and color contrast section by section.  

Around the same time, I came across Katie’s wonderfully illuminating blog on when videos and images genuinely add value to digital content: 

Videos and images – when do they add value and not just page weight? – Website and Communications Blog 

Although the blog was more about websites, its message inspired me to remove stock footage in my videos, which I previously employed for pure aesthetic reasons to make sections appear less static. Not only did they not add much informational value, but they also increased the video file size and created more moving backgrounds that hinder accessibility.  

Another lesson came through collaboration. Unlike society and event projects where I made every creative decision myself, this video formed part of the Pre-arrivals team’s “How to” series and therefore needed to follow an established visual identity. I will need to adapt the current draft to their prescribed templates, formats and requirements. With the same logic of branding in mind, I also replaced all colors in the video with colors from the University’s official branding palette. This way, in the long term, it could seamlessly fit into university websites, whether uploaded to Media Hopper or embedded into EdWeb pages.  

It would be dishonest to say it wasn’t a little heartbreaking to undo and cut work I had spent hours creating. Nonetheless, I came to understand that information resources differ from creative projects exactly because clarity, effectiveness, and accessibility must always come before visual aesthetics. I began seeing various guidelines and requirements less as constraints. They taught me a more rational and methodical approach to creating information resources than relying solely on the easy intuition and judgement of “I like the look”. Where I designed with my own palate and assumptions before, now I truly began my journey of designing for others. 

 

But does “I like the look” truly have no merit at all?  

Surprisingly, I would argue that it still does. “I like the look” is not something to unlearn completely, but it should be treated as the beginning rather than the end of the design process. From a different perspective, I have come to think that that instinctive thought is where UX (user experience) thinking begins. 

When I first opened the Notifications Service SharePoint that I was supposed to redesign, my immediate reaction was “I don’t like the look.” Except this time, rather than concluding the thought and jumping straight to redesigning based on personal preference, I attempted to find a rational “Why” by referring to all the guidelines and effective digital content tips I have learnt.  

The SharePoint was comprehensive, containing all the information staff would need to understand what notifications are and how to send different types of notifications. Yet as a first-time user that knows near nothing about the Notifications Service, I found it difficult to know where to begin. The original homepage was filled with large blocks of text and links with equal visual weight regardless of importance; Navigation of all the pages and materials relied heavily on users have prior knowledge on terminologies like “Notifications Template” and “Emergency Notifications”, and there was little visual hierarchy to guide attention or suggest the next step.  

That’s when I realised when users say they “like the look” of a website, they are often responding to not just colours or typography, but how intuitive, organised and effortless it feels to use. I decided not to simply edit the existing pages, but to rebuild the site’s structure in a separate testing environment.  

For instance, instead of letting the homepage act as a page of plain text, I plan to make it a clearer starting point for all types of users. I intend to include an image of Notifications Backbone (the system used to send notifications) alongside a direct button to access it. This way, experienced staff can access the system immediately, while first-time users are given some introductory visual and textual context before they continue exploring the site. The content changes minimally; my focus is to reorganise them around users’ journeys. Similarly, rather than presenting users with a long list of pages whose titles assume prior knowledge of relevant terminologies, I plan to reorganise the content into a small number of category cards based on what potential tasks users are trying to accomplish. I also hope to introduce a clearer hierarchy within the navigation menu, so that related pages are grouped more logically, and any information can be found more intuitively.   

Original homepage  v.s. New draft hompage 

  

Original information list  v.s. New draft categorisation  

New draft menu bar  

Being a student unexpectedly became an advantage in this process. Since I had similarly little prior knowledge of the Notifications Service as a new user, every point where I became confused while visiting the original SharePoint highlighted somewhere a common struggle might occur. Looking at the site with fresh eyes helped me identify problems that familiarity can sometimes hide. 

 

From “I like it” towards “We like it”  

But of course, just as I learnt with the review of the MyEd video draft, the work does not end once I think the design “looks right”. Everything I design  – SharePoint, websites, and videos – still need to be checked against the accessibility standards, follow editorial and branding guidelines, and most importantly, be tested with the people it is actually designed for (e.g. test MyEd video with students, the Notifications SharePoint with staff). Nick’s excellent guide on running usability tests has been particularly helpful in shaping how I plan to continue with the next steps.  

How to run a usability test – Website and Communications Blog 

“I like/dislike the look” has carried me through countless creative projects before. Four weeks later, I don’t think that instinct has been unlearnt but simply found its proper place. Rather than a justification for me to blindly follow personal preference and biased judgements, it has become the starting point for me to ask better questions about accessibility, usability, and the needs of the people I’m designing for. That is the perspective I’ll continue carrying into MyEd information resource that I will continue to create and develop throughout the rest of the internship.  

 

 

A year on from the relaunch of our Effective Digital Content online course, we’ve recently made some improvements, particularly in relation to the ‘Understand what your content is for’ module. We’ve rewritten the module, moving from a video to a text-based format.

In this blog I’ll share a bit about the updates we’ve made and the thinking behind them.

Over the last year we identified ways to improve the module

It was always our intention that the course would follow a cycle of continuous improvement, where it would evolve when we identified ways to make it better for learners.

Over the past year, we’ve learnt quite a lot about what makes a module effective through our work to adapt the course for external audiences. Although this project has paused for now, the work has allowed us to improve the course for University colleagues.

We’ve also continued to learn about people’s preferences in how they like to consume information, as well as the environmental impact of the content we create and maintain.

Developing a proof-of-concept course for external audiences gave us a fresh perspective

When exploring how we could evolve the course for external audiences earlier this year, we had to think about new ways to teach certain concepts. The video in the first module explaining the importance of understanding the audience and purpose of your content was one of the areas we knew would need most work. The video had been produced many years ago, specifically for University staff and therefore contained various terms and references that wouldn’t be appropriate for an external course.

We knew how important it was to get this module right as the principles it teaches underpin the rest of the course topics. It involved going back to the drawing board to consider the key learning outcomes of the module and the practical skills we wanted to teach. This process provided the opportunity to re-imagine what the module could become and importantly whether we needed video to convey key messages.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ongoing user research showed video was not always the preferred format

We were also aware from speaking to colleagues who had taken the course and in usability testing of the new module, that video was not always their preferred method of obtaining information. Some colleagues mentioned that their preference would be to view or download the transcript instead of watching the video in full, even if the video was relatively short. The benefits of this approach were that they could digest the information at their own pace and be able to refer back to relevant points more efficiently, rather than having to locate the correct place in the video.

These insights, alongside the time intensive process involved in producing and maintaining a new video influenced our decision to reconsider whether a text-based format would work better.

The environmental cost of media use cannot be underestimated

We’ve also been learning through ongoing research into digital sustainability about the environmental cost of media use, particularly images and videos. We’ve learnt the importance of considering the value that the media brings before choosing it as a medium to communicate your message. You can read more about this work in my previous blog.

Videos and images – when do they add value and not just page weight?

As a result, we’ve been questioning whether the video we previously used in the course enhances clarity, context or understanding, or whether we could convey the same information without it.

The module has evolved but the underlying principles remain

We came to the conclusion, based on user feedback and our own inclinations about how to improve the module, that we would remove the current video in the internal course and replace it with a freshly written text format module.

The underlying principles of the module stand true – that the starting point is always to think about the audience and purpose of your content. As a result, the accompanying workbook activities for the module remain unchanged.

There are a few new additions to the module

We’ve added in a new section to explain the key concepts of user needs and business needs, which should help to provide a good foundation for later modules. There are also some more practical University related examples of key concepts.

The previous iteration of the module didn’t have any interactive elements. We’ve received positive feedback on the quiz questions we’ve included in other modules of the course so we decided to include two multiple choice quiz questions so you can check your understanding as you go.

How to take the course

If you’d like to take the Effective Digital Content course, you can find more information on our course page, including a link to enroll through People and Money.

Effective Digital Content

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.

 

 

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

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.

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.

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.

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.

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.

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.

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.

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.

Riding on the success of our internal Effective Digital Content course, we set out to expand by building an external version for the short courses platform, taking a product thinking approach. Three months on, experimenting with a proof-of-concept course has convinced to pause this work – to avoid falling into a build trap.

The success of our relaunched Effective Digital Content (EDC) course, to date completed by more than 400 University staff, prompted ambitions to reposition the course for external audiences by including it in the University’s Short Online Courses platform. With the help of colleagues from the Short Online Courses team and the Learning Technology team, we did some market research, identified target audiences, defined a product vision and goals and began using the Canvas platform to develop a proof-of-concept.

Read more about our plans to reposition EDC as an external course in my blog post from March 2026:

Repositioning Effective Digital Content as a short online course: A product approach

At the end of sprint three (of a total of seven planned sprints) we faced unknowns and unanswered questions preventing us from achieving some of the fundamentals we’d defined in the product vision and goals. Resisting a sunk-cost fallacy-motivated urge to continue building, we made a sensible decision to stop and to pause until we’re in a better-informed place to have the confidence to continue.

In this post, I reflect on the benefits of adopting product thinking, the discomfort with facing difficult questions upfront and the practicalities of learning about audiences for expansion opportunities.

Revisiting the Product Kata helped clarify feelings of uncertainty

Melissa Perri’s book ‘The Build Trap’ contains a helpful framework to guide product development which I have become familiar with through my involvement with Drupal product teams. On the strategic level, this framework helped me set out a vision for an external version of the Effective Digital Content course, establish the problem the course was aiming to solve and its audiences, and work out the learning outcomes associated with each course module.

Entering the execution phase, however, taking each course module at a time and building each one out to meet the needs of the established audiences, things took longer than planned, and felt more difficult than we’d anticipated.

Pausing for reflection, we unpicked where things were going wrong. Going back to our vision, we had wanted to repeat the success of the internal EDC course, giving learners practical experience of writing digital content for their audiences. We had been able to instill this experience in the internal course because we had been able to regularly engage with University web publishers, to fully understand their content design challenges and design practical experiences for them that specifically addressed their friction points. Without such detailed insight into external audiences, we were effectively basing our course design decisions on guesswork and assumptions, which explained why our initial efforts seemed to be missing the mark. The strategic vision was sound, but our capacity to fully explore the problems and optimise associated solutions was limited, therefore execution was flawed.

The practical workbook is EDC’s best asset – but is hard to replicate for broader audiences

A lightbulb moment in our reflections came when considering what worked well about our internal EDC course. When staff complete this course, they are required to complete exercises in a workbook which they submit to the UX team for feedback. This tests learners’ ability to do fundamental content design tasks like structure headings, write hyperlinks and turn lengthy text into chunks to be scan-read. Reviewing more than 400 submitted workbooks, we affirmed the importance of this element of the course both for learners and for our team as owners of the course as a product. Through these workbooks,  learners are able to practice content design in the specific context of the University sites they are responsible for, and as the product team, we are able to see impact the course has had in improving content design knowledge.

Replicating the workbook concept for external audiences would require knowing about the contexts and content they were working with, in order to design exercises that required them to test those skills. Without knowledge of our audiences’ circumstances, the best we could do would be to design a generic set of exercises, devoid of the nuances needed to really engage learners in practising content design techniques.

Testing what we had built so far taught us what we didn’t know

In UX and product design there’s a saying: the best time to test is yesterday, failing that, test now. Resisting the urge to keep building EDC modules, we made the decision to take the three modules that had been built and to test them with University publishers. Feedback from the tests was positive, which was nice to hear, but didn’t really help us assess if the modules we had made were a good fit for external audiences. University staff wouldn’t take an external Effective Digital Content course as they had already taken the internal version. To assess if we’d made a good product we needed to know answers to questions such as:

• What needs should we prioritise for our target audiences?
• How do our audiences currently meet these needs?
• Would univerisities with a distributed content model find an external course useful?
• What would motivate our target audiences to take this type of course?
• How well do existing courses meet user needs and expectations?
• Will our proposed course be valuable to target audiences?

In another of Melissa Perri’s books ‘Product Operations: How successful companies build better products at scale’ by Melissa Perri and Denise Tilles, the authors use a case study at a financial services organisation, Fidelity, to show the relationship between user research and the product design lifecycle. Applying this relationship by positioning EDC external as the product, it was clear that our outstanding questions fell into the ‘Core UXR question’ category at the ‘Discover’ ‘Define’ and ‘Design’ stages and therefore needed to be addressed before proceeding to the ‘Develop’ and ‘Deploy’ stages.

Having worked with other teams both within and outside the University, we knew all too well the potential risks and consequences of building without adequate research – and resolved that it was better to stop building to avoid wasting effort.

Successful expansion will rely on targeting audiences and researching their needs more fully

Taking a pause in the build will allow us to take time to assess the gaps in our knowledge of our target audiences, and work out ways of learning what we don’t know. Understanding the nuanced needs of our target audiences will help us familiarise with the market for content design training in the public sector to assess the value of the expansion opportunity. Referring again to ‘Product Operations’, learning the differences between the markets associated with our expansion opportunity (the total addressable market, the serviceable addressable market and the serviceable obtainable market) will help us decide whether the proposition is viable, deliverable and desirable or not.

In the meantime, we’re using what we’ve learned to improve internal EDC and training

As a team, we really value what we learn from time spent in research, and we always endeavour to act on what we have learned and make sure research does not go to waste. In this case, going through the process of reworking three course modules to aim them at external audiences has pinpointed ways to improve the internal version of our course – in particular to make the introductory module clearer and more impactful and to be clearer on some accessibility concepts. Submitted workbooks and feedback from our regular Content Improvement Clubs also provide a constant source of learning, to identify areas publishers still struggle with that we can continue to address with subsequent tweaked versions of EDC and topics for additional publisher training sessions.

In January 2026, Alex Burford, a learning technologist from the School of Informatics contacted the UX Service following completion of the new Effective Digital Content online course. Alex had really enjoyed the course and was keen to explore ways to implement the content design best practice principles it teaches within Open Course – the platform that the School of Informatics use to share their course materials.

Informatics Open Course Materials

Identifying key areas for improvement

Alex had received positive feedback from students who were able to successfully locate their course materials. However, from our discussions and a review of the content on the Open Course platform, (which relies heavily on tables), we both felt there was scope to review the current layout and explore potential alternatives.

Within the tables, we also identified that a more consistent and informative approach to formatting links as well as creating more effective headings could improve the user experience.

In addition, Alex was keen to look at the best ways to support Open Course publishers with content design and embed ways to make it easier for them to prepare effective content. To this end, we talked through potential guidance and training that could be developed with a specific focus around Open Course content.

We spoke with Open Course publishers to gain their perspectives

Before progressing any further with our ideas, we were keen to establish a baseline understanding of how Open Course is currently used by those who publish content on it. This would help us to learn about their processes and approaches, identify pain points as well as areas that were working well.

Alex reached out to Informatics colleagues to see if they would be happy to speak to us about their experiences of using Open Course. In late January / early February 2026 we carried out a series of semi-structured interviews.

Format and aims of the interviews

The UX Service facilitated the interviews via Teams, observed by Alex, to learn about the experiences of Informatics colleagues who published content on Open Course. Informatics colleagues shared their screen and talked through how they achieve content publishing and formatting tasks in Open Course. This enabled us to see first-hand how they went about these tasks and hear their perspectives and feedback.

The aim was to confirm areas that were working well and also the main pain points. We were keen to learn the reasons why tables were used, what the experience was like for those editing content within them and understand more about their approach to writing headings and links.

We gained a lot of useful information from the interviews both from a content perspective, but also in relation to more technical aspects relating to the platform itself which Alex could feedback to Graham Dutton, the developer working on Open Course.

This information then provided the basis on which to form an action plan around how to make improvements and decide on the best way to provide support and/or guidance.

Tables: were they necessary, if so could they be improved?

Following our discussions with Alex and the semi-structured interview insights, we felt we had a good understanding of how tables were used and the pain points relating to editing content within them.

We first wanted to explore whether tables were needed, or if there were alternative layout options to avoid the need for tables completely. If they were needed, we could then look at how they could be improved?

Prototypes were created by the UX Service

The UX Service mocked up some prototype tables, initially in Word before also creating them in an Open Course playground site we had access to. We used the following ‘Schedule and materials’ page, where almost all information was displayed in a table.

INF2-SEPP: Schedule and Materials | Open Course Materials

Prototype one

Our first prototype involved removing tables completely and using headings and paragraph text to display the same information. What we soon realised was that this made the information hard to scan and increased the length of the page. We felt from trying this approach, there were definite benefits to having a structured column layout to help communicate key dates and materials for course participants efficiently.

Prototype two

Our second prototype then explored how we could improve the current table layout and make it as accessible as possible. The existing page had a continuous table with six columns. All headings and links were included in the table itself which made it quite hard to navigate. Also, the number of columns meant that text was wrapping onto two lines quite often, which again impacted on readability.

We explored presenting the same information in a two-column layout, using rows with clear left-hand headings to signpost key information. We also split the continuous table into multiple tables, one for each week of the term. Column and row headers were also applied within the table editor tools. These changes we felt improved the overall look and feel of the page but also made it easier to navigate to the information you needed.

Stress-testing prototype two

After sharing both options with Alex, we decided to proceed with prototype two and carried out some further testing to make sure it was fit for purpose.

JAWS – Screen reader testing

Using the prototype in the our Open Course playground site, we used JAWS to test out how the content on the page would be navigated and interpreted by a screen reader.  Whilst this approach may not fully capture how all users of assistive technology navigate, interact and experience the page, it did provide useful insights around how tables in Open Course interact with screen readers. Overall, the new table layout responded well.

We found that JAWS:

• read out the number of columns and rows in a table as expected.
• navigated the table content in a logical order. It interpreted tabled cells moving from left to right, first reading the column headers (‘dates’, ‘themes’) before information and links within the cells.

JAWS didn’t pick up on blank cells within the table. Instead, it moved to the next table cell which had content within it. Therefore, we recommended that if this table layout was adopted that there should be no blank cells to aid clarity. Where there was no information to put within certain cells, text such as ‘no milestone’ or ‘no tutorial’ should be used.

We are also aware that screen reader users can and may wish to jump from table to table on a page. When navigating in this way, JAWS moved table content to table content without reading out the assigned ‘Week X’ heading we had inserted. Therefore, when you have multiple tables on a page, it’s hard for the user to tell which table they are on. A potential solution to aid understanding could be to incorporate the week number within the table itself, rather than using headings.

Magnification and responsiveness on mobile

When tested, the page (including tables) responded well to 400% magnification, with no loss of information. This check was carried out to ensure that the content reflows correctly for users who routinely view web pages using zoom functionality. We wanted to ensure that information did not move off screen or overlap when zoom was used.

The tables also responded well in mobile view, including when the screen was rotated. This is important to test given the increased usage of mobile devices to access digital content, to ensure all users were able to easily read / navigate the information on the page.

UX Service recommendations

Recommendation to use prototype two table layout going forward

Following our prototyping and stress-testing, we reported back to Alex that prototype two was the option we would recommend.

Recommendation to consider best formats for guidance on headings and links

From reviewing the pages and considering the insights gained from the interviews, we also felt that it would be beneficial to create guidance around:

• writing effective headings and using correct heading levels in tables
• how to use links and write effective link text.

Having this guidance close to hand, ideally accessible directly from the edit screen of the Open Course platform would be preferable to enable ease of access for users.

Reflections and next steps

As a team, we really enjoyed working with Alex on the project. It provided us with the opportunity to apply the content design best practice principles that we teach specifically to learning and teaching content. It was interesting to explore and test out options for using tables in a different context, outwith the central EdWeb 2 Content Management System, for student-facing content.

We are glad that the Effective Digital Content online course provided the impetus for this work. We hope that the course continues to provide the starting point for interesting conversations about how digital content can be improved as it reaches wider audiences around the University.

We look forward to continuing to work with Alex in relation to the guidance and potential implementation of the new table layout before the next semester or at an appropriate time in the future.

AI tools to support content tasks are becoming more and more widespread. As part of my contributions to open-source Drupal I’ve been researching how to prepare and package content design and style rules that these tools can use effectively.

Using AI to help with content design tasks (and indeed, any other type of tasks) is now standard practice for many. As anyone who has experimented with it knows, the value the AI can provide is largely dependent on the prompt it receives, and the contextual data and information it is given to work with.

The way you provide your chosen AI with context affects the results you get

I have encountered two main methods for providing AI with context data. The first is the ‘prompt and pray’ approach, where you start with vague instructions and then engage in back-and-forth to drip-feed the AI the necessary information in the conversational turns. The second is the ‘context engineering’ approach, where you front-load information to proactive guide the AI, for example, defining its role, setting explicit goals, providing background and adding contextual constraints and rules.

Context engineering is more proactive than prompt and pray

Prompt and pray is better suited to a standard LLM interface or chat assistant (like ELM or Claude), and is the preferred choice when you’re looking to brainstorm and experiment, and are happy to take variable outputs. Context engineering relies on a more structured interface, designed to handle workflows (like Claude Skills) and is therefore the best choice if you’re looking for consistent, predictable outputs within set parameters, but it requires you to prepare your context data upfront, and for your chosen AI mechanism to have a way of handling it.

The Drupal Context Control Center is a management system for context data

Context data is a term given to the structured, site-specific knowledge – such as brand guidelines, regulatory requirements, editorial rules, and terminology – that tells an AI how you want it to work, to ensure its outputs reflect your actual preferences and standards rather than generic defaults.

In January 2025, our team was fortunate to spend a day of Drupal AI experimentation with specialist company Freely Give, in which we applied AI solutions to some of the web content management and design problems faced by the University. One of our experiments involved prototyping a basic style-guide checker into EdWeb2.

Read about this early experiment in my blog post:

An automated Editorial Style Guide? Experimenting with Drupal AI Automators

Looking back, this experiment was a very basic form of context handling, and since then, following the launch of the Drupal AI Initiative in June 2025, there have been rapid developments in thinking about AI and context. The Drupal Context Control Center (CCC) was initiated specifically for the purpose of enabling AI to handle context data and I am proud to have worked on its design, collaborating with Kristen Pol, Aidan Foster and others from the AI Initiative.

Read about the Context Control Centre on its project page on Drupal.org

To design the CCC architecture we brainstormed context application scenarios

Starting with a blank page, we started trying to come up with the main building blocks that the CC needed to have, but we found it very difficult. Drupal is phenomenally flexible which meant every function we wanted could be achieved in various ways. We quickly moved from thinking in the abstract to considering real-life scenarios when people would want to use AI to make use of context data to control what happened with their content which helped us tease out the tasks we wanted the CCC to support.

An example scenario was as follows:

Content creator wants to refresh a prospective student recruitment campaign. They ask the AI, integrated in the content management system, to help. Acting on the instructions, the AI prepares a sample campaign page which includes a slogan that doesn’t match the voice and tone and contains images from winter when the campaign is for summer. The content creator rectifies this by providing the voice and tone guidelines and updated imagery. The AI tries again, it’s better but this time there’s a word spelled differently from the style guide. The creator uploads the style guide rules. The page looks good, but the content creator wants another version to compare. The AI comes up with a version 2. The content creator wants to track interactions with the first version and swap to the second based on performance. To do this they connect their Google Analytics Acquisition reports and give the AI instructions of the thresholds to look for, to initiate the change.

We defined building blocks of the CCC and the relationships between them

Considering what would be needed to support the scenarios we came up with, we identified that the CCC needed to house several types of data and we thought about the dependencies and interactions the CCC would need to support.

1.     Data items that set out ‘the What’

First and foremost, the CCC needed to include the context items (rules and guidelines) such as:

• Brand guidelines
• Voice and tone rules
• SEO keywords
• Campaign or project briefs
• Style guide
• Image bank
• Pattern library

In addition, it needed to contain subcontext items (more refined versions or child/subsets of the context items) such as:

• New product brand guidelines
• Seasonal campaign copy
• Seasonal image set
• Landing page pattern set

2.     Data that set out ‘the When and How’

As well as the various sorts of rules and guidelines, the CCC also needed to include details of the circumstances and situations in which to apply them. Collectively, these were called the context scopes and they mapped out boundaries and constraints such as:

• Global (site-wide)
• Site sections
• Content types
• Use cases (for example – writing teaser copy, working with images)

3.     Mechanisms that control how agents select context

Connecting the ‘what’ with the ‘when and how’ relied on AI agents identifying context scopes and selecting appropriate context items to apply. For this to occur successfully, the CCC needed to include some means of facilitating as well as guardrails to steer suitable choices. These included:

• Context limits (limiters on numbers of context items and tokens)
• Scope subscriptions (agent configurations to define opt-in or opt-out)
• Target entities (specified content entities with context built-in)

We tried out terms in practice before deciding on labels

Labelling parts of interfaces is always tricky, particularly within Drupal where certain words have legacy meanings and, owing to its flexibility the functionality associated with terms may change over time. It was especially important to make careful label choices for the different parts of the CCC architecture, given its anticipated universality.

To inform my work on the CCC I decided to re-read ‘Design by Definition’ by Elizabeth McGuane, which book sets out and appraises a range of approaches for deciding upon terminology, labels and names for objects.

When choosing a name to fit a system, the author recommends appraising the options against three criteria:

• Novelty – how standard or unique the name needs to be
• Flexibility/mutability – how well the name works in different contexts
• Memorability – how easily the name is recalled

Applying this idiom helped us decide upon several key CCC terms, including:

Context item: any piece of information fed into an AI powered mechanism (typically an agent) to help the AI’s working memory to produce responses and outputs that are accurate and tailored to the users’ requests.

Context source: origin of any piece of information fed into an AI powered mechanism (typically an agent) to help the AI’s working memory to produce responses and outputs that are accurate and tailored to the users’ requests.

For the CCC to work as intended, inputs need to be machine-readable

With key parts of the CCC defined and the architecture mapped out, we started to consider how well the CCC could handle variations of context data loaded into it. This required us to think more broadly about how AI makes sense of information.

In the excellent book ‘Machine customers: The evolution has begun’ by Katya Forbes, the author outlines many use cases where people enlist AI agents to take care of tasks for them and diagnoses the underlying factors necessary for the AI to satisfactorily work on behalf of the people concerned.

In one such use case she breaks down the stages required for a human to take a purchasing decision compared to a machine.

For a human to decide on a purchase, they go through the following stages:

1. Awareness – ‘I have a problem’
2. Interest – ‘This might solve it’
3. Consideration – ‘Let me evaluate my options cognitively and emotionally’
4. Intent – ‘I’m leaning toward this choice’
5. Purchase – ‘This feels right’

For a machine to decide, the stages are different:

1. Query initialisation – parameters received ready to begin search
2. Discovery – options identified that meet basic criteria
3. Evaluation – comparing options against weighted parameters
4. Verification – validating performance claims and reliability
5. Selection – optimal choice identified based on data

From this comparison use case, it is clear that designing contextual data such as guidance documents to be used by AI requires a different approach to designing content to be read by humans. In particular, writing guidance information that relies on sentiment and/or subjective interpretation will be lost on AI and therefore not applied in the ways intended.

In its current form, our Editorial Style Guide is only partially AI-ready

Last year, in the early days with ELM, members of the UX Service tested ELM’s ability to apply the rules of the style guide to check content. They found it had limited success and found that in some cases, ELM applied its own rules to checking the content which couldn’t be traced to the style guide. Reviewing this experiment in light of the machine customer journey, it becomes clear that for an AI like ELM to faithfully and consistently apply style guide rules, the rules need to be written in a way that demands minimal interpretation, in other words, a deterministic way.

Read John Wilson’s blog about experimenting with ELM and the style guide:

Testing ELM’s ability to return useful results with prompts about the Editorial Style Guide

Adopting a ‘machine-first’ lens to the Editorial Style Guide to analyse content in selected sections, it is possible to pull out some of the deterministic (automatable) rules to compare with non-deterministic (requiring judgement) ones.

Analysis revealed deterministic and non-deterministic rules in the Editorial Style Guide

I completed a quick review of three sections of the style guide to assess how AI-ready they were.

1. In the Headings and page titles section

Deterministic rules:

• Do not skip heading levels
• Do not use H5 or H6 headings (maximum four levels)

Non-deterministic rules:

• Use word and language your users will be looking for and familiar with
• Write descriptive headings – avoid vague words

2. In the Acronyms and abbreviations section

Deterministic rules:

• Do not put full stops or spaces between letters of an acronym
• Do not abbreviate Professor to Prof
• Do not use eg, ie or etc

Non-deterministic rules:

• Spell out acronyms multiple times on long pages or pages with accordions
• Well-known acronyms don’t need spelling out
• Use abbreviations only when better known than the full version, or when space is limited

3. In the Links section

Deterministic rules:

• Do not use a URL as link text
• Do not use ‘click here’, ‘more information’, ‘learn more’ as link text
• Put links on a new line, not inline in a sentence

Non-deterministic rules:

• Add details about what a link will do (open in a new tab, require a University login) where relevant
• Avoid duplicating links where you can
• Reserve button styling for the most important links

Going through this short exercise with our style guide established that before we can make valid use of AI-powered features like the CCC, there is preparatory groundwork required to some of our content design guidance and rules more AI-readable, and potentially to create a new machine-readable version of the Editorial Style Guide.

I’m looking forward to investigating the potential for the CCC at the University

My work with others in the Drupal community on the CCC has led to a successful release of a beta version, with a release candidate coming soon, planned alongside the regular Drupal AI module release cycle.

Building on our early AI experiments with the style guide, I am keen to lead the UX team to explore the CCC’s potential to handle and apply editorial rules within a Drupal-powered CMS like EdWeb2. Our previous research with web publishers tells us that applying the style guide consistently can be genuinely difficult, and as AI-powered content design tools like the CCC continue to emerge, there is real opportunity to put this to work on the challenges our publishers face.

Read about our previous research with publishers about using the Editorial Style Guide

An analysis of responses to our Editorial Style Guide survey by Hannah Watson

Usability testing the Editorial Style Guide site by me in my previous Content Designer role

Full automation of good content design is unlikely and undesirable but it may be possible to offload some of the more straightforward rules to an AI mechanism like the CCC, freeing publishers to focus their attention on the trickier aspects of content preparation. Taking a machine-assisted view will also provide the chance to revisit existing non-deterministic rules to assess whether some could be made more granular, broken into sub-contexts or context scopes for more precise application.

In line with our broader aim of improving the tools available to content publishers, I am excited to see what the CCC can offer for real-world content design challenges at the University.

 

It’s been a whole year since we launched the new and refreshed Effective Digital Content online course. To celebrate the one-year anniversary I thought I would reflect on how the year has gone, share a bit more about what we’ve learnt along the way, and what is coming next.

If you are keen to read more about the development of the course up until the launch date, you can take a look at our previous series of blogs.

Effective Digital Content blog series

Over 350 people have completed the course in the last year

The aim of the Effective Digital Content course has always been to share content design best practice across the vast University web publishing community. We are really happy that so many people have successfully completed the new version of the course, particularly given the new workbook element which we appreciate comes with an additional time investment. It shows a real willingness from the web publishing community to learn more about how to create effective web content.

As a result, over 350 Digital Badges have been issued under the University’s Digital Badge scheme ‘BadgEd’. Again, this is a real positive in terms of showcasing continuing professional development within our publishing community and we’ve seen people sharing their badge with their networks on LinkedIn.

Effective Digital Content badge details

The course workbook – reaping the rewards of trying something new

We’ve written in previous blogs about the decision to add the new workbook element to the course. For us this was very much a case of trying out something new, as it wasn’t something that had been explored in previous versions of the course.

The workbook idea was born out of a wider project to rethink our content design training approach. The key premise of the workbook is to provide a chance for people to apply the course principles to their own context and receive feedback from someone in the UX Service.

Practical application of the course principles with the opportunity to gain valuable insights from the UX Service was something we had seen work really successfully in our Content Improvement Clubs (our regular meet ups for anyone who publishes web content at the University). The task of delivering this at scale given the ratio of UX Service team members to web publishers was quite a daunting task, but one which I’m pleased to say has been a great success.

Over the last year 350 people have completed the workbook and received personalised feedback from the UX Service on their submission – no mean feat from either side!

We’ve had positive feedback about the personalised workbook feedback

We are so pleased with how the workbook has been received and the effort people have taken in completing it. We’ve seen people updating and improving their web pages as they complete the workbook exercises and in response to the tailored feedback we provide. It has been really rewarding to help facilitate and see tangible positive change in this way.

Here’s what a couple of people who have taken the course have said about their experience of completing the workbook.

I enjoyed completing the workbook as it allowed me to reflect on the various aspects of the course. Receiving feedback on the workbook was a great addition and not something I’ve had in other training courses I’ve completed.

Whilst time-consuming, this was very valuable as it really enabled engagement with the material, enhanced my learning and I feel confident in updating the web page I am responsible for now. The feedback was helpful too, thank you.

We’ve gained valuable insights from reviewing the workbooks

The UX Service have also found it incredibly useful to hear directly from publishers through their workbook answers. The process of reviewing and responding to each submission has provided invaluable insights which can help us to enhance the training we provide by responding to topics and areas which we know are most relevant.

Since the launch, we’ve also made further improvements to the workbook activities as well as the course modules in response to feedback we’ve received.

Taking on the task of reviewing each workbook has been a significant new workload for the team and we’ve been on quite the learning curve. However, we are pleased with how collectively we’ve taken on the challenge and the feedback turnaround times we’ve managed to sustain.

We are evolving and refining our processes to keep up with increasing demand

As demand for the course continues to grow from colleagues across the University, we are looking at ways to refine and automate some of the administrative processes involved in receiving and logging workbook submissions. This is to ensure we can continue to provide tailored feedback to an even larger number of people across the University.

We are developing the course for the Short Courses platform

Following a showcase of the course at the UCISA UX Community Day in September 2025, we received interest in the course from the wider Higher Education sector, with colleagues from other UK universities requesting access to the course content, so that they could apply the concepts to content publishing in their respective institutions.

In response, we are currently working with colleagues to deliver a proof-of-concept course for the Short Courses platform by summer 2026. You can read more about how we are repositioning the course for an external audience in Emma Horrell’s blog.

Repositioning Effective Digital Content as a short online course: A product approach

How to take the course 

If you’d like to take the Effective Digital Content course, you can find more information on our course page, including a link to enroll through People and Money.

Effective Digital Content 

Progressive thinking about inclusive content combined with a review of our content design tools prompted us to look at the effectiveness of our Inclusive Language Guide. Before we could think about improving the guide, however, we needed to ensure staff knew it existed.

Since the relaunch of our Effective Digital Content course last year, and following a succession of content improvement club sessions regularly attended by web publishers and content creators, it’s been gratifying to see more and more University staff learning about content design and putting theory into practice. The raised awareness and interest gave the UX team cause to review the guidance we direct staff to follow, to check that it’s as clear and easy to apply as possible.

The Inclusive Language Guide (ILG) was published In June 2022, following months of careful research, investigation and analysis by Ari Cass-Maran, former Senior Content Designer of the UX Service. Nearly 4 years on, amidst increasing UX and content design maturity, it was timely to revisit the guide with a view to improve it. Before we could think about improvements, however, we firstly needed to appraise how well the guide was known and being used by University staff.

Read more about the origins and publication history of the Inclusive Language Guide in Ari’s blog posts:

Inclusive Language Guide

Inclusive Language Guide: how we co-designed with our community as part of a human-centred Design System

Inclusive language awareness and practices have advanced since we published our guide

Since 2022, there have been many positive developments in inclusive language practices and approaches in the public sector and beyond. In November 2023, members of the Home Office Digital team created inclusive language guidance as part of their goal to embed diversity and inclusion into their research and design practices. In September 2024, the Department for Education published the first release of an Accessibility and inclusive design manual and initiated research to learn how easily users could find information within it, with a view to making improvements for a second release. Further afield, in 2024, the Council of Europe published inclusive language guidelines and the European Institute for Gender Equality published ‘Words Matter’ a guide and associated toolkit designed to encourage more gender inclusive language practices. Content-design publications like ‘Considerate Content’ by Rebekah Barry and ‘Designed with Care: Creating Trauma-informed content’ by Rachel Evans and contributors helped shed light on practical ways to prepare content in more sensitive ways, for example, taking into account needs associated with neurodivergent conditions and needs triggered by previous difficult experiences. On a more conceptual level, Karen Yin’s book ‘The Conscious Style Guide: A Flexible Approach to Language that includes, respects and empowers’ prompted a philosophical approach to inclusive language use, going beyond lists of ‘do’s and don’ts’, instead, calling for engagement with changing cultural norms to make decisions around language use within a framework guided by content, context, consequence, complexity and compassion.

Read about some of the developments in inclusive language practices:

Conscious Style Guide website

Inclusive language by design, published 22 November 2023 on the Home Office Digital blog

Accessibility and inclusive design manual blog, published 29 October 2024 on the GOV.UK website

Guidelines for the use of language as a driver of inclusivity by the Council of Europe

Words Matter: Supporting Gender Equality Through Language and Communication, published by the European Institute for Gender Equality

Before we could make improvements, we needed to understand the guide’s current use

Working in UX, with its overarching aim of making things better for people, it can be tempting to track developments in user-centred design and apply emerging thinking directly to the work in front of you – in this case, the iteration of our Inclusive Language Guide. But to make changes that are meaningfully impactful, it is often better to pause first and understand the current state in order to plan accordingly. In this instance, that meant taking time to assess how our existing guide was performing – to find out whether it was known, adopted, and being applied by  University staff with content publishing responsibilities.

Appraising the guide’s effectiveness involved assessing receptiveness, discoverability and findability

We weren’t certain whether staff knew about the Inclusive Language Guide, let alone whether they were using it. In order to find this out, we identified two broad categories of behaviour that would indicate successful engagement with the guide.

The first related to receptiveness – did staff realise the need to write inclusively, or recognise that inclusive language was something they needed to think about at all? , in other words,  that inclusive language was’a thing’?

The second related to information-seeking- once staff had identified the need, how did they go about addressing it? The answer depended on whether the guide was findable (for those who knew it existed) or discoverable (for those who didn’t).

These behaviours mapped neatly onto a framework from an old but still salient blog post from 2006, in which Donna Spencer wrote about four modes of information-seeking:

• Known item seeking – looking for something specific you know exists
• Exploratory seeking – browsing when you have a general sense of what you need
• Don’t know what they need to know seeking – no clear awareness of the gap or what would fill it
• Re-finding seeking – locating something you’ve accessed before

Four modes of Seeking Information and How to Design for Them (Boxes and Arrows blog)

When it came to the Inclusive Language Guide, the staff who already knew it existed would draw on known item seeking or re-finding behaviours, and if those succeeded, the guide could be considered findable. Those who had identified a need but didn’t know the guide existed would rely on more exploratory methods, and if those succeeded, it could be considered discoverable. Our research needed to probe for all of these.

We developed a scenario-based test to understand perceptions and expectations around inclusive language

Before beginning any piece of research, the UX team thinks carefully about what we want to learn, framing our intentions as explicit research questions. Working together, Mel Bacharj, Content Design Assistant, and I identified three core questions to guide our research:

• Do staff know the guide exists and the type of guidance it includes?
• Do they know what it can help them with?
• Can staff recognise situations where it would be useful to them?

Drawing on UX and product literature, we identified a scenario-based approach as the right method for testing whether staff felt a genuine need for the guide. Rather than asking directly about the guide itself, we would present participants with a content preparation scenario where the guide’s rules could apply, and observe whether they recognised the need unprompted. This approach is grounded in the principle of ‘talk about their world instead of your idea – described by Rob Fitzpatrick in the book ‘The Mom Test: How to talk to customers and learn if your business is a good idea when everyone is lying to you’ – which cautions against asking people about a product or tool directly, since doing so tends to invite polite, unhelpful answers.

From there, the research followed a logical sequence. If participants identified a need for guidance on writing inclusively, the next stage would ask how they would naturally go about finding that information – testing whether the guide was discoverable. If they located it, the final stage would assess whether they could find relevant guidance within it to help them write inclusively in the content preparation scenario we had tasked them with.

Based on initial findings, we’ve improved the guide’s visibility by adding it to key websites

Following our research plan we conducted testing with staff volunteers and the results were insightful – revealing staffs’ current perceptions, expectations and understanding of inclusive writing practices. Further, more detailed analysis will follow, however, having watched participants search for inclusive language guidance, an primary research finding was that the guide was not that easy to find.

We wanted to act upon this finding as soon as possible, so we reached out to relevant site owners and have now successfully added a link to the guide from the following webpages:

Disability Information | Help | Information Services – Linked from the question: ‘How do I make sure I use the right words to write about disabilities and disabled people?’

Helpful links | Help | Information Services – Added to the list of resources

The Social Model of Disability | Health & Safety | Health and Safety Department – Linked from a paragraph ‘The University’s Inclusive Language Guide contains advice about how to write about disabilities and disabled people’.

Staff EDI Learning | Equality, Diversity & Inclusion | Equality, Diversity and Inclusion – Linked from the Available Learning section

Further Reading and Learning | Equality, Diversity & Inclusion | Equality, Diversity and Inclusion – Added to the list of resources

Resources – by topic | Institute for Academic Development | Institute for Academic Development– Added to the list of resources

With the guide linked from more places, we are in a better place to work on improving its content, to ensure it can be found and used more effectively by those preparing content for the University.

A deep exploration of how aspect ratios shape perception, visual rhythm, and usability in modern interfaces. From grids to galleries to video players, this article dissects how proportion silently governs how users see, feel, and interact with content.

 

Content Improvement Club is our regular meetup for web publishers. In our March session, with a focus on accessibility, we explored how effective use of links and headings can make content easier to navigate and use. 

Accessible content is effective content

Accessible content is simply effective content. If people cannot access, understand or use what you’ve published, then it isn’t really doing its job. As the amount of online content continues to grow, making sure it works for everyone becomes increasingly important. We also see accessibility as a shared responsibility. Anyone creating or publishing content can make a positive impact.

Small changes can have a big impact

This session focused on practical improvements. Clear link text and well-structured headings help users process information quickly and navigate more efficiently, particularly people using assistive technologies.

These are small changes that do not require technical expertise, but they make a significant difference.

Accessibility and legal compliance

While we focused on practical changes, accessibility is also supported by a legal framework, including the Web Content Accessibility Guidelines (WCAG).

WCAG

Links and headings are still common accessibility issues

WebAIM’s annual survey shows that many accessibility issues remain widespread, often rooted in how content is written and structured.

Screen Reader User Survey #10 Results (WebAIM)

From the data, links and headings stood out as two practical areas to focus on. They are part of everyday content creation, quick to review and relatively easy to improve.

We have covered these topics before, but we wanted to take some time to focus specifically on links and headings considerations from an accessibility angle.

Designing for screen reader users benefits everyone

Assistive technologies such as screen readers convert content (such as text, buttons, images and other screen elements) into speech or braille. This allows blind or partially sighted users to access the same information as sighted users.

In the session, we focused on how screen reader users experience content. Designing with them in mind has a much wider benefit. What improves content for screen reader users also improves the experience for people using other assistive technologies and often for all users.

Demonstrations using JAWS

To support this, we included demonstrations using JAWS (Job Access With Speech), a screen reader. These showed how content is interpreted by assistive technologies.

These demonstrations are only part of the picture. Screen readers are complex, and people use them in different ways. They do not represent every user experience, but they are a useful way to build understanding.

Making links more accessible

Clear link text helps users:

• predict what will happen when they open a link
• find the content they need more quickly
• avoid opening content that isn’t relevant

Replace raw URLs with meaningful link text

One of the most common issues we see in content is the use of raw URLs (or web addresses) as link text. Raw URLs can create usability and accessibility issues. They are difficult to interpret and screen readers read them character by character, which can be slow, frustrating and unclear.

Clear link text is much easier to understand and navigate, especially for people using assistive technologies. Instead of using a full web address like ‘https://www.ed.ac.uk/’, use meaningful text such as ‘University of Edinburgh’.

We demonstrated how replacing them with descriptive link text improves accessibility by looking at some examples. This included using JAWS recordings to compare how raw URLs and descriptive links are experienced by a screen reader user. Here’s an example from the session:

Raw URL version: ​

Link text version:

This helped highlight how adding meaningful link text gives users a clearer and more immediate understanding of where a link will take them.

Link text must make sense on its own

Screen reader users often navigate by jumping from link to link or by viewing a list of links on a page. This means link text needs to make sense out of context. It should be clear, predictable and meaningful on its own.

Avoid vague phrases such as ‘Click here’ or ‘More information’. Instead, include key details about where the link will take the user.

Again, we considered some examples to showcase what we meant:

• Vague link text: ‘Click here’
• Improved link text: ‘Click here to book a ticket for the event’
• Best link text: ‘Book tickets for Content Improvement Club (opens in a new tab)’

We also discussed the importance of making each link distinct when linking to different destinations. For example, there may be multiple links to different sets of teaching materials or slides. Instead of using the same generic link text, like ‘Slides’, across the board, you can improve clarity by adding context:

• Vague link text: ‘Slides’
• Improved link text: ‘Lecture slides (Week 1)’
• Best link text: ‘Lecture slides (Week 1): Course introduction’

During the session, we compared how these links appear in a screen reader’s list view. This helped show how important clear link text is when experienced out of context.

Position links on a new line

University style is to place links on a new line, usually below the relevant paragraph, rather than embedding them mid-sentence.

This makes it easier to write link text that works on its own and helps users who navigate from link to link.

Making headings more accessible

Headings do more than break up text visually. They create a structure that helps users understand content and navigate efficiently, particularly those using screen readers.

Do not skip heading levels

Headings are structured in levels, typically from Heading 1 (H1) down to Heading 6 (H6).

Each level should follow a logical order. For example, use:

• H1 for the page title
• H2 for main sections
• H3 for subsections

Skipping levels can make navigation more difficult for screen reader users, who rely on a consistent structure.

We looked at an example from a University page to demonstrate correct heading structure.

Seeing this in a real life context made it clearer how heading structure organises a page and supports navigation and understanding.

Headings reflect content hierarchy, not style

Headings have visual styles, but they should not be chosen based on appearance alone. Use headings to reflect the structure and importance of content, not to make text look bigger or stand out.

If you need to emphasise content, use alternatives such as bold text or feature boxes rather than misusing heading levels.

A way to check heading levels

During the session, we demonstrated the W3C Heading Checker, which we often use to review headings.

W3C bookmark tool for checking headings

This tool provides a quick way to review page structure and flags any skipped heading levels in its checks. In groups, we used this to quickly assess headings across our own pages, evaluating headings and making suggested improvements.

Guidance on links and headings in the style guide

The UX team has been reviewing and updating the University’s Editorial Style Guide. It includes detailed guidance on links and headings, expanding on the points in this post.

Guidance on links in the editorial style guide​

Guidance on headings in the editorial style guide

Our next Content Improvement Club

In our next session, the topic we’re covering is:

Editing that works: nine techniques for improving content

In the session, we’ll practise using a nine-step editing process to improve web content.

Date: Wednesday 22 April 2026

Time: 2pm to 3:30pm

Place: Edinburgh Futures Institute, Room 1.52 (in person only)

Content Improvement Club: 22 April session

How to hear about future sessions

We promote these sessions via our mailing list. If you’re interested, please sign up:

Join the UX and Content Design mailing list (University login required)

Suggest a topic for a future session

We’re keen to continue covering topics that colleagues across the University would find useful. It would be really helpful if you could let us know any ideas you have using this form:

Suggest a topic for Content Improvement Club (University login required)

Other training that we offer

More training is listed on the User Experience Service website:

Training | User Experience Service

The Role of Profiles project produced 10 recommendations for an improved University profile provision. To start actioning these, I assembled a working group of specialists and drew on UX design principles – implementing practical prioritisation while seeking innovative solutions that addressed the research findings.

Recognising the widespread value and strategic importance of communicating the work, accomplishments and status of University staff, the UX Service undertook a research project to investigate the needs and requirements for an improved provision to publish profile content within the University web estate. The project uncovered many insights, brought together in a series of technical and non-technical recommendations. Since the research project closed, I have been looking for ways to act upon the recommendations, in a bid to make them happen and crystallise a new profile provision for the University.

Read about the profile research project in our series of blog posts

To start bringing the recommendations to life, I needed a UX design process to follow

In the absence of a formal follow-up project to implement the recommendations, and recognising the unwavering importance of profile content being available on University websites, I was keen to retain momentum and to keep profiles on the agenda. Having worked as a UX Lead in different realms, I have learned about various UX design processes to effect technical builds. I was keen to experiment with an approach based on the Agile Squad method, which brings together individuals from multidisciplinary teams to focus on specific feature areas of a technological solution. This seemed like a good fit for profiles, firstly as a way to break down the recommendations into smaller tasks, and secondly as a way to harness the University-wide knowledge and expertise about profiles my team had uncovered as part of the research.

Read more about the Agile Squad Model in project management in an article on daily.dev

I set up a specialist squad to continue making progress on profiles

In the latter stages of the profiles research project, I had ran two successful co-creation workshops, bringing together colleagues from different teams, Schools and Groups, all with different perspectives yet a shared interest in profiles. These workshops had demonstrated that, across the University, there were colleagues already developing profile solutions, and that there was a bank of innovative ideas to tap into – to help achieve an improved profile solution.

In the interests of starting small and keeping things simple, I formed a Teams channel which included staff from the Business School, the School of Engineering, the PURE team, IS Apps and EDINA. I initiated a round of discussions, brainstorms and show-and-tells to harness expertise and gather perspectives from each team in turn.

Reviewing the recommendations, I ranked them by what to tackle first

With the help of squad colleagues, I revisited the 10 recommendations from the research project to better understand the dependencies and complexities and accordingly, sort them into a prioritised order. The recommendations that required EdWeb2 expertise needed to be accommodated within the existing EdWeb2 roadmap and therefore were placed in a queue behind other priorities. Recommendations relating to profile creation and maintenance had dependencies on the updated provision being in place, and similarly, it was logical to schedule training sessions to help colleagues write effective profiles to occur once the new provision was available to use.

See the full list of project recommendations in my blog post: The Role of Profiles is to represent our staff: Recommendations and reflections from our project

It made practical sense to start by investigating data exchange solutions

One of the more sizeable recommendations from the profiles project was as follows:

Profiles should support the display of content from other repositories using technical solutions where feasible

This recommendation recognised the tendency of profile owners to publish content about themselves and their work in multiple sources, and their wish to be able to bring those content sources together, to display in a University of Edinburgh profile. To address this recommendation, I began some investigation work – primarily to find out about existing solutions for data exchange (both for profiles and more broadly) that would provide food for thought about how to break the recommendation down into small tasks.

A simple diagram served as a boundary object to align thinking and prompt collaboration

In technology design and innovation, reference is often made to the value of prototypes and wireframes as a way to crystallise thinking and to spark ideas. In this piece of work, a diagram depicting the expected interactions to achieve data sharing between different systems served as a useful artefact to bring a shared way of thinking across the teams and to prompt ideas for achieving the different aspects of the proposed idea.

A workshop with Business School colleagues helped formulate a proof of concept

UEBS operates a non-EdWeb site, and to meet the need to display profile content of UEBS colleagues, the technical team had devised a solution that parsed data from fields within PURE (the University’s primary research repository, operated by Elsevier) and displayed it in UEBS staff profiles. As part of the profiles squad, the UEBS team shared details of their solution to enable critique and assessment of its suitability for wider, scaled-up production.

Having learned about what worked, what didn’t and the associated requirements and dependencies, and keeping in mind the user requirements from the research project, it felt appropriate to propose developing a minimal viable product (MVP) for the University-wide profile solution. Defining the MVP was helpful to give us something to aim for in the short-term, and we recognised that in the process of working towards delivering the MVP, we would learn along the way and ultimately get closer to a solution that was feasible to deliver for the whole University.

The MVP contained three parts:

1. Profile data coming from PURE or from another identity source, such as People and Money or the Active Directory
2. A Drupal 11 site within EdWeb2 with a profile entity to handle the data
3. A School site to ingest the data

Breaking this down further, we agreed that the first step would be to make some PURE profile data available to be consumed by the Drupal 11 site – envisioned to be achieved with a single PURE ID of a person. A subsequent step would be to expose the data as a JSON feed from the Drupal 11 site, ready to be consumed by the School site.

Meeting the PURE team helped tease out typical repository dependencies

Given a key part of the MVP was data-sharing from PURE, the next logical step was to learn from the PURE team about the possibilities for data extraction from this system. On the technical side, the team shared PURE API documentation with details of data endpoints and new data formats to help with modelling the data consumption planned for the MVP. They also shared information about PURE’s upgrade path and ongoing maintenance needs which was important to consider within the context of the planned profile solution. Reflecting on requirements of PURE end-users, the team revealed trends for PURE profile data – for example, the need for academics to not only capture detail of their publications but also of their research activities within PURE. This was interesting to hear as it mirrored a finding from the profiles research project relating to profile content.

Furthermore, the team provided insight into broader requirements for the use of PURE data, including integrations with other systems, for the purpose of support and publicising research activities in alignment with high-level University strategic objectives (such as REF 2029). Understanding the wider landscape was helpful to reinforce the potential of the improved profiles provision we are aiming to achieve and the key role of PURE within that.

Learning about integrations from IS Apps colleagues offered an innovative way to look at data sharing

The team from IS Apps recently presented about their use of Choreo – a cloud-native platform which powers their newly-launched integration service. Choreo has the capacity to manage APIs and integrate services and systems, affirming its potential usefulness as part of our improved profile provision. Meeting the IS Apps team to explain our goals for a profiles MVP, we began to consider options for being able to make use of identity data APIs to receive baseline data to populate profiles for part 1 of the MVP.

Read more about the Choreo technology on the WSO2 website

Wider interest from the Higher Education Drupal community suggested opportunities for contribution

Having contributed to open-source Drupal for several years, I have built up a network of useful contacts for shared learning about Drupal solutions. Raising awareness of our profiles project in the Drupal community provoked a response from people in other institutions trying to achieve similar goals, leading to knowledge-sharing with institutions such as the University of Cambridge, Stanford University and the University of Bergen. As our squad progresses with its work, I hope that the University of Edinburgh can contribute an open-source technical solution that may benefit organisations like ours, and that may be taken and adapted for more and more use cases.

With EDINA and Drupal we ideated for potential use of AI: balancing opportunities with risks

Reflecting on ways of achieving data exchange between systems, it was natural to consider how AI could assist. Consulting colleagues from the ELM team within EDINA we explained our plans for the MVP as a provocation to understand the potential for AI. Between us, we identified the potential for MCP servers for contextual data transformation, to potentially deliver repository data dynamically in AI-ready formats. We also identified an idea for ELM to potentially deliver profile data from defined sources conversationally, in response to queries. Both ideas were subject to dependencies and further investigation.

Drawing on earlier learnings about use of AI to formulate profile content, we recognised the need for profile owners to be able to sense-check the content before it was displayed, to ensure it did not misrepresent them. For this reason, we resolved that if either of our suggested AI ideas proved technically viable, user research with profile holders should occur to inform actions and progress, to ensure full agency for personal data remained with those the data belonged to.

Read about a project experimenting with AI to generate profile content in the blog post: An AI tool for generating academic staff profiles using a pre-trained LLM – findings from a study

Considering tried-and-tested use cases for ELM, we identified that profile owners may like to make individual use of ELM to assist with the wording of their profile content, in particular to undertake tasks like writing the content in particular styles conference abstracts, providing ELM with the necessary contextual sources to be used to shape profile content in particular ways. I identified a potential test use case for a new Drupal AI module I have been contributing to, the AI Context Control Center (CCC), currently under rapid development within the Drupal community.

Read more about the development of the AI Context Control Center on Drupal.org

We have a way to go to implement the recommendations, but we’ve made a good start

All things considered, we’re getting incrementally closer to an improved profile provision, but we’re not there yet. Taking a UX design lead on developing a profile solution is helping to ensure we keep sight of the recommendations formed from the research project. Working in a squad that brings together people from multiple disciplines from the wider University provides a welcome way to learn about different colleagues’ ways of working, ideas and approaches. It is heartening and motivating to see the appetite and interest in profiles from colleagues around the University and from the wider content management community, and I feel confident that, with continued support, we will, in time, arrive at a better profiles provision to serve staff at the University.

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.

 

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.

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.

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.

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.