Co-creating future profiles – ideas and insights from collaborative workshops
Research from the Role of Profiles project revealed what staff require from online profiles. In a series of two ideation workshops, the UX team worked with staff across the University to consider possibilities for a new profiles provision.
As part of a project on profiles, a programme of research activities including system analysis, a survey and staff interviews identified various shortcomings with the existing EdWeb profile provision and potential opportunities for improvement. To act on this information, and to ideate on possible solutions, staff with an interest in profiles from a range of roles and from various parts of the University were engaged in workshops to help tease out recommendations for a future profile provision.
Access project details on the projects website:
Staff workshops were structured around the profile lifecycle
Two workshops, facilitated by the UX Service between May and June 2025, brought together technical and non-technical staff responsible for managing and coordinating profiles in their individual Schools and business units to pool ideas and approaches to profiles. Using decision points from key stages of the end-to-end profile management process (or lifecycle) as prompts, each workshop included sharing from colleagues as well as discussions around the appropriateness of proposed solutions, weighing up pros, cons and associated resource requirements.
Both workshops represented the potential start of a longer-term collaboration between central and local IT teams and included colleagues managing content in EdWeb and non-EdWeb sites.
Read more about the stages of the profile lifecycle in the blog post:
Different approaches for profile creation were assessed
It was logical to make careful consideration of the ways profiles were created, to set out the different points and tease out associated consequences for choices made at this early stage of the profile lifecycle.
Should the profile structure be fixed or flexible?
In both workshops, participants spent time considering which fields should be included in profiles. In some Schools, a strictly defined profile structure had been adopted, with each profile comprised of pre-labelled set fields.
Pros, cons and resource needs for profiles with fixed, pre-labelled fields vs flexible profiles
One benefit of all profiles comprising the same complement of sections was that all profiles had a uniform, predictable structure. This consistency helped those wishing to consume and search content across multiple profiles, and also facilitated automatic or machine-led extraction of content from other sources (such as HR records or staff databases) to promote data accuracy on fields like name and job titles. The downside of this approach was that it required reaching a consensus on a single set of fields to meet the needs of all those requiring a profile, further resource to enforce the rules for using the structured fields and also prompted a need to continually assess individual staff requests for more flexibility.
Allowing profile owners freedom to label sections of their profiles avoided staff having to try to fit content about their work and achievements in into a ‘one size fits all’ profile. This presented a more attractive proposition for staff to publish content, and lessened the resource-heavy requirement to agree upon, and enforce a rigidly defined profile structure. Instead, resource needed to be directed towards providing guidance and good practice advice about writing profile content to appeal to the specific audiences staff wished to reach.
Should profiles be opt-in or opt-out by default?
When new staff joined, some Schools set up a profile for them by default. In other cases, staff were encouraged to request a profile by themselves. Each profile creation method had pros and cons and had implications for later stages of the profile lifecycle.
Pros, cons and resource needs for staff receiving profiles by default vs opting in
Generating profiles for all new members of staff required people to put mechanisms in place for the creation of profiles either manually or automatically and to ensure this worked in synchronisation with HR information held locally or centrally so that the set of staff profiles matched the list of staff working at a particular School or business unit.
Providing profiles for all staff meant no one was excluded from having one, however, it meant that staff who felt they did not need a profile or did not want one due to privacy concerns had no choice, suggesting it was better for staff to ‘opt-in’ rather than ‘opt-out’. In support of this, in both workshops, staff noted that when profiles were set up by default, colleagues often did not realise the profiles existed, and therefore didn’t update them which had led to profiles being sparsely populated, out-of-date and seemingly surplus-to-requirements, creating a burden to maintain.
Should profiles be external or internal-facing?
Some Schools had taken decisions to publish some profile content internally, for example, content for professional services teams on SharePoint, so these details could only be accessed by people from within the institution.
Pros, cons and resource needs for internal vs external profiles
The main drawback of publishing profiles internally was that this content was not available to wider audiences of the University and meant the work of staff concerned was not showcased outside the institution. That said, this approach meant there was less profile content to manage on the main web estate, and therefore, that the risk of sparse or out-of-date profile content being publicised was minimised. It also avoided individual staff members receiving spam emails or direct contact when it was preferable for enquiries to go to a generic email address or via a central contact route, and it also respected the concerns some staff had about their contact details or working locations being publicly available.
Should profiles be published on a School/institute site or main University website?
Different Schools and business units had chosen to publish profile content in different locations on the web estate. Some non-EdWeb sites and individual research institutes had published content in their standalone sites, for example in sections such as ‘People’ or ‘Our Staff’. Others had opted to publish profiles in the central EdWeb profile provision.
Pros, cons and resource needs for profiles on School site/institute sites vs main University site
Having profiles published as part of individual sites provided important context by association, for example, it was possible to know of a staff member’s standing in the organisation by the profile URL belonging to the specific site (for example Professor Timothy Drysdale at the School of Engineering). Having this content located at the level of individual sites also promoted tighter control over profiles in accordance with the School or institute-level processes used to manage and look after web content.
One difficulty associated with having profiles published on specific standalone sites was the risk of duplicate profile content for staff associated with more than one School or institute. For example, colleagues from the College of Science Humanities and Social Sciences may be part of the Edinburgh Futures Institute as well as the Edinburgh College of Art as well as several research groups, meaning they may require a profile on multiple websites.
In theory, a single University-level profile may avoid this situation, however, in practice, nuances in School or institute-level profiles that would appeal to specific target audiences would likely to be lost at the generic University level leading to profiles that tried to serve the needs of all audiences but in fact would run the risk of not serving any audience needs particularly well.
Means of keeping profile content up-to-date were appraised
Following on from considerations of how profiles were created, participants in both sessions discussed decision points at the next stage of the lifecycle, the maintenance stage. Various courses of action that ensured profiles remained relevant and up-to-date were shared and associated pros, cons and resource needs were assessed by workshop attendees.
Should staff do their own profile updates or should these be done for them?
Interviews with staff had revealed that in some cases, staff owning profiles had them updated for them by colleagues with edit access. In the workshops, the advantages, disadvantages and practicalities of staff doing their own profile updates were debated.
Pros, cons and resource needs for staff doing their own profile updates
Given the irregularity with which staff may be prompted to update their profiles (depending on their individual career progressions), it was advantageous to empower staff to be able to access and edit their own profiles to make updates as and when they wanted to. That said, staff had commented (both in the survey and in the interviews) that, although training and guidance was available, they struggled to remember how to use the system to make these updates, which often blocked them from doing so. This problem had been addressed in some Schools by staff being able to request that updates were made for them by colleagues with web editing experience. This approach led to more consistent profile content being published, and alleviated the need to train large numbers of staff to use a system they would only use intermittently. It did, however, mean that some individual staff members forfeited direct edit access to EdWeb and therefore were unable to edit their own profiles directly.
Providing staff guidance and integrating profile updates into annual review processes
In a bid to help staff keep their profiles updated, several Schools had produced internal guidance on profiles in SharePoints or similar internal locations, which they referred staff to as part of their School induction procedures. In some cases, Schools also offered training for staff on writing effective profiles.
How could content from other sources be presented on web profiles?
The content in staff profiles changed over the course of individual staff careers and for most staff, content that tracked their work and achievements was available both in internal sources, such as staff databases, as well as being published in external repositories like PURE, ORCID, and many others. Recognising that it was desirable for this data to be dynamically presented within University web profiles as a means of keeping them updated, Schools had used various mechanisms to achieve this.
Integrations between systems required defined profile structures and continual monitoring
Several Schools had taken steps to implement technical integrations with PURE, one of the main publication repositories used by academic staff for profile content. These integrations had required technical expertise to set up, as well as monitoring to ensure they continued to work and could be relied upon to present updated content. The success of these integrations also had dependencies both on the source system side (for example, where and how the content was published in PURE) and on the profiles side (in terms of profiles requiring a defined structure to accommodate the source data), therefore there was also a requirement to provide guidance and assistance to staff to use profiles and the source systems (such as PURE) in the right way to enable integrations to function properly.
Some staff added direct links to external repositories on their profiles
At a more basic level, some staff had added links to external sources of content in the ‘business units’ section of their profiles. In these cases, individual staff owning profiles were in control of the sources they wanted to include, and could change these at will depending on the achievements they wanted to highlight. For example: Kyle Morrison, Design Technician had included LinkedIn, ORCID and PURE in their profile: Kyle Morrison’s profile on the University of Edinburgh website.
Middleware for data exchange between systems– an idea for further investigation
Recognising the need for any data-sharing mechanism to be flexible and adaptable to varying source systems and platforms, an idea for a middleware application was suggested in the second workshop. This would enable EdWeb 2 to ingest data from the source system via a JSON feed/API following a defined schema and dynamically present it in EdWeb 2. Further expansion of this solution would require work on specific areas: defining the schema for an output feed from the source, development of client-side interfaces, investigation of the potential to use of Drupal Paragraphs to set rules for specific profile sections. This could be achieved through further collaborative working sessions with interested staff.
Should profiles be tagged to enable profiles to be grouped?
Sharing experiences from their individual Schools and business units, many workshop participants had a need to create lists of profiles, and to collect profiles together based on specific themes. For example, various Schools needed to list all the current academic staff, others needed to group staff profiles by research discipline or subject area. This had commonly been enabled by use of taxonomies to set up categories, and then applying tags to individual profiles to ensure they appeared in the defined categories.
Pros, cons and resource needs for tagging and taxonomies
Reflecting on their processes, Schools spoke of the effort required to define taxonomies and sets of tags. Some Schools worked with a defined set of tags for research interests – which enabled the categorisation and searching of profiles in ways other than name (for example, to find all the staff working in a specific research area. Achieving this set of tags had required significant behind-the-scenes work, however. First of all, there had been the need to gain agreement on tags from senior academic members of School staff (such as Heads of Research). Once a list of tags had been confirmed, there was an additional need to reach consensus on a syntax for the tags to avoid mis-spelling and alternative variations. With the set tags in place, there was a need to continually monitor the correct and consistent use of them by all staff in the School. Looking ahead, there was also a need for oversight and governance of the tags, to periodically review and update them in line with relevant requirements, for example the Research Excellence Framework units of assessment.
Approaches to deleting and archiving profile content were considered
A significant aspect of keeping profile content up-to-date was the need to remove profiles that were surplus to requirements. Data retention schedules specified periods of time that staff records needed to be kept for, however, there was no explicit requirement to keep website staff profiles, content in these was subject to usual web content management and archiving good practices. In both workshops, staff shared the ways they ensured profiles published accurately reflected the staff working for the School or business unit, making sure profiles were removed when staff left. Each approach came with different resource requirements.
Automated synchronisation of profiles with staff databases took effort
Some Schools used HR records, staff databases or lists as the definitive source of all those working there, and used these data sources to check that only profiles for staff currently employed by the School were published on their websites. In some cases, Schools had set up automated alerts to flag the need to delete profiles when staff left and no longer appeared in staff lists.
Achieving this workflow required technical staff to integrate staff databases with the source of profiles, sometimes using a middleware layer. In addition, there was a requirement to work with local HR teams to ensure profile structures matched the format of data in the staff lists or database, to set up rules for the system integrations, to monitor the way data was handled between the systems, and to ensure information was parsed in the correct way. Furthermore there was a need to handle exceptions where profiles were requested for absent staff, such as in the case of emeritus professors, and a further need to override system defaults to delete content when staff thought to be leaving actually remained part of the University, for example, when contracts were renewed. Some Schools were piloting use of an API from People and Money instead of localised staff databases, however, this was limited in scope and not widely available.
Without technical solutions, profile collections were updated manually
If technical solutions were not an option, Schools kept on track of staff profile collections manually, physically removing profiles when staff had left. This was a time-consuming process, especially if every staff member had a profile, and if there was high turn-over of staff.
Profile owners tended not to delete profiles when they left
Some Schools relied on staff deleting their own profiles as part of their exit processes, however, more often than not, they had found staff omitted to delete profiles themselves. In these cases, the profiles needed to be removed by other staff – which in turn required changes in editing permissions on an ad hoc basis.
Conclusions – shaping recommendations
Taking the outputs of both workshops together, and considering different approaches to the shared challenges of profile management helped formulate recommendations for a profile provision that was more attractive for staff to publish their content and that facilitated better quality of profile content.
Profiles should contain minimal pre-labelled fields to suit more staff
Pre-labelled fields helped ensure profiles contained certain key details about staff members, such as their name, and job title and contact details. Having these fields fixed also facilitated extraction of these data from defined sources such as HR records or staff databases. That said, it was important that other fields were more flexible to suit a myriad of staff needs, to move away from the need for staff to have to try and shoehorn content into sections that did not match the content they wanted to publish about themselves and their work.
Public-facing profiles should be opt-in rather than opt-out
Before automatically creating profiles for staff, staff should be consulted to check that they require one, and that it needs to be publicly available (rather than available internally).
Where possible, profiles should be located in ‘People’ sections of sites
Having profiles published in a standalone profiles section (as in the current EdWeb arrangement) meant that staff often forgot where their profiles were located and how to update them. Furthermore, having thousands of staff profiles published together and separated from individual sites meant it was difficult to convey context about how staff were associated with the University and to include School or institute-level nuances, and also to implement controls over profile content in alignment with local-level staff lists and databases, to ensure profiles were kept up-to-date. Having profiles as part of individual sites (in sections such as ‘Our People’ or similar) could facilitate greater control over profiles and enable staff to more accurately describe their associations with the University.
Middleware to present data from other sources should be investigated
Recognising that staff profile content existed in a number of different repositories – including University systems (such as HR records, staff databases, etc) as well as external platforms (such as PURE, ORCID, etc) it would be beneficial to continue investigating the idea of a middleware solution that could enable the presentation of data from these sources in EdWeb 2 without the need for individual system-specific integrations. Achieving, and making use of such a solution could potentially reduce the amount of data needing to be stored in EdWeb 2, and could also alleviate the need for staff to have to remember how to use EdWeb 2 to publish profile content, which was difficult when they only needed to do so intermittently.
Profiles should include functionality to group into lists and to use tags
Thinking beyond content within individual profiles, there was a need to be able to pull together multiple profiles, to present them in groups or categories – for example all profiles for staff working in a particular research group. Although they required consensus and governance at the School or institute level, followed by monitoring to ensure they were consistently used and applied, tags and taxonomies helped achieve grouping and for this reason would be a useful piece of functionality to make available to EdWeb 2 sites.
Guidance and training on updating profiles should be available to all staff
Regardless of how, where or when they published profile information, there was a need to help staff design profile content to achieve the most impact for their work and achievements and to reach their target audiences. Guidance and training on writing and updating profiles was already available to some staff through their School or business unit. It would be beneficial to build on this good practice to make this type of support more widely available to all staff.
The UX Service had already piloted a session for web publishers, detailed in this blog post:
How to write a staff profile page that meets the needs of prospective graduate research students
These and other findings from the Role of Profiles project are being presented as part of the closure of the project, scheduled for 31 July 2025.
Read more about the project in related blog posts:
Collected blog posts about the Role of Profiles project
