I’m Grace, the Web Registry Development Intern for the 2026 Summer! As my internship draws to a close, I discuss how my AI Supported Accessibility Testing, and my Web Estate Dashboard projects have progressed. The first project focused on investigating how AI can be used to automate accessibility testing websites. My second project aimed to produce a dashboard for non-technical audience so they could see their website statistics. I reflect on my project, my experience, and what I’ve learned.

AI Supported Accessibility Testing

Almost three months after I started, my internship is wrapping up. My Summer project aimed to investigate how AI can be used to automate accessibility testing, so we can make sure the web estate is in compliance with Web Content Accessibility Guidelines. Currently, most automated testing (programs like axe DevTools) catches approximately 30% of errors, I aimed to increase that accuracy and investigate where AI can be useful. I’ve learned a lot, but there’s still lots more for me to pick up! The goal was to get AI to test for WCAG violations more accurately, and see if it could be a useful tool in the testing process.

Findings

Rather mundanely, AI won’t be taking over the world anytime soon. AI supported accessibility testing still hovers around 30% accuracy.

Strengths

The agent is good at crawling through sites and identifying suspicious elements that commonly produce issues, things like a pop-up widget or a pdf. It also excels at anything related to markup languages, testing guideline 1.3.5, identify input purpose, for example, which looks to see if input fields are labelled correctly, so computers can autocomplete them. These black-and-white guidelines are easily digestible for AI, it’s when a human aspect in included that AI can stumble.

Weaknesses

In conversations with the accessibility team, it was noted that AI struggles with the “grey-areas” that pop up in the testing process. While the full list of WCAG guidelines is lengthy and specific, the primary goal is to make sites usable for all. A guideline may not explicitly outline why a website fails, but if a human finds it inaccessible, that means it’s inaccessible! An element’s context within a website can drastically change whether or not it’s WCAG compliant, this was something that agents struggled with. I found that agents are too scared to get something wrong to think critically or apply executive judgement.

Aside from that, guidelines that measure things like a logical tab sequence—measuring how intuitive it is for someone to navigate a website with a keyboard—should continue to be tested and reviewed by humans.

Methodology

In the beginning, I did some desk research to find the AI agent best suited for the task at hand. I investigated the different LLMs available through ELM, with varying success. They could analyse whatever screenshots I gave them, but that still required me going through a website and selecting information that was relevant. I pivoted to the ChatGPT software, which was then called Codex. Codex could exit its window and crawl through the site itself autonomously, more closely mimicking how accessibility testing is actually carried out. It was a bit of a learning curve, lots of failed audits that I got to learn from. Throughout the summer, I iterated a master prompt to feed to agents, tinkering away at it bit-by-bit. I made it modular, so it was easy to swap out guidelines based on what you wanted to test. Currently, the prompt sits at 7252 words, and each guideline is split into smaller sections.

The AI specifications section contributed the most to the wordcount. You have to be very specific about the exact path you want the agent to take. It’s good that you get to have specific control over the testing, less great when you have to soft-parent an agent through pressing the “Tab” key.

This prompt would then produce an audit report, this is distinct from a completed accessibility report. The audit was produced to help a tester identify issues, not to present findings to a wider audience. During my internship, I gave weekly updates to the accessibility team and I was consistently given really valuable feedback that I could integrate back into the master prompt. At the end of my internship, I started scoring the accuracy of the prompt against preexisting human accessibility reports.

Web Registry Dashboard

The aim of this project was to pull data from a registry service using its API capabilities and present it in a user-friendly dashboard. I wanted to make sure the entire process was cheap, secure, and easy to upkeep, qualities that can be tricky to balance all at once.

I split the project up into 2 phases. Phase 1 covered transferring the data from the registry to a PowerBI dashboard, which was a bit of trail and error, but was successful. Phase 2 covered adding specific filtered to the dashboard depending on the user, and these filters would be added autonomously, without requiring users to manually log in every time. Phase 2 was a lot trickier, and s still incomplete.

Methodology

Phase 1

This really tested, and expanded upon, my technical skills. Through my astrophysics degree, I do a lot of data analysis and presentation through Python. However, the data in a university setting is reliable, easy to obtain, and consistent, this isn’t the case with this project! It was really interesting working with data that has real-world implications and it changed the way I think about my data analysis. I used Python code to make my API calls—the thing that gives me the data from the registry—which confused me at first, but everyone on my team was happy to answer all my questions. I was able to pull the data from the registry and produce a PowerBI dashboard that presents all this data simply.

Phase 2This really broadened my experience with different types of data, especially sensitive data and the security that must come with it. Phase 2 results are still inconclusive, but good progress has been made.

Applying the filters to the dashboard is relatively straightforward. Phase 2’s main difficulty is accessing employees’ names and departments, data which is quite sensitive and requires high admin permissions to access. Naturally, any workflows would have to ensure employee data is handled securely. In order to produce a successful dashboard, the current web registry data would need to be completely reorganised. To create a robust dashboard, the data—including employee data, stored separately—would also need to be accurate.

What I learned

I’m still a long way from understanding the ins-and-outs of accessibility testing, but this project certainly built up my confidence in the subject. It encouraged me to think about the logic of these guidelines in creative ways, to make it better digestible for AI. After all, how would I train an AI to test a guideline if I myself didn’t understand it? While the project didn’t produce earth-shattering findings, the findings are still inconclusive. We should continue to explore tools to make websites more accessible, especially as AI continues to evolve.

The dashboard helped my technical skills grow, and taught me to come at an issue from many different angles as certain avenues were rejected. The dashboard project taught me that there sometimes isn’t a “right” way to do things and that sometimes you have to juggle conflicting considerations in a project.

Overall, I’m really grateful I got to evolve in this way and I’m excited to see what future projects can accomplish!

A student in Philosophy and English Literature is probably not what most people picture when they hear “web governance administrator”. Angelina initially did not picture herself in this role either.  

Two summers ago, after finding an ISG vacancy through Unitemps, she joined the University’s web governance team only expecting a summer job. Recently, she graduated as part of the class of 2026. In this interview, Angelina reflects on how the experience has changed how she sees the IT sector, the value of her humanities degree, and her own career options.  

 

Q: What is the story of how you joined ISG, and specifically your current role? 

I was looking for a part-time job over the summer when I came across the advert on Unitemps. The role sounded interesting because it covered quite a wide range of things. I would be helping to keep track of the University’s web estate, but there would also be opportunities to work on side projects depending on what the team needed. 

My dad worked in IT, so I guess I had always found the sector intriguing. I just never thought I would have the right skills for it because when people see an IT job, the usual immediate associations are with coding, math and very STEM-based skillsets. None of which I had as a student in Philosophy and Literature. The thing that really caught my attention and prompted me to apply in the end was that the advert specifically stated that they were “NOT JUST looking for Computer Science students.” Indeed, working here for the past two years showed me that there is much more to digital service work than purely technical skills. 

 

Q: What does your role as a web governance administrator actually involve?  

My main project has been auditing the University’s web estate. The University owns a huge number of websites. Different schools, departments, services and groups might create their own sites, but those websites still need to follow University standards around things like accessibility, editorial content and data protection. Additionally, sometimes a website has been sitting there for ten years, and the person who originally owned it has retired or moved on. If nobody is actively responsible for it, that can become a security and governance risk. 

A lot of my job is thus making sure our records are accurate. We bring together lists from different departments, work out where each website belongs, ensure it fits guidelines and requirements, and track down its owner. If there is no current owner, we contact the department and ask them to appoint someone. In short, our work is looking after the quite important behind-the-scenes structure that a lot of ISG works sit on top of. 

 

Q: Was the work what you expected when you started?  

Only partly. From what I had heard from previous interns in my position, I thought I would mainly be looking after an existing list of websites. 

My manager, Stratos, wanted us to take a more thorough look at the whole web estate. Thus, we were not just checking that a website appeared on a list. We were asking whether it was under the right department, whether the named owner was still there, and whether there were other University websites that had never been recorded in this comprehensive collection. 

The role expanded quite a lot from what I had imagined. It was more challenging, but that also made it more interesting. I’m always looking for ways to develop new skills, so I enjoyed having work that made me think problem-solve, rather than doing the same administrative task repeatedly. 

 

Q: Is any part of the job more complicated than people would assume? 

Definitely. Almost every process is more complicated than it looks from the outside. 

One might assume the University already has one perfect, complete list of all its websites. In reality, the web estate is enormous. To build an accurate picture, you have to speak to departments, website owners, suppliers, and different University services. A task that sounds simple can involve a very long chain of communication. 

Last year, for example, we worked on a SharePoint site explaining what people need to know before creating a university website. I initially thought we would simply put the information onto SharePoint and finish it in about a week. That was not the case at all. First, we needed to work out which departments had relevant expertise. Then we had to gather their information, review it with managers, and also make sure the SharePoint site itself was accessible. There are so many stages of checking, reviewing, and going back and forth. 

It made me appreciate how much work happens behind the scenes. As a student, it can be easy to look at a university system and think, “Why isn’t this more organised?” But once I started working from the staff side, I realised how many people and processes are involved in making anything happen. 

 

Q: Has your background in humanities prepared you for this job in ways people wouldn’t usually expect? 

Yes, especially Philosophy. A lot of what I do academically involves taking an argument apart, identifying gaps in information and thinking about possible criticism. That transferred surprisingly well into the auditing process. My degree taught me critical thinking. I became very good at asking “what if” questions. What if the website owner has retired? What if somebody else has taken over, but the record was never updated? What if a site exists but has not been included in any of our lists? Humanities subjects taught me to consider different possibilities of scenarios, which enabled me to predict potential hurdles and thus prepare solutions in advance or respond accordingly. 

It may sound cliché, but my degree taught me a lot about efficient and effective communication. In Philosophy and Literature tutorials, we constantly discussed ideas, explained our perspectives, and responded to each other’s ideas. It transferred directly to when I lead meetings with suppliers. I can explain why we need something, keep the discussion focused, and emphasize the information points that matter most.  

 

Q: What surprised you the most about working in digital services? 

How nice everyone is. I thought it would be a very intense environment where everyone knew exactly what they were doing and had strict expectations for you to match their pace. Instead, everyone has been really easy to talk to. 

 The working environment is one of the things I have loved most about the role. My manager Stratos also made it much easier to settle in. When I started, I was slightly overwhelmed by everything I had to learn. He is patient and very good at explaining not only what I needed to do, but why we were doing it. That made the work feel collaborative. It did not feel like I was just being handed tasks. I understood what we were working towards as a team. 

 

Q: Which part of your internship experience stood out to you the most? 

Aside from my work tasks, I joined the panel that recruited this year’s summer interns. I was involved in reading CVs, shortlisting candidates, conducting interviews, and making final decisions. As someone who had only recently been on the other side of the table, it was really interesting to see what employers actually notice. 

Obviously, your experience and practical skills matter. You need evidence that you can do the job. But being able to communicate and collaborate also makes a big difference. When interviewing you, employers are also imagining what it would be like to work with you. You want them to be able to picture you as part of the team.  

 

Q: Congratulations on graduating. Looking forward, do you think the internship impacted your future career plans? 

Before this role, I always thought I would probably follow a more typical route that people picture for Literature students, like journalism or teaching. However, my first ideal choice currently would be to continue working in web estate. I would also be interested in other governance or risk-management roles, now that I have experience working in maintenance of a large set of information and containing risks around websites and data. The internship has helped me see past the stereotypes of disciplines and fields, and showed me career paths into a sector that I didn’t even realise were possible. 

 

Q: What advice would you give to students and new student interns? 

For university students in general, try to expand your scope and get experience outside the classroom as much as possible. One of the experiences that unexpectedly helped me get this role was being Competition Secretary for the University Volleyball team. I was managing the administration of a national-level team, scheduling competitions, booking halls, and arranging transport. It had nothing to do with websites or coding, but it showed that I could organise things, communicate with different parties, and manage a large estate. You never really know which experience will lead you to something else, so keep exploring things while keeping your academic work on track.  

To myself two years ago, and also to all future interns, I would say do not be afraid to ask for more opportunities. I asked whether I could join the recruitment interviews. I asked whether I could be involved in procurement work with external suppliers. Even when you do not have a speaking role, ask for the chance to be in the room, even just to listen in. Sometimes you would have to put yourself forward, because not all opportunities are automatically included in your job description.  

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

In March, I started my internship as a Digital Developer within the Website and Communications team. My internship focuses on exploring Figma, the industry-leading digital design tool, and the user interface (UI) component library that the University has been developing within it.  

First impressions as an intern 

On my first day – somewhere between onboarding, learning a whole new set of acronyms, and unexpectedly getting free pizza – I began to get a sense of what the next few weeks might look like. I also met with colleagues I’d be working with closely on the project: Sonia Virdi (Human Centred Specialist in Web Strategy and Governance) and Mel Batcharj (Content Designer in UX and Digital Consultancy).

Looking back, that first week was a bit of a whirlwind. From getting to grips with the University’s structure, to navigating room bookings in the Edinburgh Futures Institute, to settling into the Forrest Hill office (and quickly becoming a fan of the huge monitors), it took some time to find my rhythm. 

Attending my first stand-up and adjusting to a new way of working was all part of that process. At the same time, I began exploration and research, which quickly became central to my day-to-day work. What stood out most was how quickly the experience shifted from unfamiliar to genuinely engaging, especially as I explored the problem space in more depth. 

The platforms and tools behind this project 

Several platforms and tools underpin this work, helping us design, document and maintain digital components while ensuring consistency between design and development. 

EdGEL (the University’s coded component pattern library)

EdGEL is the University’s coded component pattern library. For those unfamiliar, a pattern library contains all the digital assets that are required when building and creating digital products and services. EdGEL’s underlying design framework is Bootstrap, which provides the starting point when developing coded components.

Bootstrap

EdGEL is widely used across websites and web applications. It acts as a central source of truth for how interfaces should be branded, structured and implemented at the University. It was developed in 2015 when the first Drupal installation of the University’s central web platform, EdWeb, was launched. 

EdGEL website 

Documenting EdGEL components (Pattern Lab and Storybook)

The assets contained within EdGEL are currently documented within Pattern Lab, which is being replaced by the tool Storybook. Both tools provide a practical way for developers to explore the available EdGEL components and understand how and when they should be used.

Storybook implementation of EdGEL pattern library 

Figma Design 

Figma Design is an industry-standard tool used to create user interface designs (UI), prototypes and support teams through its collaborative features. It’s widely adopted by organisations (from startups to large enterprises ) because it brings design and development workflows closer together, reducing inefficiencies in how digital products are created and iterated on. 

More recently, Figma has introduced AI-powered features for prototyping and layout generation, making it an exciting tool in the current digital software landscape. 

What is Figma? (Figma article)

Building a University UI component library in Figma

In 2021, as part of the University of Edinburgh’s design system project, Figma was adopted to develop a library of digital UI components.  

Blog on the University’s design system project 

The goal was to make the University’s branded EdGEL components more accessible to a wider range of colleagues, align the two libraries and streamline digital development workflows. Additionally, the project’s aim was to simplify the process of making design changes and improvements to the EdGEL components, ensuring they are fit for purpose across a broad range of University environments. The work to create the Figma UI component resource would support a variety of roles involved in designing and developing digital platforms. 

 

 

Why Figma was chosen 

Figma was selected for several reasons: 

• Its functionality outweighed any other digital tool in respect to component development. 
• It helped bring design and development practices closer together, creating a more efficient workflow. 
• It enabled component and resource sharing across the University, reducing duplication of effort. 
• It supported more consistent use of the University’s branded components across digital products and services. 
• The strong user community provided a rich resource for learning best practices and obtaining support. 

My internship has two key aims

The two aims of my internship both focus on Figma, however, they approach the challenge from different angles. The first is about understanding how staff across the University currently design and deliver digital work, and where Figma fits within that landscape. The second is about improving the University’s existing Figma component library to better support its users. 

Understanding how Figma fits in at the University

The primary aim of my internship is to learn more about how Figma supports digital development processes across the University. This involves assessing Figma alongside the other tools teams use every day and understanding where it could add value.

We focused on understanding how people work

As a second-year computer science student, I was keen to move away from a purely engineering perspective and instead immerse myself in the user side – exploring not just Figma as a tool, but the people using it.  

Understanding how staff design, collaborate, and deliver digital work is central to this. Importantly, we’re not just interested in Figma itself, but in the wider workflows and tools that people rely on.

To guide this work, we focused on a few key questions: 

• What tools are people using day-to-day? 
• How do these tools support their work? 
• What works well and what does not? 
• How does or could Figma improve their workflow process? 

A survey helped us reach staff across the University

To help us understand how people work, we created a survey to reach a large proportion of internal staff across a range of roles. These included: 

• marketing and communications staff producing high volumes of digital content 
• visual designers working on platforms and services 
• developers building and maintaining applications and systems 
• user experience (UX) professionals carrying out human-centred research and design 
• academic staff designing and prototyping their own tools 
• others (such as project managers working with product teams) 

A key decision we made from the start of my work was not to focus solely on “designers.” Through discussions, we recognised that design isn’t confined to traditional visual design roles. People across the University make design decisions about layout, content, structure, and user experience, often using whatever tools are easiest to access within the University. 

Working with This Is Milk to enhance and improve the existing Figma UI library

Our work is being supported by the design agency This Is Milk, who are helping us make better use of Figma’s newer features while improving the University’s UI component library.

This is Milk 

This will involve: 

• making the library easier to access and integrates into users’ workflows
• improving synchronisation between the EdGEL codebase and the Figma UI library to reduce maintenance effort 
• developing training resources to help colleagues get started with Figma 

What I’ve learned so far

Developing my own understanding of design systems and Figma

Alongside our research, I’ve been developing my understanding of both design systems and Figma. 

The internship has given me the opportunity to build on concepts I was already familiar with, like components and variant properties, while exploring newer ideas, including design tokens and more scalable system structures.

Adopting a user-first mindset

So far, the experience has shown me that designing digital systems isn’t just about creating components or choosing the “best” tools. It’s about understanding people, workflows, and the small details that make something either frictionless or frustrating to use.

Importantly, the internship has pushed me to think more from a user-first perspective, grounding decisions in usability, accessibility, and real user needs rather than focusing only on the tehcnical or visual aspects of a solution.

Looking ahead

As my internship continues, I’m particularly looking forward to getting more hands-on with improving the design system and component library, as well as continuing to engage with staff to better understand how these tools can support their work. 

Myself, Sonia and Mel will continue to blog about the project as it progresses. Our next post will explore the survey research in more detail, including how we carried it out, who took part and our initial findings.

Hi! I’m Elisa, a Web Content Intern this summer at the Information Services Group (ISG). I realise this isn’t the most descriptive of job titles; my work mostly consists of rebuilding content that was migrated from our old website platform, EdWeb1, to the new platform, EdWeb2.  

Today marks the completion of my first month at ISG. To be honest, the first few days on the job were slightly intimidating. Updating websites that people actually visit on such a large domain can feel like a lot of pressure. Something as small as switching a simple toggle could have a big impact, and at the beginning, I was nervous I’d make some horrible mistake. I also don’t have a computer science background at all, unlike most of my team, so when they were showing each other the websites they had built and discussing their favourite programming language, I definitely felt like a fish out of water.  

Once we actually started working on the rebuilds, I realised there was no need to be nervous. EdWeb2 is a pretty intuitive platform to use, and my supervisors and line manager have patiently answered the thousands of questions I bombard them with every day. As I had used EdWeb2 at a previous internship at the University, it was more so a matter of jogging my memory and getting reaccustomed to how the system works. 

So, what does rebuilding sites actually consist of? To be truthful, it’s a lot of copying and pasting content from the old system into the new system, and building out what had previously been chunks of HTML into items like feature boxes, accordions, and body text. Everything you see when you visit a university website – all the buttons and links you click, every accordion you expand – has to be built out in EdWeb2. We also liaise with the sites’ lead publishers if we run into any issues. For example, some of the formatting that had been built out in EdWeb1 can’t be replicated in EdWeb2. In this case, we’ll suggest new ways of formatting page content, while still keeping in mind functionality and accessibility.  

I’ve also had the chance to do more in ISG alongside my role. My first week, I attended a training day for Drupal, a software used to build websites. This was quite outside my comfort zone, and the installation itself was really tricky (I do not do well with coding) but in the end, it ended up providing some useful insight into the website building process, and I felt pretty accomplished looking at my (very amateur-looking) website at the end of the session. I’ve also volunteered to help organise the blog you’re reading right now! We’ve been brainstorming ways to make it more engaging and accessible, as well as working on making sure all the interns are aware of the blog and know how they can contribute.  

I’m looking forward to the rest of my time at ISG and contributing to ensuring the university’s websites are running smoothly and efficiently.  

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.  

 

 

Hiya! I’m Grace, and I’m studying astrophysics and I’m going into my 3^rd year. I’m the web registry development intern and I started over the Summer of 2026. This Summer I’ll be working with LittleForrest, utilising the data it pulls about the University’s web estate, and using its APIs to present data to staff members at the University. I’ll also be training AI to test how accessible websites in the web estate are. Both these projects allow me to engage in topics that I’m really passionate about; digital accessibility and succinct data presentation. But more importantly, they both make me pick up lots of new skills!

First Impressions

My first day I didn’t really know what to expect, I knew I’d be working with data, but this would be the first time I’d be working with an institution as large and respected as The University of Edinburgh. I was armed with an EliteBook and a sparkly new lanyard, and was briefed on my projects.

Almost three weeks in and I’ve got into a good rhythm, though it was quite a learning curve. Fortunately, I’ve evolved from nodding sagely in meetings as I try to google what all the acronyms mean to now contributing confidently! Aside from the technical skills I will be picking up, I’m really keen to improve my public speaking skills, which is something my friendly line manager—Stratos—has really encouraged and given me opportunities to do!

Officially, my title is “Web Registry Development Intern” which, while correct, can be a bit vague when I introduce myself and doesn’t fully explain what I do day to day.

What I actually do

During the coming months my time will be split between two projects.

Web Registry Development

The University has a massive web estate, which I’m sure every student is vaguely aware of. I didn’t realise just how much fell under the University’s purview, and the diversity of websites. Lots of people are—rightfully—utilising what the University has to offer, but pulling their own website statistics from a massive array of data from an application like LittleForrest can be unintuitive. LittleForrest is a web governance tool i.e., it parses through all the websites the University is responsible for and deciphers who owns it, when it was created, and other properties.

My task is to create something that can wrangle the unruly web estate and present it cleanly, effectively, and succinctly to technical and non-technical audiences (emphasis on the non-technical). This will be presented in a dashboard that allows a login so users can see what is relevant to them, while also allowing filtering, so staff at the University can easily measure the performance of their websites. I am keen to give back to the University community while doing some concise data presentation and make the dashboard as seamless as possible.

AI Supported Accessibility Reporting

My second project doesn’t necessarily fall under the title of a “Web Registry Intern”, and is a project Stratos introduced after I waxed poetic about digital accessibility during my interview. The University has an AI platform called ELM, and I’ll be working closely with it to prompt it to test websites to see if they adhere to WCAG guidelines and aid in the reporting process. If all goes to plan, AI will be able to reliably evaluate how accessible a website is, and report its findings.

WCAG, Web Content Accessibility Guidelines, is a set of criteria that websites have to meet in order to meet accessibility requirements, and often a website is assessed (mostly manually) and the findings are compiled into a report. This can later be compiled into an accessibility statement.

Working with AI is a lot of iterating prompts, as each new response paves the way for a new error. Figuring out how to reword a thought process that is very instinctive for humans into something digestible for AI forces me to think creatively, and I’m really enjoying the freedom I’m given. I had a surface-level grasp of digital accessibility, as I had previously tried to implement WCAG guidelines in my own personal website, but talking with people who really know what they’re talking about made me realise how frequently websites aren’t accessible.

When I was receiving training there where many examples where obvious accessibility violations were completely overlooked by reputable websites, so I’m really glad I get to work on something really important and that clearly deserves more awareness.

My Takeaways

Everyone I’ve interacted with has given me ample opportunity to be curious. I’m being introduced to many new ways of thinking so being able to badger someone with questions without judgement has been really encouraging. I’ve got two really engaging projects that are going to keep my busy this summer and I’m excited to see what I can do by August. The University hires lots of interns each year, and it’s definitely an intern-friendly environment.

It’s clear this internship is not just about what you can do for the University, but what the University can do for you.

 

 

 

 

 

 

Hi! I’m Suhana Grewal, a first-year undergraduate student pursuing Economics with Finance at the University of Edinburgh. In December, I joined the ranks of the Website and Communications (WAC) team as a Community Engagement and Events Intern (yes, that’s quite a mouthful).

My role focuses on promoting engagement initiatives and events across the Portal Services, Web Development, University Website, and UX teams, particularly:

• supporting community engagement activities
• helping teams ideate, plan, and organise events that align with their goals and audiences
• developing structured frameworks to make event planning more accessible and sustainable

Having been here for seven weeks now, it feels like the right moment to pause, reflect, and share what I’ve been up to.

Weeks 1, 2 & 3: Context, Culture, and Cake

My first week was largely dedicated to training, induction into the Information Services Group, and getting to know the people behind WAC. While my role is undeniably a lucky one, with the rare opportunity to work with all teams across WAC, it did mean my first few days involved memorising an impressive number of names, faces, and acronyms in record time.

Although I’ve had prior experience managing events in high school, this was my first time doing so in a professional setting. And so, I turned to external resources, including ICC Belfast’s “Complete Guide to Planning Events” which became a nifty guidebook.

That said, the most valuable learning came from observing real events in action. The first of these was the ISG All Staff Event– which also happened to be my first day on the job. In hindsight, it was a generous (but mildly misleading) introduction to work life at ISG: I was blissfully fed cake and cream, attended talks on ISG’s work so far, and participated in fun trivia. While this isn’t a typical day at ISG, it was a lovely introduction to the culture.

I paid close attention to the details:

• how the agenda was structured
• how catering and room flow were managed
• how icebreakers were used to encourage participation.

It was my first glimpse into the thought and coordination behind successful community events.

During my second week, I familiarised myself with MyEd’s staff portal, including Booker and the Catering and Event Booking Admin tools– resources that would become integral for event management.

Weeks 4 & 5: From Familiarisations to Frameworks

The following weeks focused on meetings with Team Managers to understand event needs and aspirations through 30-45-minute conversations. I gained a clear picture of the types of events teams want to run and identified where interests overlapped.

Across these discussions, a recurring observation emerged: while teams were keen to host events, ideation and planning felt overwhelming.

To hopefully address this, I designed a standardised event-planning framework on Miro.

The first component is an Ideation Map that encourages teams to brainstorm events based on either:

• an audience they want to reach, or
• an issue they want to address

This approach was inspired by the backward “Event-Mapping Strategy” discussed during the UX team’s Content Improvement Club session in December. Rather than starting with an event format, the process works backwards: identifying a problem, defining a clear goal, and shaping a meaningful event.

I translated the Ideation Stage into a Miro flowchart following the sequence:

Signal to be Targeted → Problem to be Solved → Desired Outcome → Ideal Event Format → Event Concept

Each stage includes prompts and guiding questions to support decision-making. If a team is able to clearly answer these questions, they move on to the Planning Stage

For planning, I similarly divided the process into structured stages:

• success metrics
• event experience design
• defining logistics
• event agenda
• timeline creation

In what I can only describe as a fondness for micromanagement, I created Kanban boards and checklists for each stage, embedding all relevant event management links and tools in one central space for easy access.

Looking ahead, I’m excited to develop a similar framework for Feedback Collection, a stage I’ve come to see as essential for ensuring that today’s insights shape tomorrow’s events.

Weeks 6 & 7: Putting it into Practice

Since creating the frameworks, I’ve been implementing them alongside Team Managers. I’ve had the chance to begin streamlining event ideas and outreach processes for the Web Development team, as well as complete rigorous event ideation with the Portal Services Team.

Goals Going Forward

Looking ahead, I have a few clear goals (aside from the obvious improvement of my Miro skills).

One is to support the organisation of 5-6 concrete events from ideation all the way through to planning.

I’m also focused on developing my own soft skills. Networking is a big one. Working amongst such experienced staff, the opportunity to understand their work, take guidance, and build connections is incredible, and I hope to lean into that rather than shy away from it.

I’m eager to strengthen my organisational skills. Seeing colleagues’ reliance on calendars and time-blocking, I’ve been inspired to manage my time intentionally. This skill will benefit me far beyond this role, especially as a student.

Final Thoughts

These first two months have been a mix of learning curves, small wins, and growing confidence. I’ve learned that things often take longer than expected, especially when multiple teams are involved, but that collaboration is where meaningful work happens. I’ve felt genuinely supported, trusted to experiment, and encouraged to learn along the way.

Although I may be losing the glamorous view of the Edinburgh Castle I’ve gotten so used to, I’m sure the next few months have a lot in store, both in terms of the events we bring to life and skills I build along the way.

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

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

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

1. Using Storybook to Preview Single Directory Components

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

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

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

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

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

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

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

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

• Can we store multiple focal points for different contexts? 

• How do we improve the editorial experience around this? 

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

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

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

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

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

The human side

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

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

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

In this post, Digital Content Style Guide Intern Hannah Watson examines the research and existing guidance that have supported our work on the University’s style guide.

The UX team have recently been working to refresh the University’s editorial style guide. As part of my internship, I have been doing research to assist with this project. This has involved exploring other style guides and looking at the evidence they provide to support their choices. These resources have enhanced our understanding of digital content guidance, allowing us to provide more precise and nuanced information as we develop the editorial style guide at the University.

In this post, I’ll cover some of the most useful of these sources, why they have been helpful and how they can help you when working on your own content. This post may also be useful to anyone outside of the University who is looking to update a style guide.

Australian Government Style Manual

The Australian Government provide a comprehensive style guide designed for publishers on government sites within the country. Their guidance often aligns with the University of Edinburgh’s guidance and so has helped us to better understand some of the stylistic positions taken by the University. This has helped us to provide more thorough guidance with better examples for users to follow.

In particular, the Australian Government Style Manual has helped us with the formatting and punctuation sections of our style guide. Specific examples in these sections helped us to reflect on our style guide and consider what these aspects could look like.

The Australian Government Style Manual also has a heavy emphasis on ensuring accessibility of their web publications. We wanted to keep this in mind for our guidance as this is also a top priority for University publications.

Australian Government Style Manual

Content Design London’s Readability Guidelines

Content Design London are a content design consultancy company in the UK. Working with Lizzie Bruce and a large group of collaborators, they produced a detailed guide called the Readability Guidelines. This offers guidance, context, examples, and further reading on each topic covered within the guidelines.

Once again, this set of guidelines has been useful in editing and rewriting all of the style guide sections so far: formatting, punctuation, and using plain language. Especially helpful has been the extensive list of references that they include at the end of each page, meaning that if anything is unclear, or even just interesting, the option to do a deeper dive into that topic is always available. This has also been valuable when creating an evidence base for our style guide, as it means there is not a shortage of discourse on each section.

You can view Content Design London’s guidelines if you are interested in learning more about what influences decisions made withing web publishing guides.

Content Design London’s readability guidelines

Caroline Jarrett’s post on plain language and Plain English

Caroline Jarrett’s post, ‘Why plain language and Plain English are different’, has helped us to clarify terms used when having discussions about plain language use. The article explains how often these terms are used interchangeably despite having different, context-dependent meanings. This has helped us to be clear and precise in our descriptions and examples of plain language in the style guide.

Why plain language and Plain English are different

University of Reading’s Centre for Information Design Research

A team from the University of Reading were commissioned to assess the content principles used by GOV.UK. They used both quantitative and qualitative studies to illustrate why these principles exist and why they work. For example, they use a study by Nielsen Norman Group which concluded that users tend to scan in an ‘F-shaped pattern’. If content is structured so it can be scanned in this way, the accessibility and readability of the content is improved.

This is reflected in our guidance on formatting in our style guide, which emphasises clear and concise headings with accurate hierarchies, avoiding long blocks of text, and using well-formatted lists.

GOV.UK content principles: conventions and research background

NHS digital service manual

The NHS digital service manual explains why having a guide for digital content is necessary. This is specifically in reference to health literacy (the ability of the general public to understand content related to health). They explain that unclear, inconsistent content can have a knock-on effect when it comes to the decision making of digital content users. This is relevant to the University, albeit on a smaller scale, since inconsistencies could lead to a spread of misinformation throughout the University.

Content guide – NHS digital service manual

Conclusion

Overall, these resources have provided us with additional context, evidence, and examples to help us improve the efficiency and usability of the editorial style guide. If you are looking for additional information on a particular area of the guide, then they are likely an ideal place to start.

In October 2025, the User Experience Service ran a survey to learn about how University staff use the editorial style guide. In this post, Digital Content Style Guide Intern Hannah Watson summarises and analyses the responses.

About the survey

This survey focused on the usage and experience of those who have interacted with the style guide. We ran this survey to improve our understanding of how and why users interact with the style guide. We also wanted to explore any issues or opinions users might have on the guide.

Editorial style guide

In the survey, we asked five questions:

• Have you used the editorial style guide recently?
• The last time you looked at the guide, what did you use it for? (Choose any that apply.)
• Did you find what you were looking for?
• Which version of the editorial style guide did you use?
• Any other thoughts about the style guide?

The survey had 39 participants, most of whom answered all of the questions; however, some did leave answers blank.

Results

Each section had a varied response rate, with some questions answered by all participants and some with blank responses.

When did the participants last use the style guide?

The results of this question were as follows:

• Longer ago: 29
• Within a week: 6
• Today: 2
• At beginning of job: 1
• Can’t remember: 1

Of all the participants, 29 said they had not used the style guide recently, choosing the option longer ago. This makes up the vast majority of the responses, and 1 other response said that they used the style guide when they began working at the University (although it is not specified when this was). Only 2 participants said they had used the style guide the same day as taking the survey, and 6 had used the style guide within a week of taking the survey. The final response states that they cannot remember when they last used the style guide. This means that 20.5% of respondents used the style guide recently, compared with 79.5% who used the style guide a long or unknown time ago.

This suggests that while the style guide was well used among these participants, they do not return to it frequently.

What did participants use it for?

The results to this question were as follows:

• Dates and numbers: 21
• Formatting: 16
• Spelling style: 15
• Language and tone: 14
• Abbreviations: 10
• Punctuation: 7

For this question, responses mentioned multiple sections of the style guide more often than not. Dates and numbers was the section mentioned most frequently chosen, with 21 responses citing this. Language and tone, spelling style, and formatting had 14, 15, and 16 responses respectively. Abbreviations was mentioned 10 times, often alongside dates and numbers. Finally, punctuation was the last section mentioned, and it was present in 7 responses. Dates and numbers, formatting, abbreviations, and spelling style were the sections mentioned on their own, all more than once except for abbreviations.

This might suggest that these sections are the ones where people are looking for guidance on specific details, or do not have any additional guidance beyond the style guide.

Did participants find what they were looking for?

The results to this question were:

• Found what they were looking for: 33
• Did not find what they were looking for: 2
• To an extent: 1
• Can’t remember: 1

Almost all of the responses (33 out of 37) said that they found what they were looking for. Only 2 participants directly said that they did not find what they were looking for, with a further 1 stating they couldn’t remember, and another 1 saying that they found what they were looking for ‘to an extent’.

Which version did participants use?

These results were:

• Web version: 27
• PDF: 8
• Unsure: 3

Of 38 responses to this question, 27 said that they used the web version, compared to 8 that said they used the PDF. The remaining 3 responses were unsure which version they had used.

Other thoughts about the style guide

The responses to the free text responses to this question can be summarised thematically as follows.

The PDF requires updating with most recent information

Four participants mentioned this theme.

The most frequent response to this section of the survey was that people are aware that the PDF version of the style guide is not up to date with the web version, and are frustrated by this, since they prefer to use the PDF version. This also links to the the theme of people requesting the web version to have a search function, since this is why many people prefer the PDF.

Not enough people use the style guide

Three participants mentioned this theme.

The second most common response to this prompt was participants stating that they do not believe enough people use the style guide. Some people appear to feel quite strongly that the editorial style guide is a very useful tool that would benefit their team if more people engaged with it, either properly or at all. This is not necessarily within our team’s control but is interesting to note how highly the guide is valued by some users.

The style guide has too many sections

Two participants commented that the web version of the style guide has too many sections. One response said that this makes information hard to find, and the other said that the number of pages seems unnecessary to them.

Issues with guidance on stylisation

Two responses mentioned more general issues with guidance on style, such as with formality based on who the piece of content is for.

The web version needs a search function

Two responses included requests for the web version of the style guide to have a search function to make it easier to navigate. This lines up with people favouring the PDF and wanting it to be updated more frequently.

The style guide needs more detail

The free text responses also included suggestions as to how more detail could be added, such as:

It would be good to have instructions on image sizes and formats in the style guide as well.

 

The one that I always have to check is masters, master’s, etc. I’m still unsure if I’m always using it correctly – and there is a lot of variation in how it’s used by others across the University. It would be great to have more examples…

What’s happening next

Thanks to everyone who filled out the survey. We are taking these comments and answers into account and using them to help us to implement changes to the style guide.