1 of 30

The discomfort and messiness in big projects (and how to get past it)

Lauren Tormey (she/her)

Senior Content Designer

University of Edinburgh

9/26/2023

2 of 30

About me

Lead a team of 3 content designers
Part of Prospective Student Web Content team
Feel free to connect:

LinkedIn: lauren-tormey
Twitter: @ltormey

3 of 30

Why I'm giving this talk

Started working on my first BIG project last year
BIG = multi-year, multi-disciplinary, high impact
I knew it would be challenging...
...but I didn't expect it to be so uncomfortable and messy
I want to unpack the discomfort and messiness and reflect on it
The work we do is hard, and I believe sharing can help make us all better

Back to the discomfort and messiness. What do I actually mean by this and why am I talking about this today? Last year I started working on my first big project. By big, I mean the type of thing I had waited my whole career to work on. A multi-year, multi-disciplinary, high impact project that was going to make a huge difference to the University.

I'll share more about the specifics of the project in a bit, but to give an intro as to how this talk topic came about, I knew this project would be challenging. It's BIG project. I expected BIG challenges. More than that, I was so ready for the challenge. This was the thing that was going to upskill me immensely and I would learn so much from.

But I wasn't prepared for how uncomfortable it felt at times, especially in the beginning. And how messy things got along the way, it felt so hard to keep up with everything.

I'm here today because I want to unpack that discomfort and messiness, and I want to reflect on it. I think it's important to do so for both myself and my team, so I can learn where I went wrong and my whole team can think about where we can improve.

I also think it's really important to share stories like this because the work we do is hard, and I don't think enough people talk about how hard it is. By we, I mean all of us in this room, working in content and working in this sector. We don't do ourselves any favors by painting a glossy façade over our challenges. We need to talk more about how difficult our work can be. I believe by sharing stories like the one I'm about to tell you, it can give us all a chance to reflect and make things better in our workplaces.

4 of 30

Project background

3-year project to design the future state of our online degree finders
Current degree finders end of life and not fit for purpose
Working with a consultancy to increase our development and delivery management resource
First year focused on our undergraduate degree finder

Product owner

UX specialist

Content designers

Developers

Delivery manager

Strategist

University of Edinburgh

Consultancy

Project team

To give you some background, my team is a now in year 2 of a 3 year project to design the future state of our online degree finders. It's our online prospectus listing all the details about programmes you can study.

Our degree finders are at end of life, and they are also not fit for purpose for both prospective students and editors. The current content and design presents a lot of usability issues for students trying to find information about a programme. The CMS doesn't have even functionality to upload pictures, which has often been a bug-bear for our editors. In short, it's been a long time coming to design a new product that improves the experience for both the content creators and consumers.

For this project, we've been working with a consultancy to fill some resource gaps in our team. To give you an idea of the full team, I've created these dots to show you the different roles and the breakdown between University people and consultancy people. University people are represented by purple dots, consultancy people in green dots.

So from my team, we had my boss as Product Owner, our UX Specialist whose role combines both user research and user interface design, me and my team of three content designers, and our developer. Our developer was joined by 3 developers from the consultancy, and from the consultancy we also got a delivery manager and a strategist.

The first year of the project focused on redeveloping our undergraduate degree finder. The stories I'm telling today all have to do with year 1 of the project.

5 of 30

The undergraduate degree finder editorial experience

School editor liaises with academics to update content in GatherContent.

Our team edits content and shifts to degree finder CMS.

Published degree finder.

Edinburgh has a highly devolved approach to web publishing, so I think it's important to give you some context into how our undergraduate degree finder is published.

In a nutshell, my team manage the degree finder, but we do not create the content for it. Every school (or faculty as it might be called at your university) has an editor assigned to it. This is usually a comms or marketing staff member based in the school who is responsible for liaising with the relevant academics to create the content each year for all the programmes in their school.

School editors make the updates to their programme content in GatherContent, which is a content operations platform. We edit the content to ensure it adheres to digital content best practice and the University style guide. We then shift that content over to our undergraduate degree finder CMS. And if a school editor needs to make an edit to that content during the year, they email us a support request, and we make it. They do not have access to the undergraduate degree finder CMS.

The only other people who do have access to the CMS are colleagues in central admissions. They are responsible for updating all entry requirements content. Admissions have a sort of similar process to us in terms of updating entry requirements in that they liaise with admissions colleagues around the University to get the updated entry requirements info they need to populate the degree finder.

I'm going to speak about working with admission in the talk, but the main point I want to get across here is that designing the backend editorial experience was as big a job as designing the frontend content experience.

6 of 30

What I'll be talking about

The rocky start in project leadership
Collaboration difficulties getting colleagues aligned
The feeling of a project within a project (designing entry requirements)

7 of 30

The rocky start in project leadership

8 of 30

The kick-off that didn't really kick us off

UoE and consultancy project staff met in person October 2022 for kick-off

got consultancy up to speed with work done so far
align on project goals
discussed roles in project

Set up lists of tasks for 'sprint 0'...but with no deadline of when they should be completed

Lauren

Content lead

(limited capacity)

The collaboration between my team at Edinburgh and the consultancy formally started in October 2022. Some of the consultancy staff came to our office for a series of kick-off meetings over three days.

The kick-off was a chance to get the whole project team together and to get the consultancy up to speed with work our team had been doing already in the project, align on project goals, and discuss roles in the project. Those kinds of things.

When discussing roles, the delivery manager from the consultancy was writing down everyone's names on post-its and their roles in the project. So when it got to me, my post-it said Lauren, content lead, and I made sure they added in brackets 'limited capacity' to the post-it.

Because at the time, the other senior content designer who heads up our content operations function left the team a month prior and their replacement didn't start until January. So for the last quarter of 2022 I was looking after two teams and basically doing two jobs.

I wanted to make clear on that post-it that yes I was the content lead, but until the new year, this project wouldn't be getting 100% of my time.

Another thing we did at the kick-off was set a list of tasks to be done in what was called sprint 0. Our project followed Agile Scrum methodology, which if you're not familiar with Scrum, meant we were going to work in time-boxed periods to accomplish a set number of tasks. Those time-boxed periods are called sprints, so sprint 0 meant all the tasks we needed to do before we were ready to start officially sprinting. However, there were no deadlines set for those tasks.

So the project had kicked off, but we didn't do a great job of kicking off. When we started with sprint 0, things got chaotic.

9 of 30

The chaos that was sprint 0

Got through tasks but no one took responsibility for managing progress on them
15-minute stand-ups always took a half hour
No deadlines led to no reviews or retros
Unclear when sprint 1 would begin
I had a workload I struggled to keep up with
I hit breaking point...

What made sprint 0 chaotic?

First, we were getting through the list of sprint 0 tasks we devised, but no one was taking responsibility for managing progress on them. One of the issues that contributed to that was between kick-off and sprint 0, the person from the consultancy who we were told was going to be our delivery manager, ended up not being our delivery manager. Instead someone else was put onto the project who didn't have all that context from the kick-off, and as a result, I think they struggled to get to grips with the big project they were tasked with.

Second, part of Scrum projects involves a daily short meeting called a stand-up where everyone says what they did yesterday, what they're doing today, and any blockers to their work. These meetings were scheduled for 15 minutes and they always ended up taking a half hour. People would use their speaking bit to ask others questions, invite feedback on something, or do a show and tell of what they had been working on. It sometimes led to long tangents about very technical things that went over my head.

Third, as I said on the last slide, there was no end date, which meant no review sessions, which is a space to share what you've been working on. And no retros, which is a space for everyone to share what's gone well or not well in the project – the very thing we needed as the discomfort and messiness was mounting in this project.

It was very unclear when sprint 1 would begin. No one was putting an end date to sprint 0 or giving us direction.

I wasn't taking leadership to give us direction, and that's mainly because I didn't feel that was my role in this project, and I did not have the capacity to make those decisions. I was really struggling to keep up with the workload in front of me managing two teams but clearly being needed more in the project than I said I had the capacity for.

It wasn't just me who felt the discomfort. Most people felt it. We all knew something had to be said, and I finally hit my breaking point in a meeting with my boss and the rest of the Edinburgh project team present.

10 of 30

"There's no leadership going on."

-me to my boss

In this meeting, I told my boss what I had been thinking since sprint 0 began: there's no leadership going on.

Let me just add for context, I have a very open relationship with my boss. He's been my boss for most of my career. I'm a very frank person in general, and I'm frank with him. I will tell him anything, good or bad.

That said, I was so incredibly nervous to say to my boss that there's no leadership going on, because it wasn't only a comment on the delivery manager, it was a comment on him. As product owner and the most senior University of Edinburgh member on the project, I expected him to take the lead and say we need to start setting deadlines so we can kick this thing off. But he didn't. No one did. Including me. And it resulted in me waiting until I hit breaking point and said this in a meeting in front of everyone.

I will never forget the look on my boss's face when I said this. It looked something like this [click to show emoji]. He definitely looked quite taken aback. But because of our relationship, he is well used to my bluntness. And my boss is really good at taking feedback like that seriously and making changes to fix things.

So yes, it was a very uncomfortable things to say, but it was one of those meetings that had to happen to make things better.

11 of 30

What changed after I said that quote

We had a retro as a team, and then shared with the consultancy for them to add their own contributions
We started working in sprints
We got a new delivery manager
It wasn't perfect but it was better – better structure, but improving ways of working not prioritized enough

"Working in a sprint finally - we’re working toward goals and deadlines!"

Sprint 1 retro what went well point.

During that meeting, I said we needed to have a retro just for the Edinburgh team because I felt we needed the space to freely express how we were feeling. So we did have that retro, but in the spirit of being open and transparent, my boss shared with the consultancy we had this retro and he distilled the points we raised at it and shared it with them. The consultancy added their own points to the retro, and then all of us met to go over the points together.

That meeting then set off some much needed changes in the project.

We started working in sprints, yay! This gave us more structure, and we all benefited from feeling like we were working towards something unlike how aimless sprint 0 felt. I've included one of my quotes from our sprint 1 retro which highlighted how happy I was to be working in sprints finally. I wrote, "We're working towards goals and deadlines!" I was so excited about it!

We got a new delivery manager. The performance from the person the consultancy put in after the kick-off didn't meet our expectations, so we got someone who was more familiar with bigger, complex projects.

Throughout the rest of the project, I wouldn't say it was perfect, but things were much better and never got as bad again as it did in sprint 0. What primarily made it better was having that structure to work in. We never got to the point again where we felt like we were working aimlessly. But I think the biggest thing that I felt like was missing was improving ways of working not being prioritized enough.

When I run retros for projects I manage, it's important for me to create an action list afterwards to implement our lessons learned. Not being in that lead role in this project, I felt the way we handled retros wasn't as proactive in enacting those lessons learned and therefore didn't meet my expectation on how to run them.

But overall, things were in a much better state from sprint 1 onwards.

12 of 30

Lessons learned

An open team culture where people can speak up if something isn't going right is paramount
If you're not getting the service you want, ask for a change
Stand-ups should focus on the tasks, not the individuals
Set up not only roles and responsibilities but expectations
You set the leadership you want

"We should be confident to set out how we want to work in future rather than expecting the agency to be experts who guide us."

-my boss to me

What were my lessons learned in project leadership from this?

1- An open team culture where people can speak up if something isn't going right if paramount. I'm not saying if you were in a similar situation, tell your boss what I said to mine. But I think if something isn't going right, this has to be communicated in whatever way you feel comfortable doing so. But feeling comfortable in a setting like that is such a privilege, so before you can say anything, you need that open culture to be present.

2- If you're not getting the service you want, ask for a change. I commend my boss for sensitively approaching the consultancy about ensuring we had what we needed from a delivery manager to support the project. It would have had a massive impact on the project if he didn't say something, so by doing so, it got our project to a better place.

3- Stand-ups should focus on the tasks, not the individuals. This is a lesson I learned from my boss, and I totally agree with him on this. The format of saying what you did yesterday and are doing today doesn't tell me how you're getting on with a task. It tells me about you – not to mention that format led to those massive tangents we had in sprint 0. As a project team member, it's much more valuable for me to hear how the task is progressing along, rather than framed as what you're currently doing in that task.

4. Set up not only roles and responsibilities but expectations. Yes, we stated roles at the kick-off which was good, but what we all should have done was clarified expectations around those roles. I should have clarified at kick-off what limited capacity actually meant. How much time could I actually dedicate to the project. What I expected my involvement to look like while I was managing two teams.

And similarly, I should have shared my expectations of everyone else. I should have shared with my boss what I expected of him as product owner, like how I expected him to call out the fact we weren't working toward deadlines. And he could have shared what he expected of himself.

I was in a coaching group for content leaders over the summer where I brought up an issue, separate to this project, about collaboration difficulties I was having with someone I was doing a favor for. I labelled this person a poor collaborator because they asked me to help them and they weren't taking the lead or communicating very well in this collaboration. What the coach said to me changed my whole outlook on the situation. They said, I've expected this person to be a good communicator, but I didn't actually tell them what I expected of them and by not having these discussions at the start of the collaboration, we ended up in a place where I've expected things of someone who maybe didn't expect those same things of themself.

When the coach said this, it actually made me think of the degree finder project and this discussing roles issue. Saying your role is not enough. Everyone needs to be clear what's expected of each other.

5. Finally, you set the leadership you want. This goes back to what I said last slide about retros not meeting my expectations. This topic actually came up in a meeting just with the Edinburgh team a few months back and my boss said this: "We should be confident to set out how we want to work in future rather than expecting the agency to be experts who guide us." Wise words.

I love this sentiment. As someone doing their first big project, I felt like I should be led by other more experienced people in how the project should go. I did a lot of waiting for things to happen and they never happened. If I could go back in time, I'd tell myself, yes this may be new territory, but you are a leader, so do what you do best and lead. So going forward, I know not to wait on anyone. If there's a change I want to make, just make it.

13 of 30

Collaboration difficulties getting colleagues aligned

14 of 30

The lack of communication between content and user research

Project started with separate user research and content design workstreams
My team started with content modelling, a task new to me I had to research how to do
Felt strange starting content work not informed by user research
Led to our initial content model being based on assumptions

Initial content model.

The first collaboration difficulties we hit in the project were from the moment my team started on it. There were separate user research and content design workstreams that weren't talking to each other about their work.

My team's first task in the project was to build a content model. I had never built a content model before so I did a bunch of research on how to do this. There was this great article by content strategist Lauren Pope on the Gather Content blog on how to build a content model that came with this handy spreadsheet template, and that was my starting point for building the model. I told my team to look at our current degree finder, the websites of the University's schools, and other university websites to build a list of all the different components, called attributes in content modelling, that could be in our new undergraduate degree finder.

As we were starting this task, there was something that didn't sit right with me. Content design begins with research. Why was I doing a task just on content? Shouldn't there be any research step before then? To be fair, some of the initial attributes we added to our list were ones highlighted by some user research done prior, but how did I know the attributes my team were finding from their audit of other sites were actually meeting user needs?

The thing was, being new to content modelling and working on a BIG project, I didn't think about how to do this collaboratively. I only researched how to build a model. But the result was our initial content model was largely based on assumptions, which is not good design.

15 of 30

The lack of communication between content and tech

UX/content and developers not talking to each other outside of stand-ups in sprint 0
Combination of factors leading to lack of communication:

Project leadership issues
Inexperience with big projects
My limited capacity
Put off by technical jargon

Didn't have oversight of what each other was doing and didn't know about the technical feasibility of our design ideas

Before I get to how we got past that messiness, there is some more lack of communication to talk about. That between content and the developers.

For the most part, our UX/content function and developers were not talking to each other outside of stand-ups in sprint 0. For six weeks, work was happening, but we barely met about it. Before the holiday break we had a total of 1 meeting to go over the first wireframe of the new undergraduate content type we had developed.

I think this poor communication had to do with a few factors.

1- Project leadership issues (and by this I mean, the leadership individual contributors can bring to a project, not just the delivery manager and product owner) – no one was saying let's meet, including me.

2- My inexperience with big projects – I didn't know when we should start meeting with developers.

3- My limited capacity – I didn't have the headspace to even think about meeting.

4- Put off by technical jargon – As I mentioned in my last section, we had a stand-ups which led to long, highly technical tangents. I can't say I felt particularly engaged about collaborating on stuff that I couldn't understand.

The result of this was we didn't have oversight of what each other was doing. The tech team was doing their tasks in their little bubble. And content was doing tasks in our bubble.

As you can imagine, this is pretty problematic in a software development project where developers can only build what they are told. We were starting to build a wireframe, but had no idea about the technical feasibility of our design ideas.

So our project got off to a pretty siloed start. But we realized this wasn't right at that first retro and we turned things around.

16 of 30

How we improved communication

Met with UX Specialist to synthesize research findings with content model
In-person collaboration sessions between content designers and UX specialist when developing the prototype and testing ideas
Tech/UX/content weekly check-in meetings and tech log to write down questions
Roadmap to see upcoming areas each discipline would be working on

An item in the tech log.

On the user research side, my team met with our UX Specialist after we created the initial content model to go through each attribute we proposed and discuss whether the research suggested there was a user need for that particular content component.

We also started having weekly in-person collaboration sessions with our UX specialist when it came to developing the prototype of the undergraduate programme content type. That ranged from deciding on what design elements we should use for each attribute, to coming up with research goals for design ideas we wanted to test, conducting usability tests, and collaboratively watching the test recordings so we could learn about what was or wasn't working about our designs.

For working with developers, we realized we had to start talking to each other and a big thing that helped with that was setting up what we called the tech log – it started out as a spreadsheet and then one of our developers turned it into a Microsoft list which had all these very handy features where we could add issues or questions we had and details about them. So when working with our UX specialist, if we had a technical question related to a design, we could log it.

The log then became the discussion points at weekly tech/UX/content check-ins we set up, so we could discuss face to face the questions we had. A big recurring question at these meetings was, we think we want to design something this way, is this technically feasible.

We'd get our answer and either mark the question as closed or assign an action from it if further work or investigation was needed.

For all disciplines, we were helped by my boss setting up a shared space to create a project roadmap so we could actually see what everyone would be working on and when and readjust things as we went and found that some pieces of work took shorter or longer than others.

17 of 30

Where we still struggled with communication

We didn't communicate new content decisions to our UX specialist, which meant the prototype was not always up-to-date – so one of our content designers got access to make updates
My directions for user stories weren't always the clearest for developers to understand and led to things being developed incorrectly – but check-ins helped us align on understanding

Poorly worded specification in user story.

So that was great, but we also still struggled at times to keep collaborating well.

For instance, the content designers didn't always communicate new content decisions to our UX specialist, which meant sometimes our prototype was out of date because we didn't tell him things had changed. So we decided for one of our content designers to get a bit of training in how to use the prototyping software so they could make basic text edits to it. This was for our prototype for entry requirements which was interactive and built in Axure. We built the rest of the prototype in Miro as there weren't any interactive elements to it.

When it got to the point where I had to write user stories for development, the actual specifications of what to build, I just handed over my written up stories over to the developers without meeting on them first. Granted, the stories I wrote were very detailed and featured front-end and backend visuals. But what happened was a bunch of stuff ended up being built incorrectly, in some cases because my directions weren't always the clearest for developers to understand.

For example, in the content model, we had an H2 heading for what we called the main attributes – the section headers you'd expect on every programme page, so things like fees and funding, careers, entry requirements.

When I wrote the user stories, I listed what the backend specifications should be for each attribute, in other words, how is something presented in the backend of the CMS.

For those H2 main attribute headings, I wrote in the user story under backend specifications: 'heading only PSWCT can edit'. (PSWCT is the abbreviation for our team name.) What I meant by that was, unlike other attributes which could be edited by our school editors using the system, only our team should be able to change those H2 headings. It's unlikely we would change them; they're used across every programme and pretty standard across university course finders. But if someone was going to rename those labels, it would be us that had the power to do so.

But I didn't actually mean our content team would be editing these main attributes in the CMS. In my head these headings would be hardcoded across all programmes. So if they did change, a developer would have to do it.

But that's not how I worded it in the user story. As a result, one of the consultancy developers had built the H2 headings in the backend as textfields for each programme page that could be edited by our content team. So text I expected to be hardcoded and the same on each programme page was built in such a way where human error could have easily led to inconsistencies.

My poor wording was totally to blame because what I had in my head as I wrote that specification is not what the developer understood it to mean, and quite understandably.

The tech/UX check-ins were incredibly handy when it came to reviewing what the developers had built. Whereas I should have spent more time going over the user stories before passing them over, I corrected this at the point when those stories came back to us for user acceptance testing. I used those meeting spaces to go over the issues we found and discuss any instances where things weren't built in the way I expected them to be.

18 of 30

Lessons learned

Strong collaboration and alignment require constant maintenance
Be confident in your design process, question if you're not following it, and change course
Document design decisions and inform relevant collaborators
Meet with your developers before handing over tickets (have a 'design kick-off') and pilot development of your tickets

What were the lessons learned in collaboration?

1- Strong collaboration and alignment require constant maintenance. Just because we had done stuff to fix our early collaboration difficulties didn't mean it solved everything. If you're not on top of it, difficulties arise again and new ones appear. You have to keep working at good collaboration.

2- Be confident in your design process, question if you're not following it, and change course. I should have acted on that instinct that told me something wasn't right about building a content model without research. Yes this big project was new territory to me, but similar to a lesson learned I mentioned in the leadership section, I should have taken charge and talked to our UX Specialist sooner. Like I said previously, my lack of experience in a big project meant I kept waiting on things to happen or to be told to do something, so it was a failure of my own leadership that I didn't take charge in this way.

3- Document design decisions and inform relevant collaborators. Yes, getting one of our content designers access to edit our prototype was useful, but at the end of the day, we should have been keeping our UX specialist in the loop about the new content decisions that happened. Having a formal process for documenting our decisions and communicating them would have helped with this.

4- Meet with your developers before handing over tickets and pilot development of your tickets. First off, as detailed as my user stories were and the developers did appreciate how detailed they were, it would have gotten us all on the same page sooner if for each ticket we met to discuss what was expected and I could have realized sooner cases where my instructions made no sense.

I was talking about this project and its collaboration issues with a fellow content professional in Australia who used to work in universities, and she told me about how she would have 'design kick-offs' for the tickets she passed over to developers, so I have her to thank for this idea of an initial meeting. It did seem so silly to me after speaking with her that I didn't think to do this in the project. I would never hand over work to my content design team without meeting with them to train them in how to do it. Why should the process be any different for handing over work to collaborators?

What I had thought about previously, though, was we should have piloted the development process for user stories I sent over. By this I mean, we should have agreed that I would pass over only one user story for development when we started, wait for that to be developed, and then reviewed it to see what issues arose. That way, we could have worked out any initial issues before more tickets were developed. This as opposed to what happened in the project where I passed over quite a few tickets which were built and I saw similar errors through each. A pilot could have saved those repeat errors from happening.

I appreciate a lot more now how much work I'll need to put into developing good communication with developers in each project I do.

19 of 30

The feeling of a project within a project

AKA designing entry requirements

20 of 30

Why entry requirements felt like a project in a project

Front-end: The content is complicated

many qualifications and entry pathways
grades listed by fee status
standard and widening access requirements
additional requirements
English language requirements
endless exceptions to the rule...

Backend: Had to design a process where a spreadsheet of gathered entry requirements could be uploaded to new degree finder and populate it

Current entry requirements design.

What was it about entry requirements that felt like a project in a project?

First, the content itself is complicated and messy. Here are all the different things to design for in entry requirements:

1- There are many qualifications and entry pathways. We have SQA (Scottish qualifications), A level, IB, qualifications from countries around the world, UK qualifications other than the 3 main ones mentioned, qualifications if you're a mature applicant, qualifications if you're a university graduate returning to do another undergraduate programme. All those qualifications for almost 400 degree programmes is A LOT of content.

2- As part of the new degree finder, the University was also keen to use this opportunity as a chance to implement something they've been looking to do: list grades by fee status. If you're not from the UK, fee status is the term we use to determine whether you pay a Scottish, rest of UK, or international fee rate for a programme. Due to government caps on Scottish students and high competition for students from other fee statuses, the grades you need to be considered for an offer is determined by your fee status.

Our current degree finder expresses these grades as a range, which is obviously confusing for students because the range doesn't mean get between this and this score. It's reflecting the fact that one fee status can apply at the lower end and one at the higher end, but the content doesn’t actually say that. So we had to design something to explain this complicated relationship between fee status and admissions.

3- For every programme there are two sets of entry requirements to consider, standard entry requirements and widening access requirements from students disadvantaged backgrounds.

4- Some programmes have additional requirements other than grades that need to be listed.

5- Every programme has English language requirements.

6- On top of all this, it's very hard to find consistent structure in this content because there are endless exceptions to the rule. So designing this content involved trying to find what programmes were similar and could be given a structured template and what differences we needed to make for the exceptions.

Just at a frontend content level, entry requirements was complex and my team was responsible for making it better. Unlike other areas of the degree finder where content is created by school editors, we were co-designing entry requirements with admissions as it's a central service area.

And it turns out, the backend processes were equally tricky and needed to be co-designed as well.

I mentioned near the start that admissions has a process of liaising with admissions colleagues around the University to gather entry requirements each year. This process involves these scary-looking spreadsheets where college-based admissions staff input the new grades in. The spreadsheets are massive with a lot of data in them.

Currently admissions just copy and paste that data into the degree finder each year. One of the enhancements we wanted to make in the new degree finder was having a process where we could upload the spreadsheet they gather their data on, and it populates the grades and info on the degree finder for them.

Practically, what this meant was making sure our backend was structured in such a way that the fields we created could be tied to fields in a spreadsheet and that we design a spreadsheet that could work in this upload process. The fact that the content had so many exceptions to the rule made it that more difficult to think of design solutions for the backend that would accommodate both the consistent structures and the exceptions.

21 of 30

Designing this one element took more effort than designing every other part of the undergraduate programme content type combined.

22 of 30

An uncomfortable start with entry requirements

Original content model featured attributes for existing presentation of entry requirements because I knew we couldn't build the model for it before working with admissions
Admissions saw this original content model and were concerned it didn't factor in any features they had previously raised with our team about what needed to change
I felt awful upsetting very important stakeholders

Entry requirements also got off to a bit of an uncomfortable start.

When my team created our initial content model, I was in charge of listing the attributes for entry requirements. Because I knew we'd have to collaborate with admissions to design the experience, it felt like wasted effort to find or add any new attributes about entry requirements. I needed to build the model with them. So in the spreadsheet housing our content model, I just listed the attributes we had in our existing degree finder in the meantime.

At a consultation event on the project, I shared the content model spreadsheet with attendees and admissions saw the entry requirements section and were concerned that the model didn't factor in features they had previously raised with our team about what needed to change.

We'd done research into entry requirements before, but what I didn't know is that our developer and former UX specialist had quite a few other sessions with admissions around designing the new entry requirements experience in the past few years.

So when they saw that content model that just listed the same attributes as the current degree finder, they were understandably upset about they fact they'd invested a lot of time and effort into requirements gathering and this information didn't get passed on to me.

I felt really awful about this. I was left with this uncomfortable feeling about upsetting important stakeholders, especially when their concerns were valid.

23 of 30

Turning the discomfort into an action plan

Put 75% of our content design resource into entry requirements work
Reviewed previous research and work done by our team in this area
Agreed a timeline and number of hours of collaboration time with admissions

2 two-hour collaboration session a week over 4 weeks
1 collaboration session a week was in-person

Created agenda for each collaboration session so we could get through front-end and backend design in the short window we had
Got through all we needed to by the end of 4 weeks!

I couldn't change what happened but I could turn that discomfort I felt into an action plan. I knew it was time to seriously plan out the work on entry requirements. Realizing this was a big job needing a lot of our attention, I put 75% of our content design resource onto it.

One of our content designers set off to get familiar with the previous work done by our team so we knew what admissions had discussed with us in previous sessions.

I had another content designer take charge of the project management of collaborating with admissions. We agreed a timeline (4 weeks) and number of hours per week we'd work with them – 2, 2 hour sessions, one of which was in person.

We worked to build agendas for each collaboration sessions so by the end of four weeks we would have tackled both front-end and backend design.

Through being organized and disciplined in our approach to collaborating with them, we ended up getting through everything we needed to in the 4 weeks we set aside to co-design with them.

24 of 30

Convincing admissions to change the term 'minimum requirements'

'Minimum entry requirements' refers to requirements students from widening access backgrounds needs
Admissions knew the term was problematic but were reluctant to change it
Showed 1 usability test of a student incorrectly assessing themselves as eligible for minimum entry requirements and admissions agreed it needed changing
Compromise reached: referred to as widening access requirements in dropdown selector, but minimum requirements when content appears

There's a lot about the specifics of that collaboration that would be great to share, but we don't have time to get into. But I do want to share one story about what became our biggest win of the process.

One of the issues with the current degree finder is that what lots of other universities call widening access requirements, we call minimum entry requirements. Other universities use this term as well, but it's problematic. Understandably, students think this means the minimum grades they need to apply. If they get those grades, they'll be considered for an offer, when in fact minimum really means a lower set of entry requirements that students from disadvantaged backgrounds can apply with.

The reason we use this term though is because some time ago there was this meeting of university admissions teams in Scotland, and at that meeting, it was decided to create consistency across the sector for what entry requirements are called and the terms standard and minimum were chosen. So admissions were insistent on using it because that's what was chosen by this committee and Edinburgh had a part in deciding on those names.

If you look at Scottish university websites, though, almost no one else is using the term minimum entry requirements. They use terms like widening access, access, or gateway requirements.

We were trying to get across to admissions that if other unis are using more descriptive terms, surely we should too. We've known for years from research that the term minimum requirements is a big issue and creates a lot of confusion for applicants.

But admissions wanted to keep with the agreed terminology. So we went ahead with designs that still used minimum requirements. We did usability tests on them, and basically every participant who would be eligible for standard requirements wrongly assessed themselves as eligible for minimum.

I know from my years of showing usability tests to stakeholders how eye-opening seeing tests can be to really grasping the issues with your content. So at one of our two-hour collaboration sessions, I had planned to show them the tests we'd done with students failing at this task. But we were running a bit behind schedule and before you know it we were at two minutes before the end of our session. But I said, let me just very quickly show you one of the tests we ran – it'll only take two minutes.

And that 1 video of a student failing at that task was enough for admissions to realize they needed to change it. We eventually agreed to a compromise solution.

In our design a student has to select the country they study in and their qualification. The dropdown for qualification has two options for each UK qualification: standard and minimum. And when you select minimum, text appears showing the grades you need.

So our compromise is that the text that appears would continue to say minimum requirements, but the dropdown selector option would say widening access requirements. So the point at which students have to make a choice of which requirements are for them, they're not seeing the wording that will make them think minimum requirements are relevant to them.

After we made that change, we then tested our new content at an undergraduate open day and no one made the mistake of choosing minimum entry requirements when it wasn't relevant to them. That tiny change has a massive improvement on the user experience.

So of all the uncomfortable and messy moments we had in designing the entry requirements experience, it ended with what felt like a pretty sweety victory getting agreement on a better content experience.

25 of 30

Lessons learned

The biggest content design challenges are most likely people challenges
Good content design can only do so much when the service itself is complex
Make sure there's enough research done on service areas before doing design work (and that you know about prior research)
Scope your work
Keep your important stakeholders in the loop
Show is more powerful than tell

What that story and the rest of working on entry requirements taught me was more of a reminder actually: the biggest content design challenges are most likely people challenges. Nothing inherent in the content made it difficult to design- it was the policy decisions that made it difficult to design.

I once saw a conference talk a few years back where the speaker talked about how no amount of good content design can fix a complex service, and the same was true here. Good content design can only do so much when the service itself is complex.

Another lesson learned in entry requirements is to make sure there's enough research done on service areas before doing design work on them, and if research has been done, make sure you know about it. In the case of entry requirements, we did do a lot of research beforehand, but our team wasn't up to speed on all of it. But the process has made me reflect on how much more difficult this process would have been had I had zero exposure to it before or had we done no work on it prior to starting this project.

That's also tied to the next point: scope your work. I wish I had started the project thinking about all the different areas we knew we were going to tackle and had a think about how much work it was going to take. I was too consumed thinking about the whole product, I didn't consider the bits in it and the varying amounts of effort they would take.

Next, keep your important stakeholders in the loop. I wish I had told admissions before our first content model consultation session that our content model wasn't up to date for entry requirements. Better yet, I should have just not shared it publicly and told them why I'd added nothing to it yet.

Finally, show is more powerful than tell. Even though admissions knew minimum was problematic and we'd discussed this a few times, it was only through showing them one two-minute video that it finally clicked with them that something had to change.

26 of 30

Where the project is at now

27 of 30

Released a beta in September

Featuring 3 degree programmes in their new content types
Have a look: https://edin.ac/ug-beta

Veterinary Medicine in the beta site.

28 of 30

Developing the postgraduate programme content types

And are trying not to repeat the same mistakes!

Programme in current postgraduate degree finder.

29 of 30

"Expect the discomfort and messiness, and use that feeling to make things better."

-me to you

30 of 30

Thanks for listening.

Questions?

Email: lauren.tormey@ed.ac.uk

LinkedIn: lauren-tormey

Twitter: @ltormey

Team blog: https://blogs.ed.ac.uk/future-student-experience