Being introduced to the 'multidisciplinary team'
Timeboxed to build, test and deliver a new thing. Here’s three things I learnt when I joined a multidisciplinary team for the first time.
A team was assembled of policy experts, communications colleagues along with your standard array of digital roles; developers, content designers, user researchers, performance analysts, designers, product and delivery managers.
This was something quite new to me. I’ve worked at GDS for well over a year now but I’ve only been a junior content designer for about five months and worked in team made up of mainly content designers.
Day one 🌇
I wasn’t really sure what I was expecting. I knew I’d be with four other content designers (later two others), the work was somewhat fast paced so we had to be quick with our decisions yet be able to explain why we did something a certain way.
One of the first things which had to be done on my first day (technically day three of the eight day sprint) was turn policy definitions and explanations into something which could be easily understood by users.
That involved tweaking, adjusting or rewriting to make it as plain English as possible. Sometimes it’s quite easy, sometimes less so. Our policy colleagues explained to us what the things were and worked with us to make them more user-centred.
It was quite refreshing working together with policy colleagues in the same place trying to tackle the same issue. Something it’ll do more of in future pieces of work.
Iteration is key 🔑
During the first sprint, we knew the content in our tool wasn’t the best or even perfect, we knew it could be better.
Knowing something isn’t quite perfect is something I’ve struggled to deal with in the past. It doesn’t get to me as much as it used to but it’s still a bit difficult to look at something you’ve worked on and know it’s not perfect, however, we knew we’d get it in the user research lab, test it and then iterate.
It was good to get the chance to observe two days of user research to then iterate it to firm up some of the content we weren’t particularly happy about.
Our second round of user research a couple of weeks later shown the changes we’d made in between had made a difference in users understanding what they were being asked.
The ‘what’ and ‘why’ 🤔
Typically as a content designer working on ‘business as usual’, we get the bulk of our information to do a piece of work, like updating a piece of content, through a ticket including the user needs, the changes and any additional information.
In this project, since we’re working with a range of disciplines, our product manager recommended including ‘what’ and ‘why’ into each of our cards when we were adding something to the backlog.
Including ‘what’ and ‘why’ didn’t just help the person on the team picking up my card to understand what needed doing, it also help me to understand what needed doing in the first place and articulate the task clearer. It made you think first rather than just putting a card in which could be quite vague.
I’ll be sure to use this method again.
Sit back and reflect ✍
Over the past few days, I’ve had time to reflect and review the past few weeks.
There’s definitely some practices and techniques I’ve developed, there’s still room to develop, especially around those tricky situations, but safe to say it’s been a great few weeks and more new experiences in the new year.
After a short time working in higher education student voice, it’s time to move on to my next adventure.
Attended some meetups, juggled training across the country, oh, and organised one big cross-government content conference — it’s only been 37 days since this journey started.