Hi, welcome to our webinar. Thanks for taking the time to join us. Just a couple of admin things. Firstly, we’ll be taking questions through the function on the webinar sign in, and we’ll also be live tweeting through your Twitter feed, and you can pick up the will pick up questions through that as well.
So john and I are here today to talk about our lessons of leadership, and the legacy that you can create bringing in service design and user centred design processes into your work within the public sector.
The, the john. We’ve been working john and I have been working together, and separately in the public sector, for, for a long time.
And and most most, most, aptly in the last six years following the GDS framework and the great things that gov.uk
and GDS have been doing. I’m a digital native working 20 years agency side delivering all sorts of digital products and specialising within the public sector within the Mensa. Good, okay i’m john on the head of user experience at Mensa and what that means is I lead a large team of practitioners here. That team can include service designers user researchers content specialists designers and all the different flavours, that make up the kind of modern digital delivery team. I’ve been working for 17 years.
Follow us on Twitter and all that jazz really, you know, one of our specialisms have been, like, Amanda said in recent years has been with following GDS framework and delivering just excellent work within the public sector. And when we sat down what we, our webinar today is, is a talk that we gave last month in st and guff in Edinburgh. And what we intended to do is when we sat down with all we could do a case study on one particular programme of work but what happens is myself and Amanda work very closely together we work across across many projects and many different clients and most importantly, I suppose, many different elements of the life cycle. So what we wanted to do was create a talk for you today, which effectively covers and spans across discoveries alphas Beto into life, but also is drawn upon lessons that we’ve learned across a massive range of public sector organisations and this slide that we’ve put up here, effectively covers just some of the examples that we’re going to pull up, but everything that we’re going to talk about today is kind of what we believe to be eight lessons don’t we Amanda, yeah. Eight kind of common lessons that we see time and time again. No matter which public sector organisation that we engage with.
And then at the end of today or by halfway through today’s webinar we end to kind of talk you through a framework, which is allows you to spot, kind of some of the triggers, or some of the patterns of behaviour within project teams, which allow you to kind of get a feel for if your project is truly going to be successful or not. And also how you can maybe track cultural change and organisational change as you go through these processes and adopted. We want to cover a small cross section of lessons we’ve learned along the way, and how these have led us to understand the legacy of goods that good service design can leave behind.
This is far and away not a complete list, and we’re looking at it particularly through a user centric design lens.
So we’ve got eight lessons that we’re going to go through, and four of them, we grouped under what we call project lists. And these are effectively things we see time and time again at a project level of things working.
So let’s jump into it.
You will never understand how complex our service is set by basically every person on day one of every project we’ve ever worked on, you first come in you meet the client, you meet the product owner or whoever is responsible. Delivery Manager, and they are adamant that the complexity of the services is through the roof and to be fair, they are right. You know if things were simple then, then, then, you know, successful service design would wouldn’t be commonplace which is starting to become but I guess my point here is if something is so easy to do then everyone would do it. But what I’m trying to get at here is we often start from a position, or we see on projects people talking about job walls or personas or what they perceive to be personas, which often fall into kind of more be more of a marketing segmentation definition. So for those people who work within service design or within the user experience community, what we tend to see is, actually, you know, the number one lesson is you don’t have as many users as you may think, and this is what.
So, possibly one of the best examples of this was our work with the Met Office, and you might have seen this in some recent articles as well. Actually, the Met Office as a client doesn’t have a very diverse huge range of bespoke audience members. What they have is, is obviously members of the public who engage with the weather in a plethora of ways. So what we did in this project was try to approach the definition of that audience groups and their personas in a range of different contexts, rather than individual audience groups and market segmentations per se, so you know here what you, what you see is what he’s gone through his, his his people who were preparing to do some kind of journey and then that’s why they’re inquiring about the weather. And on the left hand side of the screen shows you where we conducted some of the user research in this example and this really helped us help work with the metal is an example of defining your audience base through contexts, rather than starting from day one of a project with, we have 24 different audience groups so on the left you can see is we went to the Brecon Beacons, and we spoke to mantic rescue teams who we’re using, we’re using the weather in a certain context. We went to just to be tall and spoke to residents who live basically on floodplains because what people don’t realise is the metaphors have a safety critical nature to their work. And we also went to Bristol and Manchester and spoke to general members of the public and what you then tend to see is the same groups of people looking for the same information but in different contexts and the priorities with which they’re given, and we see is time and time again. And it’s and it’s, we see it time again and it’s also a model that we take for us and we’ve also used this recently for highways England and applying contextualised behaviour based personas rather than more individual This is john, he said, segmentation. Exactly.
So, and the second major pattern that we see it or second lesson that we see and for those of you who’ve worked in service design for a while, you may well think well this is obvious but you know, we see it time and again, where the niche groups or the niche audiences in some examples are just hard to get to. And really what we’re trying to get people is to break out of the lab mentality there’s a time and a place for lab based research but there’s also a time and a place when trying to get access to these very particular groups, I think in here like High Court judges actuaries who if ever you’ve worked in the pensions industry, they don’t get out of bed for 50 pounds for your hour long usability study could be incredibly busy people within health care service which is a key area for us as well. So just to give you some examples here. What you see is you know the NHS nobody in the NHS is sitting around with an hour or two spare you know it’s a highly pressurised service. We’ve been which often, you know, you need to get go to where they are. And on the right hand side here, what you’ll see is our. One of our project leads here in the midst of Zoe Beeman led an excellent piece of work where she effectively felt like a world war one general pushing toy soldiers around a map that she planned where every member of her project team would be travelling to conduct ethnographic observations in the wild, and really there’s just kind of a common pattern where this is a lesson learned either from projects or doing it really well, or they’re not doing it at all. And we feel it’s important to call it out, that sometimes some of those super niche audiences, the only way you’re going to get hold of them is to go where they are. And we have come across that quite a bit in terms of going and talking to teams and saying, Well, why can’t we call them up or why can’t we do lab based testing where they come to us and, and then we talk about the value of doing a ride along in an ambulance or go into a call centre to understand what sort of user issues are coming in through a different channel that isn’t digital.
Okay, so to yourself. Yeah.
It’s funny for this for this when john and I debated because for an immense he lives and breathes accessibility and inclusive design and we have done since our inception, but we’re still seeing in 2019.
The having to have conversations of why inclusive design why considering people with access needs acip digital technology needs even low digital skills or low reading ages, need to be included in. In the services from the start. We’re often seeing this at quite late stage or very very separate. So it’s great when we come across organisations where they have champions internally. And if they don’t, then we try to act as their champion where we can, when we, when we did this champions the key word trust isn’t it because it’s, it’s the separation of accessibility into into its own silo. Yeah, which can hamper in our opinion, the success of any accessibility actions that you may. You may engage with. Yeah. And, and, you know, accessibility is quite an easy one to slip into a box ticking exercise because you have a set of guidelines that it’s very clear cut whether you’ve met them or not, however GDS is great at encouraging public sector services to go and above and beyond the workout guidelines to include users at all stages of the test. Testing so not necessarily do testing with a discrete group of users with access needs but include them in the research right from the beginning, and also to consider it as early as possible discoveries, not, not unusual to start thinking about these, these users.
So the last of the project lessons that we’re going to talk about today. Remember, each of these lessons we’re presenting our opinion ones that we see on almost every project. Yeah, is we have to acknowledge that successful service design in government comes in all shapes and sizes and most importantly the elephant the room that no one ever wants to face budgets.
But what you can still do something irrespective of what your budget may be, if you have five pounds or 5 million. There is always something that can be done, and this is the key message from from ourselves and.
If in doubt don’t bang for buck from our experience, if you have to do one thing. It’s content.
And actually, time and time again working with perhaps slightly smaller governmental organisations. We’ve seen that they’ve been able to do massive massive change without necessarily, you know, running off and worrying about the technology stack, every time and time again, don’t get me wrong. I’m not saying, technology is bad or digital transformation is bad. My point here is that, if, If in doubt, if you actually want to achieve some successful meaningful change in customer service, you can do a lot worse than change the content, it’s also sometimes the easiest thing to convince sceptical or risk of our stakeholders to to change first. So, I mean this this one here is just a case study really where this happened so the rail safety and Standards Board. Back at the tail end of 2016, we’re looking to begin and commence a digital transformation programme but really we’re operating our level of wanting to win hearts and minds as well with the value of digital investments. And what basically the rail safety and Standards Board is is a collection of incredibly technical content that can be hard for a naive novice user to engage with. So what we propose to them was basically what we call the content pilot. And this was a relatively short discrete piece of work, which would focus down on one small area of their website, improve the content within that area and help them disseminate it and effectively, almost like a micro content strategy to achieve value and demonstrate the successful for their service, where else it is drying up a couple of dis diverse departments. So, external comms and the digital team were working very separate and very siloed. And what this project did was brought them together to consider the full journey of content from creation through to publication on social media as well as the website. Exactly and to get cliche tastic wasn’t it we ended up kind of having two features here one was how do you eat an elephant one piece at a time.
What’s your favourite. That was my favourite phrase on this particular project. And what I mean by that is we wanted to you know, also, how do you feed, how do you feed my food today, you know, that classic one of if you give someone a fish or do you teach them how to fish. And the point here is with the relatively smaller timescales and budgets that we were operating to. We took incredibly complex content and just focus down on the two topics that you see at the top there which was health and well being and the platform train interface and the platform train interface it’s actually a really good example of an internal organisations terminology. For most people, you’d probably associate it with something like mine, the gap, particularly obviously if you live in London.
What, well, I just want to show you this here is simply moving on. What we gave them was the confidence to once they demonstrated massive success with just focusing on two areas of their site’s content they now have the confidence to move forward as you can see, to multiple other topics that their, their internal teams are able to confidently deliver. And what this finally did for the client was convinced some sceptical and risk averse state stakeholders, right at the top to release budget for a more comprehensive CMS, so technical stack overhaul. And, and a new, a new website which is due to go live in the next week or two. And I think that’s really important right because the digital community will he go on Twitter and everyone will be shaking about digital transformation and obviously it’s important and there’s a time and a place, but I think for us what we were trying to get to was that not every organisation, you have to acknowledge to be successful service design that you need to move at the speed and the pace with which the organisation needs to move, but actually, with this example here, some investment in content and content alone was able to then move them forward on the journey. Yes.
Okay. So then we’re moving on to leadership lessons, which are a little bit more thinking on how as product owners as delivery managers and also just as us as decision making team members. How can you ensure that the, the you’re leading the project and the service design in the best way. So the. These are again just a snapshot of some of the things that we’ve come across quite a bit, and how we’ve how we’ve dealt with them but also help assisted, our client partners in moving forward.
So, this one, and again it was one when I presented it up in Edinburgh, to a roomful of service designers, it felt like I felt like I was preaching to the choir, but it’s important to actually speak to that, that, especially if you’re following what’s happening within GDS and the move from digital service standards to government service standards that whilst digital is key. We’re not at the full service design, the lived experience isn’t solely on digital, no one, no one starts and ends their, their journey through a service. In just one channel or voice, or one sitting. So we’re from some from people leading projects were encouraged you to understand what the full lived experiences, something that was being worked on whilst we were also we were in first defining this is our work with highways England, where, where we can, where we talk about the letters people receive the signage, the call centre experience when you get a fine and you don’t know why, a more mature journey that we’re doing is, we worked with innovate UK which is an organisation.
Government organisation that releases innovation funding into the market to grow the UK economy, and we’ve been working with them for about four years to define key elements of quite a complex service as you can see from this image, and this is only one snapshot of once a client. Once an applicant has received funding, how do they realise those funds through the through the project, who’s involved, what happens offline what happens face to face what happens through a phone call, and the by mapping that all of that out. We were able to then define an MVP, to take live into a public beta, but also to understand the complexity of the lived experience. Once you’re in receipt of funding from the government. Yeah, I think, just to give two grand this kind of example like in the middle of this, this slide at moment you can see the making a claim cycle, but it’s, you know, a bit of a extreme example but I think the thing you’ll need to understand with innovation funding is that the people who get lots of innovation funding are probably brilliant individuals or companies or organisations who have a great idea, you know, let’s say you’ve invented the flux capacitor. That’s brilliant. But the thing is, you may not have any experience of actually running and managing a large multi million pound project. So, in terms of this this piece of service design here, you have to call out early on that the making a claim cycle, or any part of this internal Project Setup etc. is important, because the user base that you’re dealing with may not have the experience that you believe they have. And, and it demonstrates that not every service is a straight line and I’m sure that some people who are listening to us just just now are used to getting posted notes drawing a straight line, understanding that the start and end of a project but in this case, this can be a three to four year, making a claim cycle where you’re cycling back through the same activities, every quarter, and so it isn’t so much a straight line and you have to acknowledge that within that within the service as early as possible. Yeah, exactly.
So the, the other.
Another key leadership lesson for us is to know when to challenge. So, this is not just us being able to challenge our clients in presenting a best practice methodology, or perhaps opinions or evidence that go contrary to perceived wisdom, but it’s also giving the people we’re working with the skills, the knowledge, the confidence to carry forward.
This this idea of a friendly. Non confrontational challenge and to to understand what what is when things are right for users. It’s also in this particular context, passing gateways becomes a bit like an exam right so it’s like let’s prep for the exam. Let’s make sure we pass the GDS gateway assessment. But actually, you have to always remember that this is a service you’re designing for the users. And once you’ve benefited gateways. It’s your users who are going to have the longest term impact so it’s balancing those two things. And it’s a it this this next slide is a good.
It’s a good example of this, this map now that GDS is an established process you get a pushback. Are we are our services only for internal users were exempt from GDS or, we’re in arms like body we don’t necessarily need to. However, this is the GTS alpha discovery alpha beta live the way they approach us user centred design processes is a really nice framework for best practice and just because you don’t have to go through assessments, doesn’t mean you shouldn’t be following it and and shouldn’t be applying some of these principles to your service design and I think drawing on our experience like we said at the beginning with all of our client bases. We’ve met. We’ve had clients that think they’re exempt. And we’ve had clients that know they’re exempt but want to follow best practice anyway. And I think that’s the key thing to call this challenge the exemption clause because we have been down the road a couple of times where, where we found out quite late in the project that an assessment does need to happen and does need to schedule so if you’re following the practice, then you’re not caught unawares.
service design delivery that that within the project basically that that things have changed, you know, delivery of brilliant services doesn’t occur overnight because of years, not not days, and many things, you know like getting into politics many things can change referendums can happen new legislation can be launched, you can just enter a part of the budget where you suddenly realise that actually your knowledge base that you previously had built up, it doesn’t cover everything you need to know.
So really, for us the successful lesson here is kind of recognising that discovery sometimes doesn’t really ever end and actually no matter which phase of the lifecycle you may find yourself in. It’s important to always be asking the question and the successful projects in my opinion really are doing this is kind of saying okay what when do we need to go back and for me as I’m wearing my practitioner hat This is effectively, knowing what techniques to use when, you know, you may be in a late beta stage several weeks before going live and you could be doing a lot of lab based research just looking for these final polishes and tweaks that you want to make to the service. But actually if you discover something which is a fundamental risk you may well need to go back and do a more explosive piece of work, and we’ve come across that where we’ve come into projects at alpha, beta where discovery has already been done, but because of the time difference because because of the time lag, change of of staff change of policy, or even just budgetary considerations that some of the findings and discovery are either outdated, or no longer apply, or the service or the scope of the services change. So looping back into discovery at those stages, even if it’s rapid, even if it’s just covering a few gaps is really important. Don’t just keep moving forward for the sake of example, without naming naming the potential government organisation we can think of one example where literally the introduction of new legislation turns that service from being relatively small to critically important overnight. And actually that fundamentally meant that the project team had to stop and go, okay, where are we really, yes.
So this one is an interesting one from our perspective obviously coming from an agency where we hire and work with consultants. The, we often have T shaped people where they have a deep specialism but a broader empathy and knowledge across the user centred design. The user centred design disciplines. However we acknowledge that within government organisations, especially in terms of creating cultural change, putting in a strong emphasis on on these disciplines that you will get teams of user researchers teams of content designers of teams with really deep professions and specialisms. However, we want to acknowledge that. That.
As you mature and as your organisations which are looking for overlaps between those professions overlaps. We’re also looking for empathy between the professions. So, I’m getting going from a place of developers not at all interested in watching what user testing is doing to them actively asking when the next round of user testing is to to understanding what’s happening in research sessions, and how they can apply it to their backlog and to their problem solving further down the technology line.
It’s it’s the it’s the it’s the just old adage of don’t sort people into disciplines. And then, and then refuse to acknowledge evolution and emergence Yes, if you’re working on service delivery across years just typically seeing within the public sector. For us, this is a big one because what we see people’s behaviour change. This is not necessarily about moving into a new discipline, because sometimes it is. But also, like I think, Amanda said it’s that empathy kind of standing up for your other fellow just.
So those are the five, eight lessons that we wanted to talk through today, and then when myself and Amanda first put this talk together we kind of realised that we, we felt we were on the beginning of a some kind of framework really, because we feel that those eight lessons are the ones that we see time and time again within service design in the public sector. And we asked ourselves really kind of, well how can we make this into a useful tool that people can take away from today’s session or hopefully people to the lady from when we presented this in them.
Because I think the elephant in the room for us as as an agency especially, is that there was a piece of text within the service framework which is critical to understand. Yes. And so the one of the key service standards is a sustainable team that can have the core skill sets correct senior team in order to make decisions to make decision making. And a lot of times this is interpreted not wrongly as self sufficiency. So, one of our key goals moving into any project is to be transparent and collaborative and to provide people with the confidence to acknowledge that self sufficiency and to understand what sustainability looks like moving forward.
So, if you don’t leave a legacy of sustainability and success with the project team, we started asking ourselves well, what are the indicators, one of the things that we see or the behaviours from the teams that, in our opinion, sometimes, looking at from the outside in, you can say okay well in the long run that that piece of service design for that project is getting that project itself a service will be successful, perhaps test the success that it couldn’t. So we’ve got seven indicators, and they’re kind of build upon the lessons and build upon our experience from, quote unquote, good and bad projects.
So I’m just going to kind of start going through them. And this is an emerging framework so we’re gonna at the end of today’s session we’re going to be happy to take questions and thoughts. So, here we go.
So maturity of techniques. So, with this kind of good bad idea of a project what we’ll be talking about here is project teams that are following box ticking card prompts and box ticking is the phrase that we’re going to go with for today that there might be kind of lip service was another expression that we thought we might use but basically project teams which are just kind of saying they’re doing it in order to try to make pass assessments and the kind of indicators here of where they’re just kind of box ticking gone good service design will be knocking on reliance on one technique for example maybe they’re only doing lap based testing and, and they use the phrase a lot, or we’re just going to validate we’re going to validate rather than any kind of exploration, and they might be overly reliant on quantitative data, rather than getting out there and talking to users. And when we talk about tokenistic sponsor research, it’s not just budget but also people and and time. So giving not squeezing that use that research element of it. So, the opposite of say a box ticking project with kind of maturity of techniques if they’re really affecting cultural change and embracing a service design mindset what we tend to see is most project teams are using a broad range of appropriate techniques, and this is coming on to our earlier lesson around knowing when things have changed and knowing that actually we this is okay for us to maybe do some, some more invalidated kind of laboratory type work or, you know, we need to stop and go back to discovery and do some real kind of on the ground research techniques, and you’re a real proponent john Are you of those, keeping the research to route discovery alpha beta and live, open ended. So, so not just. Is this working is this not not just a traffic light or yes no kind of dichotomy. But actually continue to answer those open ended questions so you were not missing user needs.
So inclusive design we’re coming back onto this because we think it’s really important and it’s it’s a it’s about moving away from the types of behaviours that see a box or to see a contained area of non standard users or that that the accessibility or inclusive inclusivity happens, separate and quite late in the project. Yeah, I mean it’s this is the silo mentality, I mean the classic mistake that those people who have been in the industry for a while, probably seen at some point, is what i what i annoyingly call the disabled persona. And this is where you see projects you say oh this is Frank Frank has dyslexia dyspraxia is wheelchair bound, as part of visual impairment and broke his arm playing tennis Frank’s having a really bad week.
You know, this kind of idea that disability can be put into one person, as opposed to disability is something that affects everyone, or has the potential to affect it.
And when you start to see that the other side of the box ticking is the, is what’s on the cultural change scale. And it’s, it’s, considering inclusive design early and often that lots of people within the organisation are talking about it. It’s not one lone champion it’s not pushed to suicide. It’s not left too late with a very small element of budget, I think, just before we move on to the next one. Actually, I just wanted to go back. Some people in today’s session may be saying what you mean by those kinds of people. Just wanted to call this out and this is actually a quote taken in 2019 for my project where we were advocating the use of of inclusivity and the response back to us was effectively. Oh, we don’t need to worry about quote unquote, those kinds of people which I’m sure many people on today’s webinar will kind of be falling off their chairs oh I hope you’re falling off your chairs but such a mindset, but our point is that we still see that kind of attitude on occasion and it’s 2019. Yeah. And also it’s another point, move on from this slide is that Microsoft, the home office of GDS are moving away from an NHS, and the NHS are moving away from acknowledging the that disability. accessibility considerations are always permanent conditions that you could have you could have temporary conditional situations like holding a child and one hand, or breaking your arm that that would provide some of the same barriers that have more permanent disability would. Yeah, speaking as someone who just returned from a broken back in my first day back in the office, I totally empathise with the point.
Okay, willingness to change some of the classic examples here so say project teams they’re just trying to do the box ticking. you know, they start with that kind of mindset of our legacy system will never change it. You know, it’s that they’re absolutely incapable of making a decision. And I think really the worst one really is when you join the project team whatever you are could be a beta alpha discovery where you kind of ask very basic questions and don’t get an answer to your basic question so you say things like, Where’s the user research or, why did you do that. Yeah, and you just met with a room of trucks. Yeah. And another key area is decision paralysis. You might get a room full of people, but no one’s making the decision to drive things forward or to put a halt and to regroup. That there’s there’s there’s that lack of leadership and not just leaders but leadership.
So obviously the counterpoint to that is teams who say that kind of what can we do with what we’ve got. And I think the best example for that without explaining too much as was rssb example, yeah, where you know it’s this kind of case, nothing else can we change the content. Yeah.
And the, you get you get all levels and willingness to embrace change so you start to see conversations going well we’ve always done it that way, or we can’t do it because of x y and Zed, too. Well, what can we do what are the quick wins. We’re working on a project where we have a service design that’s not going to go live for another two, two and a half years, and the. Our client partners are asking, well what can we change on the life service, not, not just what can we design for the future but what can we change on that’s currently live that will improve the service for our users right now.
So, research continuity. It’s similar one to the range of techniques that you might use with research but for us this is the one that they continue to do research throughout the lifecycle. And you know, and the teams that are failing or in our opinion in the longitudinal time will struggle, are the ones that say oh it’s done. Thank you for the discovery let’s put it on a shelf and never look at it again.
Yeah and you you as I think we’ve said a couple of times where you don’t feel comfortable research revisiting research, or actually redoing research, if you’ve acknowledged, things of change. Another key indicator This is that siloed working, where user research, whether it is seen as the as the domain of those user centred design disciplines and not of the wider team.
So obviously as you can well imagine the counterpoint to that so really engaged teams are with we’re seeing effective cultural change is that you see research continue throughout the lifecycle of the project, and perhaps the most important one for us is right at the bottom as GDS has been pushing for the last several years, you know, user research is a team sport. And that actually when we such as occurring it’s tended by all product owners heads of development delivery managers. It’s also worth mentioning that you know we’re talking very much at the research and design stage, but what they what they’re meant to do is form user needs and they should then form part of the success criteria. So the developers should be asking, well, where are the user needs I’m not going to do to address this ticket until I can trace it back to evidence.
So deliverables are a key one because it is a slightly different indicator to some of the other ones we’ve been talking about, but we think it’s an important indicator, because as an as an agency who are often asked to come in and do a discovery or produce some alpha outcomes.
What we’re often being assessed and judged on our deliverables and we’re, we’re keen to make sure that deliverables form part of this cultural change that they don’t just sit on the shelf that they’re fluid, you know, one of the, one of the key, key things that we see with the box ticking is we’ve commissioned you to create 100 user stories and six personas and, and this and that and the other. and it’s the research and the end the work is pointing us in a different direction that having that fluidity to change it. I mean whatever you thought you knew it started discovering the whole point of a discovery programme is to indicate whether that is in fact the case. Yeah. And the teams should really religiously stick to that.
Maybe I just did.
We’ll go through a struggle. And, and then the key one for me as well is that, that there’s so much guidance both out there in terms of blog articles, a gotcha UK other organisations like ourselves who have been through this. So it’s about using that guidance, in a way that makes informed decisions not following it blindly, and also applying it to the, to the challenges and objectives of your particular service. And finally, I missed one really simple indicator for us because that’s what this framework is about is simply the deliverables are visible. Yeah, you walk you walk into a project teams space and you know within seconds how well they’re doing it because you can just tell because the walls are littered with posted notes or personas or service maps or whatever maybe.
So, the ultimate indicator is growth of skills. So one of the things we’ve seen around, and this is around that self sufficiency sustainability is one of the things that we’ve seen is that we often come into services where user centred design says plans don’t exist, and by the end of it, they got a small emerging team, but if they’re not supported. If they’re not, if they’re if they’re not given the chance to grow their skills and to work on the service, then we could see those small emerging teams.
Not flourish. Yeah, I mean, die on the vine is perhaps a harsh phrase but but really if you’re trying to affect successful changes remember not every organisation within government thinks in this kind of way. And so the counterpoint to that, though, is in perhaps the most important piece here, Amanda we’ll come back to the T shirt comment before but for me, we have to acknowledge the power of the product. Because in these kind of cultural change examples. When you are growing and developing these small disciplines perhaps you’ve got 123 user researchers have one content designer within that service. It is the product owner that can really absolutely make or break those smaller discipline sets because let’s face it traditionally within government, there’s probably a lot of developers on the project because the ratio of developers to other disciplines typically is high, but it’s the product owners you have the ability to make those teams succeed. Yes. And it’s so to come back to T shirts, again, we’re not, we’re not suggesting that you go in search of a unicorn or a particular kind of practitioner who can content design do user research do interaction design do visual design, that’s not that’s not what we’re saying here it’s more of making is those deep disciplines those key professionals. You’re recognising emergence, so they’re asking the right questions. Has this been through a content designer or should we get a contract designer to look at this hasn’t been validated by the user. The developers are talking about it.
The moment you get a developer pushback on a ticket within JIRA and say, I’m not working on that yet, because I can’t see the user need or how have we arrived at this point and you know you’re onto a winner. And it’s and it’s all the disciplines, understanding how, how they how they work together how they join up and where their overlap is because if you do get some a couple of a couple of disciplines, with a good overlap you could work in a power of two and speed up some of those kinds of research design or content design and design interaction design phases of work because they’re working together at a velocity loss law.
Okay so responsibilities is one.
This is more of a cultural problem in general like but what we see is successful organisations embracing service design.
There’s a culture of blame, or not my job mentality, or UX is all user research so yours is blocking development.
Is it really, you know, why is that why are you Why are you saying that. And also, you know, because no one’s taking responsibility, they do not get resolved quite quickly so sometimes you do need someone to stand up and kind of take responsibility and make decision.
So I mean, as you can well imagine the kind of complete counterpoint to this is the successful teams you know you walk in and you have a conversation with the team, and you actually struggle to figure out who’s jobholders what.
Yeah. And that, that there is that collective decision making that share problem solving, you still need somebody like the product owner or a you know a decision maker if there’s multiple opinions in a room, but by acknowledging those opinions, you can you can acknowledge that responsibilities are a little bit more fluid.
So, thank you very much. That’s our indicators of the framework john and i are still you know we kind of revisited this after our, our first presentation of it. And the way we talked about it the way we position it is still evolving and. And so we’re, you know, either now or through Twitter keen to hear your opinions of it.
I think what we’re really trying to talk about is to give you some practical tips and we keep using this phrase indicators to help you keep an eye on on past projects that you’re working on. Yeah. And really what we’re trying to get to is that ultimately you’re trying to leave a legacy of user centred cultural change in services that design, but where we see project teams within the public sector really really thriving, particularly if you work within the UK and, you know, with GDS and the framework that we’ve worked. It’s what we really ultimately got to today and hopefully you’ve got this message is this stop trying to pass the assessments just focus on delivering a great service project teams that that are just obsessed with passing assessments that, then they’re not doing a great. They’re not as successful I mean the analogy myself and Amanda have used several times is a bit like when people are at school, and they revise enough to try to pass the exam. Yeah, whereas you get other individuals who actually understand the content that they’re doing so when they pass the exam, they’re just really good at what they do. Yeah.
Thank you. Thank you, sir. Any questions but concert.
Think. Just checking, checking some questions. I think there’s been some connectivity issues but I don’t think there are any questions on the content.
I will take that as a good sign.
But as we’ve left you with both our Twitter handles and obviously we will be continuing to monitor it and we are in a Mensa feed as well. And feel free to reach out after this if you do have any questions. Thanks. Thank you.