32 hours with our editors: what we learned

User requirements are where the ‘what’, ‘why’ and ‘how’ begin to shape our approach. Designed by vectorjuice / Freepik.

As we continue shaping the University Content Management (UCM) programme, one of the most valuable parts of our early requirements gathering work has been listening to colleagues who create and maintain content across the University website.

Our Business Analyst, Emma Tsiatinis, led a series of workshops, interviews and feedback sessions. Formed of 23 sessions – totalling 32 hours – our website editors shared what currently works, what gets in their way, and what they hope a modern content management system (CMS) could help them achieve.

This information now forms the backbone of our requirements, procurement criteria and design approach.

Requirements gathering: a clearer picture

Across all sessions, several consistent themes emerged.

Whether colleagues joined a 90-minute high‑level review, one of the 13 deep‑dive sessions, or any of the six validation and prioritisation workshops – the needs and frustrations were remarkably aligned.

Editors told us they want an ecosystem that is easier, faster and more intuitive – especially for those who update content infrequently. Key current challenges included:

  • Too many steps to complete simple tasks
  • A steep learning curve, creating reliance on colleagues for basic actions
  • Rigid templates that prevent content from adapting to different audience needs

This input reinforced that usability isn’t a “nice to have” – it is foundational to high‑quality digital content.

Where complexity creeps in

Our deep‑dive sessions (which spanned topics including the editor experience, asset management, search and navigation, integrations and more) gave us a detailed view of the practical barriers teams face.

Common pain points included:

  • Image and asset handling that often requires manual resizing, reformatting and re‑uploading
  • Difficulty finding assets or confirming usage rights
  • Slow or unclear workflows, often dependent on individuals
  • Managing outdated content

With over 300 detailed requirements logged during the deep-dive, these insights reflect real, repeated obstacles – not isolated cases.

Importantly, they directly affect the experience of everyone who uses le.ac.uk.

What our editors want from the future

Despite the challenges, colleagues were clear and positive about what would help them work more confidently. Across the sessions – from governance, to reporting and insights, to AI and automation – we heard strong consensus on the priorities:

  • A modern, intuitive interface for quicker, simpler updates
  • Flexible content components, allowing pages to be more engaging and effective
  • Better collaboration tools, enabling multiple contributors to work together
  • Built‑in quality features such as accessibility checks, expiry notifications and integrated analytics
  • Integration with customer relationship management (CRM) and staff profile data

The validation phase was a significant piece of work in its own right.

Across multiple structured sessions, colleagues not only reviewed but refined and challenged the emerging requirements, working through detailed scenarios and prioritisation exercises.

This high level of engagement meant we were able to validate hundreds of requirements thoroughly and collaboratively – resulting in a robust, confidently prioritised set of requirements without the need for extended follow‑up activity.

Strengthening our requirements

Alongside the extensive functional insight shaped through workshops and editor engagement, our Solution Architect, Howard Taylor, led on deepening the requirements work by defining the non‑functional expectations that will ensure the CMS operates reliably, securely and in line with University technology standards.

While functional requirements capture what editors need the system to do, these non‑functional requirements (NFRs) outline how the ecosystem must perform and behave ‘under the bonnet’ to support a stable, high‑quality digital environment.

This work helped to establish a thorough set of NFRs covering areas including security, performance, availability, compliance and alignment with wider technical standards. Developing this involved adapting and refining material from earlier projects – a significant effort that has since resulted in a mature, reusable NFR library.

That library is now an asset used across multiple technology initiatives, reducing development time and helping maintain consistency in how systems across the University are evaluated.

Moving from insight into procurement

Our procurement work has been as rigorous as our requirements gathering. We followed a procurement exercise utilising the new competitive flexible procedure, under the Procurement Act 2023.

Using the validated set of detailed requirements, we carried out a structured procurement preparation phase – led by our Procurement Category Lead, Sumaya Makda – including clarification sessions, weighting exercises and pre‑qualification activity.

This ensured suppliers would be assessed consistently against what our editors and stakeholders told us matters most – usability, flexibility, integration capability and long‑term value.

By investing early effort in defining clear, evidence‑based criteria, we’re now positioned to select a CMS solution that meets the University’s needs and support the sustainable, scalable management of content.

A better experience for every user

Mapping editor experiences isn’t just about improving a technology and its processes – It’s about strengthening the University’s digital ecosystem. When editors have the right support, they can create content that is clearer, accurate and more engaging for every audience.

The time our colleagues have invested – from the early overview work through to detailed requirement clarification – ensures our procurement and design decisions are grounded in real needs. And it ensures the future will be built not only for the University, but in collaboration with the people who use it.

And yes – before you (rightly) ask – we’re not ignoring our end users. Their needs are central. Future posts will share how we’re designing for the people who rely on our digital services.