https://gds.blog.gov.uk/periscope-agile-design/
Periscope about Design in an Agile Environment
Ben Terrett, Director of Design at GDS answered your questions live on Periscope about 'Design in an Agile Environment' on Tuesday 30 June 2015. This was our first Periscope - find out more about what worked, what didn't, and our top tips over on the Digital Engagement blog.
Transcript
Giles: Hello, Internet. We’re periscoping from Aviation House and we have Ben Terrett. Say, “Hello” to the Internet, Ben Terrett (Laughter).
Ben Terrett: Hello. Can I just say, we’re really sorry this isn’t immediately accessible? We will get a transcript up as soon as possible and we’ll put a video on YouTube with captions. We’re experimenting with different social media formats, and maybe we shouldn’t adopt this as a tool until it’s fully accessible, but we’ll get the captions and the transcript up as soon as possible.
Giles: Brilliant. Ben, can you tell them about how to get questions in if they’re on desktop?
Ben Terrett: Yes, so if you’re watching this on a desktop, you can’t comment, but you can send questions in via the ‘@gdsteam’ Twitter feed.
Giles: Okay. Let’s start off with one question. You said that you were going to be talking today about design in an agile environment, so what does that actually mean?
Ben Terrett: Agile is a software methodology used to build the web. These days people that build the web have designers, and I think those two things, when I talk to other designers or other people in Government, there’s loads of questions about agile, and how to do it, and how do we do it? Then there are loads of questions about design and how do designers work in an agile system? There are lots of questions about that. We don’t have all the answers, but I can talk a bit about how we do it and why we do it, and maybe answer some of the questions that come in from the viewers.
Giles: Okay. Agile started out as a methodology for building software, but we use it for a lot more besides. Can you talk a little bit about using agile for non-software projects, especially agile in design work?
Ben Terrett: Yes, sure. What agile really means is taking a big project, breaking that down into small chunks, doing a few small chunks at a time, and then assessing where you are and whether you can carry on going in the same direction or whether you need to change direction.
It’s really good for things or projects where you’re not sure what the outcome is going to be or you think the outcome might change as you’re going along. It’s less good if what you’re doing is something where you know exactly what the outcome is, and you know exactly where to start and exactly where to finish, and you’ve done it 100 times and you know exactly what you’re doing. Then it’s less useful for things like that, but if you’re working on something that’s flexible and likely to change, agile is a great way of project managing that effectively.
That sort of describes most design projects or most creative projects; they’re inherently flexible and inherently change, whether that’s if you change your mind as you’re going along, or the brief changes, or you get some inspiration that changes what you think. Agile should, in theory, work really… creative people should be agile, basically, so the two things should work really well together.
Giles: We’ve got a question in from Dan. Shout out to the University of Bath massive. Dan says, “How do you handle the tension between agile focus on feature delivery and understanding of the overall design system?” Make sense of that one, Ben (Laughter).
Ben Terrett: Yes, so I think what Dan is referring to there is that often agile is used when we break things down into smaller chunks; you’re breaking those things into small features, and so there can be a tendency for designers to work on each feature one at a time and then nobody looking at the overall picture.
I don’t think… That’s a problem that shouldn’t happen, but that’s not a problem with agile, if you like. That’s somebody somewhere, whether it’s head of design, or the person leading the designer, or the project manager, or someone should have a view of the overall design of the product, and then the features should sit within that. It’s like two different types of gears, if you like, and someone should think that.
If what Dan means is more like the kind of visual system, I think that’s a thing you can kind of do separately or maybe do very quickly at the start – yes, very quickly at the start and go, “Here is a rough kind of visual system that we’re going to start building stuff with and see how that works.” It’s properly a case of slightly different gear to slightly different problems.
Giles: Have you got an example in your mind of a project we’ve worked on where we’ve had that rough thing at the start?
Ben Terrett: Not really. I guess when we started on the beta of GOV.UK, because we had a product that had no brand, really, and needed a new visual look, we had to come up with something quickly to start from, so it wasn’t like an existing product where we could take something we already had and work with that.
The brief we had amongst the team was it just needs to look like it doesn’t come from the West Coast of America, because it’s kind of a uniquely UK website and only really of use to people… You know, UK citizens. Most websites, at the time anyway, looked like they came from the West Coast of America, so we had that as a kind of brief.
The black bar, and the crown, and the white ‘GOV.UK’ just written at the top became really important, because that was the thing users would use to get trust that this was an official Government site, but we did that really quickly and super-light and worked from there.
Giles: Brilliant. We have another question from the Internet here. This is from Jane Fallon, I think. Yes, this one says, “Can you talk about how to bring together end-to-end service design and agile? Which is incremental?”
Ben Terrett: Crikey. Jane, that’s a whole other periscope, I would say (Laughter). I think the… I don’t think the two things are mutually exclusive. The end-to-end service design should be being thought about constantly, and then agile is a way of delivering bits of that, if you see what I mean, so it’s not like you do one and then do the other. You can do… You can think about end-two-end service design in an agile way and then you can deliver it in an agile way. That’s not a brilliant answer, but that’s a big, complicated question, Jane (Laughter).
Giles: Okay. We’ve got another one from Paul. Paul says, “How do you manage scope creep?
Ben Terrett: Good question. I think you have good, strict delivery managers that stop that happening, basically, but you also have a team. Lots of this is Jamie Arnold’s thing: “The unit of delivery is a team.” That’s really how you get agile working well: you have a good team that’s all on board with a clear mission.
That team is focused on what they’re working on, and that team should be aware enough to spot feature creep and say, “That isn’t right,” whether it comes from a designer, or a developer, or a project manager, whatever; we’re all focused on building this thing, but it helps if you have a really good delivery manager who keeps a sharp eye on that stuff.
Giles: Okay. Just a reminder to anyone watching: you can send questions via Twitter; send them to ‘@gdsteam’. We’ve got one here from Richard. Richard says, “With agile, how do you give external clients the fixed cost that they’re looking for?”
Ben Terrett: Yes, that’s a good question. I guess we don’t… If he’s talking about… If Richard comes from more marketing, rather than a government part of the world, we don’t have clients in the same way, so we’ve been working with those people.
I think – and that’s a question that comes up a lot: governance and cost and stuff like that – I’m the wrong person to ask that question, because I’m concerned about the design, not really the… I don’t write the business plans or anything like that, but what I would say is that people in government who haven’t been used to working with agile, and have been used to having very defined bits of governance and things like cost and stuff like that, have found agile gives them more control over their budget and more control over their kind of governance.
There’s a brilliant video that we’ve made with Alan from the Public Guardian, which is on the GDS YouTube page. We can tweet the link afterwards, but that’s a really good video of Alan – who’s a lawyer, I guess – explaining how agile was new to him and how useful he finds it, so I would encourage Richard to watch that video.
Giles: Okay. We’ve got another one here from Luke. Luke says, “What is an appropriate level of involvement from users when considering design?”
Ben Terrett: Loads. You should be user… You should be using user research everywhere; you should be testing all your designs. You should encourage that; you should try and test this along the way.
There come moments where you have to take leaps, particularly at the start of the project. I think you have to… Certain bits of certain things you have to take a punt and test it, but you should welcome and encourage testing – and all sorts of testing, whether it’s formal testing in a lab, or gorilla testing is really easy to do.
Guerilla testing is really helpful for designers, I think, because it’s really quick, and you can do it on paper and you can sketch it, and you can get an idea down really quickly on paper and then run downstairs to the local café, and you only need to talk to two or three people to find out whether that works or not, so that’s a thing to do.
Giles: Can you talk…? Yes, go on, have a swig of water. You haven’t got much. Can you talk a little bit about how we do design here at GDS, because the design team isn’t a team sitting in a room all together, is it?
Ben Terrett: No.
Giles: How does it work?
Ben Terrett: No, so the designers all work in product teams. The delivery managers really… The team, with the delivery manager, decide what the designer’s going to be working on in the sprints and every day. The team comes together once a week and we have a shared mission about what design means to us and what type of design. We have standards and that kind of thing, so we have that kind of shared mission, but day-to-day they’re in the teams. They work in the product teams and it’s the team that decides what those people are working on.
The big difference, I think, when we speak to other people, other design teams working on big web products, is they often have a separate UX team that doesn’t work in individual product teams, and sits elsewhere, and often makes designs or wireframes and then throws them over the wall to a product team or to a dev team.
We don’t do that here; we’ve made a really conscious effort to not do that. We don’t have a UX team, for two reasons: we think design and user research should be two separate… They’re important enough to be two separate roles and you should have both those people on the team.
We also think that user research is the responsibility of everyone in the team. Too often people go, “We’ll do this and we’ll spend six months building it, and then we’ll get two weeks of UX at the end and that will fix the UX.” That won’t, because that has to be everywhere, so we don’t have a UX team and we have designers and user researchers working in the product team.
Giles: Brilliant. Here’s one that I’m going to adjust the question slightly. The question – this is from ‘@tech4X’, who says, “Do you have any book recommendations for junior project managers trying to get into groups with agile?” I’m going to change that slightly: do you have any book recommendations about design as well?
Ben Terrett: I don’t. Well, about design, yes, I do, but about design and agile I don’t. Ben Holliday does. Ben Holliday, if he’s watching this, will tweet books afterwards, I’m sure. If not, I’ll give him a nudge and we’ll re-tweet them from the GDS team account. He has some good ones that he was talking about recently, so I’ll leave that up to him.
We have written a blog post about our design process last year, but it’s the same this year and that’s probably worth us tweeting as well afterwards, because that covers some of… That covers more detail about how we do design and agile stuff.
Giles: Okay. This one, this comes from me: what’s the best thing you’ve learned here from making mistakes in terms of design?
Ben Terrett: I think we have… Giles, that’s a difficult question. Have you got any better questions from the viewers?
Giles: Not at the moment.
Ben Terrett: I think we’ve learnt that design actually works best in those teams. Still in web or software teams, or web agencies, they still use this system of creative director deciding what happens and pushing it down, and we have found that when responsibility and power is pushed down into the teams, the design gets better, and it gets quicker, and better design gets made.
It needs lots of trust from the heads of design or creative directors or whatever, but once you get over that and once you get past your egos, you get better design work and you get a really nice peer-review type trust system happening. That works a lot better.
Giles: One thing that GDS is talking about a lot these days, which is a relatively new concept, is the idea of service design, so can you talk a little bit about what service design means and how we make it happen?
Ben Terrett: Yes, sure. Service design is the design of services, so it’s having a service and thinking about how that service is designed and what’s going to happen in that end-to-end. That sounds like a really obvious thing to say, but too often people don’t think about the service, and they don’t think about the journey a user goes on and where that service starts and finishes; they think about that service in terms of chunks of things we already have, or we have this procurement here, and we have this process here, and we have that there. If we join that up, that’s the service. That’s not what we mean; we mean design the service from end to end.
It seems odd in another expression we use: if you had a company that made chairs, you would design the chairs. There are lots of companies and organisations in government and in the world that make… Their main business is services, but they don’t design the services, which kind of seems crazy. So, we’re doing that; we’re doing that more and more.
They’re doing lots of good stuff across Government; they’ve been doing service design for a while at places like DVLA and they’re doing more of it, thinking about the end-to-end service. Our ‘Government as a Platform’ work, this is essential that we get the services right before we do it. Louise Downe talks about this on our GDS design notes blog, and I’m sure we’ll talk about it more.
Giles: Alright, brilliant. Last one. This is from somebody watching.
Ben Terrett: Good, I’m losing my voice.
Giles: Yes. How do we do user research?
Ben Terrett: How do we do it?
Giles: How do we do it?
Ben Terrett: Crikey, that’s another series of periscopes that I’m sure Leisa Reichelt will do soon. Thanks, Giles. We try and make sure there’s a… We try and make sure there’s a user researcher in every team. We try and make sure that everybody does their – I can’t remember what Leisa calls it, but does their hours, their user research hours.
Giles: Six hours every two weeks.
Ben Terrett: Yes, so you do six hours every two weeks. We try and meet ... It’s two hours every six weeks, actually.
Giles: Yes, one of those; one of those (Laughter).
Ben Terrett: Two hours every six weeks everyone does their user research; everyone gets exposed to user research. That’s really important in organisation, but there’s a user research in every team and user research is embedded into the process and is embedded into the team, so people don’t think you can make something without it ever seeing a user.
The most important thing in GDS has always been – and will always be – the user needs: working out what the user need is and then building around that. If you have that focus, lots of the other questions become easy or kind of go away.
Giles: We’re going to stop now.
Ben Terrett: Great.
Giles: Can you just quickly mention to viewers the thing about the accessibility again?
Ben Terrett: Yes, I will. Yes, thanks, everyone; thanks [to] everyone for watching. This is the first time we’ve done this; is that right, Giles?
Giles: Yes, I believe so.
Ben Terrett: Yes, so it’s a bit of an experiment, so, sorry if it was rubbish. Thanks for watching. Again, we are sorry that… accessibility is really important to us and we’re sorry that periscope isn’t accessible. We will get a transcript up as soon as possible and we’ll get a video on our YouTube page with some captions. Thank you very much. Bye.
