How to Design a User Interface in an Agile World

Paul Boag

On this episode of the Boagworld Show, we look at the challenges of integrating UI design into Agile projects.

This weeks show is sponsored by Balsamiq and FullStory.

Thanks to from Shutterstock for allowing me to use this image.


Paul Boag: On this episode of the Boagworld show we look at the challenges of integrating UI design into Agile projects.

Paul Boag: This season of the podcast is sponsored by Balsamiq and Fullstory.

Paul Boag: Hello, and welcome to the Boagworld Show, the podcast about all aspects of digital design development and strategy, all of that good stuff. My name is Paul Boag and joining me on this week's show is Marcus Lillington, but nobody really cares about that.

Paul Boag: But more significantly, we have Paul Stanton on the show. Now, before Paul says a word I think it's important that we take a moment to realize the significance of this event, because there'll be some people with no clue who Paul Stanton is, other than him being internet-famous, but they won't know him in the context of this podcast. But if you know who Paul Stanton is then you are one of your longest-standing listeners because actually Paul and Ryan used to do this show sometimes.

Paul Boag: Didn't you, Paul?

Paul Stanton: We did.

Paul Stanton: Hello, how are you?

Paul Boag: I'm very, very well. It's good to have you back.

Paul Stanton: It's good to be back.

Paul Boag: You reckon it was like almost a decade since you did that?

Paul Stanton: I'm trying to think. If you want to round up then, yeah, we could probably call it a decade. But I think it's gonna be at least six years [inaudible 00:01:43].

Paul Boag: That's amazing.

Marcus Lillington: I'm trying to remember when we went to the Mill. Because you came to Mill for one of the Christmas dos, didn't you?

Paul Stanton: Yes, yes. One of your … I think we went-

Marcus Lillington: When was that?

Paul Stanton: Was the Mill the big fancy manor house that you basically had the run of the place and we were all very, very drunk?

Marcus Lillington: No, that was Plumber Manor, of which we … Oh, I mentioned the name … Because we're never allowed to go there again. I'm surprised Paul has ever been allowed to go back again.

Paul Boag: Well, I wasn't as disgraceful as the rest of you.

Marcus Lillington: Neither was I, Paul. Went to bed early. Being old and all that sort of thing, but you know …

Paul Boag: I know.

Marcus Lillington: People kept misbehaving. And that was when we were at Plumber Manor. That was lovely.

Marcus Lillington: Now the Mill was where we did Skittles.

Paul Stanton: Oh yes.

Marcus Lillington: And everyone got very, very drunk, again.

Paul Stanton: [crosstalk 00:02:30]

Paul Boag: Oh, I got very drunk that night.

Marcus Lillington: I think that was probably seven years ago. That's my guess.

Paul Stanton: Yeah, I'd say you were about right there.

Paul Boag: We must have first met you on the hundredth Boagworld. Was that-

Paul Stanton: In person, yes.

Paul Boag: Yeah. Yeah.

Paul Stanton: Yeah, that was the first time. We came down to London. I can't remember then name of the pub but I just know it was in … There's a common theme of just general alcohol here going on. But yeah, we met in a pub, did the live show. Then it might have been one of Future of Web App conferences where we kind of volunteered our assistance for the podcast in various roles.

Paul Boag: Yes. Yeah, so you're right, it was, because I remember getting rude messages from you, Ryan, Taylor and Anna Debenham, because I was sitting in the speaker's corner.

Paul Stanton: Speaker's corner.

Paul Boag: And you were mocking me.

Paul Stanton: "Come on, talk to the plebs."

Paul Boag: Exactly.

Paul Stanton: "Come and talk to a loyal audience and give us some time." And you did. To be fair, you extracted yourself and came and had a chat.

Paul Boag: And it was very worthwhile because you became incredibly valuable to the show for a long, long time, you guys. You were producing it and Anna did some transcription and you were … And then of course, when we and Marcus could be arsed, you and Ryan stepped in and did the job for us.

Marcus Lillington: Boagworld North. I remember it well.

Paul Boag: Yeah, I just remember the grief we got for the northern accents. And that's my-

Marcus Lillington: Dare I say it, Paul? You're not sounding so northern these days, and that could be an insult that stabbed you in the heart I'm sure, but you're not.

Paul Stanton: What's the … It's my radio voice.

Paul Boag: Are we not-

Marcus Lillington: Yeah, you're putting it on for me, aren't you? That's what it is.

Paul Boag: I think it's just that you're more used to it now. Because don't forget, Headscape has Chris, who is so northern when he first arrived I couldn't understand him half the time.

Marcus Lillington: He softened a little. He's from the northeast though, so slightly different.

Paul Boag: This is true.

Marcus Lillington: But yes, the first time I was involved with an American client I basically had to translate. We had phone calls and he'd say something and I'd say, "Right, this is what Chris said." No, he's all right now. He's fine. Yes, we've softened his very thick … I want to say Geordie but he's not from Newcastle so that's probably wrong, but northeastern accent, yeah.

Paul Boag: So what are you doing these days? Obviously we talk on Slack and various other places, but for our dear listeners' perspective, where are you working? What kind of work are you doing? Tell us a bit about what's going on in your world.

Paul Stanton: Sure, okay.

Paul Stanton: I work for a company called Jadu. We sell form software, content management, and case management software, mainly to local authorities, central government, higher-education-type … so big, big organizations. And what I do there, which … You do a lot of different things but mainly user experience, user interface design.

Paul Stanton: We've got three main products and a team of three people in a similar [inaudible 00:06:00] and we look after our own individual products and collaborate and work on a thing that's kind of a platform situation.

Paul Boag: Oh, okay.

Paul Boag: So you've been there quite a long time there, haven't you? That's been a few dozen years.

Paul Stanton: Well, I don't say that long but about six now, I think. I think I've just ticked over into six years so …

Paul Boag: Wow.

Paul Stanton: Been there quite a while in the grand scheme of things.

Paul Boag: And then before that … Now, where did you work? It was either higher education or government, wasn't it? One or the other. You were in-house somewhere.

Paul Stanton: That's right. University of Leeds.

Paul Boag: That was it, yeah, yeah.

Paul Boag: So, yeah. Oh, how exciting! It sounds like from what I'd seen of what you've posted and stuff it looks like a good place to work and … Well, it must be if you're there six years now.

Paul Stanton: Yeah, yeah. It's definitely a job and a company that I really enjoy. The challenge is good, and I think if anyone gets comfortable in a place that the work is interesting and you're able to add value and you do good work without playing your own trumpet, but that's the kind of place makes you want to stick around. So yeah, I'm enjoying it still.

Paul Boag: So is it quite a kind of engineer-developer-lead type of organization or do they start with user needs … Tell us a bit about how you work there.

Paul Stanton: Okay. I'd say it could be a mix of either depending on where we are in the product lifecycle and which product we're working on.

Paul Stanton: We try and get as much user need in the early stages as possible, and we've got quite a lot of customers, gathering requirements from them. And that then goes into the churn of figuring out which of those ideas from customers have merit, have value, and that can either be built using the software's features out of the box with just general customization; or if a certain feature that has been requested has value for multiple customers and then we can put in the effort ourselves to build that out or work with the customer to do chargeable work.

Paul Boag: Oh, okay. Fair enough.

Paul Boag: What we're covering on this show … This is where I find out-

Paul Stanton: Oops.

Paul Boag: … you're totally the wrong guest. I presume you guys work in an Agile way.

Paul Stanton: We do.

Paul Boag: Yeah, because otherwise this is really not the show for you, is it? Because we're supposed to be talking about how to design a user interface in an Agile world, is what we're going to get into.

Paul Boag: So you're working on a series of sprints one after another, etc., etc. Do you work in cross-discipline routines? Do you sit alongside developers and other key stakeholders?

Paul Stanton: Yeah. For example, I'm currently working with our forms team and I take responsibility for the user interface side of things. Working in an Agile team, and I'll work with developers, test engineers. And we go through that whole Agile lifecycle of identifying user stories that come up, breaking those down into sprints; and then probably what we'll go into shortly, that process of figuring out where the design part of that fits in through that sprint process.

Paul Boag: Yeah.

Paul Boag: You're office-based, one presumes?

Paul Stanton: Yeah, we're remote-office-based if that makes sense.

Paul Boag: Eh?

Paul Stanton: Our UX team is based in Leeds. There's three of us in this office. The main Jadu engineering side of things is in Leicester, so not too far away but a good hundred miles. And we have people in the States, people in Australia, as well as remote developers everywhere. So we're kind of a mixture of both: general office-based company but also with remote work experience.

Paul Boag: Wow. That's quite a tricky mix, having people all over the … especially in Australia. Timezones must be a nightmare.

Paul Stanton: It can be, yeah. I think Australia's not really on the develop-y engineering side.

Paul Boag: Oh, okay.

Paul Stanton: Yeah, most of that is still within the UK.

Paul Boag: Oh, well, at least that's something. That makes it a bit easier. There's not that big a timezone between you and Leicester is there, really, I guess. Maybe you and down in Dorset, that's a long way. I couldn't work with you very easily because of timezones. It's amazing that we can even talk to one another, really, without there being lag on the line through the enormous distance that it is.

Paul Stanton: Yeah, just the language barrier.

Paul Boag: Yeah, just the language barrier.

Paul Boag: Right, okay.

Paul Boag: As you may have gathered, dear listener, we're talking about user interface design in an Agile world today. It's the last in the season. It feels right that we have Paul on for the last in the season.

Paul Stanton: Yeah.

Paul Boag: We're gonna look into that as a subject. We're gonna talk a little bit at the end of the show about what's coming up for the next season.

Paul Boag: But before we do all do that I first of all talk just a little bit about Balsamiq, who have supported the entire season.

Paul Boag: Now, I have to ask a question. And, Paul, if you answer this question wrong you're gonna make a liar out of me.

Paul Stanton: I wonder what will this question [inaudible 00:11:44] be.

Paul Boag: I was joking with the guys at Balsamiq about the fact that every single guest that has been on this season has used Balsamiq at some point. And then I realized that actually I still had one episode to record. So please tell me that you have used Balsamiq in the past, otherwise you're gonna make a liar out of me.

Paul Stanton: Do you mean just on salads or something else?

Paul Boag: Oh, you're so funny.

Paul Stanton: No. Yes, we absolutely use Balsamiq. It's my favorite wire-framing tool. I am not being paid to say this. And working as a remote team, we use their Mockups To Go product, that's the cloud version, so we can quite easily quickly throw stuff together, send a link over Slack or whatever to the team in Leicester, and work from there. So yeah, definitely [inaudible 00:12:42].

Paul Boag: Cool. See? That's brilliant.

Marcus Lillington: Actually uses it now, Paul. That's even better.

Paul Boag: He actually … Yeah, I noticed I've worded it very carefully over the season just in case people didn't use it today. We've had a hundred percent who've used this. And actually, apparently they've become so addicted to hearing how everybody has used their product that they're gonna support us with next season as well-

Marcus Lillington: Yay!

Paul Boag: … which is great. So hopefully I get the hundred percent run from next season of people saying, "Oh, yeah, yeah, I've used Balsamiq," otherwise they might stop and we wouldn't want that.

Paul Boag: No, it's an amazing product. I almost don't need to say anything else, do I? Paul's kind of said it for me.

Paul Boag: Do you know? What I want to do is I just want to say thank you to them for their support of this season. They are an amazing group of people with a real desire to improve the digital design world. And actually, the way that this came about is they contacted me out of the blue and asked how they could help me. Right? So it wasn't, "Can we get some sponsorship for the show?" They just literally said, "What can we do to improve what you're doing? Because we think the stuff you're putting out there is awesome." That doesn't happen very often. And actually, we've been talking about all other kinds of plans that are things we can potentially do.

Paul Boag: And the fact that every single on the season has used Balsamiq shows how quite embedded they are. It really is the perfect tool for creating low-fidelity wire-frames. You're just not gonna find better.

Paul Boag: So give it a go. You can get 30 days of their Balsamiq Cloud platform, which Paul's talking about, for 30 days. No, you can get a 30-day trial for free. And then you can get three months for free if you decide to sign up using the code "BALSAMIQBOAG" along with your billing information to create a free account.

Paul Boag: So there we go. That is Balsamiq. Thank you very much guys for supporting the season. It's much appreciated.

Paul Boag: Let's talk about Agile, because I've … Agile is a software development methodology, right? So you can a hundred percent understand why a company like yours, Paul, adopts Agile. But it doesn't always feel particularly and naturally a good fit with a user interface design process. Is that fair to say? What challenges have you experienced from working in an Agile kind of way?

Paul Stanton: I think it is really fair to say, and I don't know if people wanted a contrarian view, but I do agree that sometimes it's really difficult to work on something like design or user interface design in Agile.

Paul Stanton: Agile's really for software development. Once you get to the basics of it, because you can have complex Agile and you can have simple Agile, but even just the basics of it makes absolute sense for anyone doing software development: break stuff down into as small a chunk as you can be. You have usually big features that you're gonna develop, you break those down into smaller pieces that can be … figure out how much you can fit into a sprint, which is just a period of time. It can be like one or two weeks usually. And then after a few sprints your team's got its rhythm, that they know how many points, which is just this arbitrary measurement of how complex a story is … So something really simple like a text change or a color change might be one point. And then there's different ways assign points. There's Fibonacci scales; or even t-shirt sizing, like small, medium, and large.

Paul Boag: What?

Paul Stanton: Once your team's got this knowledge of how many points it delivers usually in a sprint that makes the next chunks of work so much easier because your team can then break the stories down and say, "Right, that's gonna be 10 points. We know we can do that. We've got space in this sprint to put it."

Paul Stanton: But when it comes to the design side, which is where I operate almost exclusively now, I find it really hard to limit my own thought process to kind of sprint-able work. Someone comes and says, "Right, we need to design something for this." My brain doesn't work in: "Right, how can I make this as small as it can be?" at the start. I've got to follow that design process all the way through to the end to design my solution and then break it down. So that doesn't really fit in a way … When you're starting a new sprint you have your sprint planning meeting. I don't know how long something's gonna take me to design because I've not seen the problem yet, which is more … I think that issue is more common in design than it is with development, where you're working a lot of with known knowns, if that makes any sense.

Paul Boag: Yeah.

Marcus Lillington: Yeah.

Paul Stanton: My brain doesn't work immediately in an Agile way. I've got to solve the problem and then break it down.

Marcus Lillington: I was hoping you were going to come up with the perfect answer for me, Paul, because we kind of struggled over the years with, "Should be doing more Agile development," but we do a lot of design work which tends, as we're discussing now … It feels like with the Agile process you don't get enough time to spend on the design aspects, so we tend to do that in more of a waterfall way, whereas there are some aspects of projects that we'd like to do in an Agile way but we can never organize the time between both. So I was hoping you'd come up with a great response. Maybe you will.

Paul Stanton: It's almost like your designers need to run ahead and scout the problems out. If you've got a specific feature you're gonna work on, say, two or three sprints down the line, your design team needs to be working on that in advance.

Paul Stanton: Because the biggest challenge we've had in the past, but we don't do it as much now, but is your product owner, that's the role within an Agile company, the role that decides what's going to be worked on and when, the product owner having the estimation done purely on engineering effort and then coming, "Right, well, we need a UI for this." And [inaudible 00:19:22], "We can do this and this and this." And you end up designing a really good solution, but the engineering part of it is lesser sometimes so it kind of blocked out so many story points for it. And you've [inaudible 00:19:40] more expensive, we need more … more. [inaudible 00:19:43] design something a bit fancier than you envision.

Paul Boag: Yeah. So that they end up having to use more points than they'd anticipated because you hadn't been able to fully flesh out the idea yet.

Paul Boag: And, Marcus, to make things even worse, in some ways Paul's in a better position than you guys are because Paul is working on an established product that has its overall visual identity already in place, while every time you start on a project you're starting from pretty much ground zero, where there's no design done up front.

Marcus Lillington: Yeah. Effectively what I think Paul was saying there was you've gotta separate … So designers work on their design stuff, preferably in front of the engineers, and they're separated. But I always thought the idea behind Agile was that everybody works together-

Paul Boag: Yeah.

Marcus Lillington: … all minds together.

Marcus Lillington: So yeah, I'm still none the wiser, really.

Paul Boag: Well, you're entirely right. The idea of Agile is that you do work collaboratively across disciplines. And that's actually one of the things I like most about Agile from a more … If I'm wearing my digital transformation / organizational governance perspective, you want a designer and developer to be working side by side on a project. But it is tricky. It's tricky to get that balance.

Paul Boag: Effectively, what it sounds like Paul is describing … Correct me if I'm wrong Paul, but you're talking about almost like a "Sprint Zero." Is that the way that you're looking at things?

Paul Stanton: Kind of. Sprint zero's usually a way of before a project kicks off you have a set amount of time where you set up infrastructure, you do some of the getting the team ready for actually starting work, whereas … I work on longterm projects. I've been working on the same product for months if not years on end. I appreciate some of your listeners will be working on and maybe yourselves are working on a project that runs for a few months and then you're on to the next project-

Paul Boag: Yeah.

Marcus Lillington: Yeah.

Paul Stanton: … where I work a software platform. We do the same thing but for features, where we work on a big feature, like we just released a brand new version of our form builder, which is [inaudible 00:22:04] very, very complex engineering thing.

Paul Stanton: So a sprint zero wouldn't work … We wouldn't be able to do all that big design at the start of the project, because one of the good things about Agile is you're constantly iterating and changing. It's almost as if for each feature, you've got a mini-sprint-zero for each feature.

Paul Stanton: And I'm not saying this is the solution or that everybody should do this, but the way we work is our [inaudible 00:22:36] or like myself will almost run ahead, we get chats with the engineers that are gonna be working on the feature, try and get an early sense of what is required from a development standpoint; speaking to users, getting an idea of what they expect of the feature; and then designing the vision almost. Not a set document, because it's gonna change. [inaudible 00:23:01] if you went to your design so early on you're gonna have problems. But, basically, to set the initial expectation of [inaudible 00:23:08] from a user interface standpoint: "This is what we expect the finished project to be like."

Paul Stanton: Then you take that into the sprint planning, you break it down, see what's achievable in how many sprints … At that point, like you were saying earlier, Marcus, we would work side-by-side with developers and engineers to do our part. If there's any new design components that need building out we would take care of that. And hopefully and in an ideal world we kind of shepherd our vision through the development process and make sure it comes out the other side intact, which doesn't always work. Things change. But that's the utopian ideal of the way that we do it anyway.

Marcus Lillington: And you'd go into-

Paul Boag: So … No, go on, Marcus.

Marcus Lillington: I was saying you'd go into that phase of the project with a kind of toolkit of design stuff that you can apply. You've already done design work to give you a library of things you can work from. Is that the way it works?

Paul Stanton: Yes. We have that real benefit of working on a single-product platform.

Paul Stanton: We have our design system called Pulsar, which sets all the consistent user interface elements, the templating languages, so we can really quickly put together even static interfaces, whereas we're not working on different products every time and we're not having to start from scratch like maybe yourselves are. So a lot of that work [inaudible 00:24:50] done, and there's a real benefit that comes out of that for working with developers because they understand that common language and that visual framework, so that we can scribble something on a piece of paper, or using Balsamiq, and they know now which components they need from our design system that can achieve that. And then our focus comes on the new stuff that we need to build out.

Marcus Lillington: Okay.

Paul Boag: So your starting point, when you talk about you kind of run ahead and you put together a rough vision but recognizing it will change, that's where you're doing a little bit of wire-framing or prototyping either in pen or paper or Balsamiq or something along those lines. Is that what you mean by delivering a bit upfront? "What's the deliverable of that?" I guess is what I'm asking.

Paul Stanton: It's different every time but for most cases we sketch out the user journeys.

Paul Boag: Ah, okay.

Paul Stanton: We're working on software, so usually a user has come to [inaudible 00:25:53] achieve something or to perform a task.

Paul Stanton: So where we do step-by-step screenshots, not in any massive fidelity but just: "Right, this is the first view," and then they click on this button and go here and then it might [inaudible 00:26:10]. And that's where we need to think in advance, is to think of all those different variations on this journey. "Right, what happens when they try and delete something? What messages do they get? What happens if something goes wrong? What error messages are shown?" and we have to figure that out as much as we can in advance.

Paul Stanton: But things come up during development, and then we have to think on our feet and go back and iterate and come up with new solutions if we didn't get it quite right the first time.

Paul Stanton: So that's why we don't work in any [inaudible 00:26:43] really high-fidelity. It's all throwaway until we get to a point where it's not throwaway any more and you're actually changing the final interface.

Paul Boag: Silly question, maybe, but is there any value to Agile from your point of view as a designer or are you just doing it to accommodate the development team?

Paul Stanton: I think it is really valuable. You're working alongside your developers and your tech [inaudible 00:27:16]. Working within an Agile way you've got this shared vocabulary of you know what a user story is or what a feature is and how it's broken down. That's just the same as design work as it is for development work and, all right [inaudible 00:27:34] my designer brain, I'm not generalize on this issue. Not everyone's the same way, but my designer brain I have to think through a problem that then the point is that I can chop it up and design and try and think, "Right, what needs to happen first? What's gonna … Right, I've designed this really complex interaction. That's gonna need more engineering effort than others." So it puts everybody in a similar mindset and you know how you're gonna work going forward, really.

Paul Stanton: So yeah, it is valuable. Just in generally the Agile way of working, [inaudible 00:28:11] anyone else but I use it out of work, if that sounds too geeky. But if I've got a load of stuff to do around the house, the really simple Agile way of working like Kanban, which is your list of things to do, which is your backlog and your list of things you're doing, which should be as short as possible, and your list of things you've done. And you can achieve so much in a week, and if you've got three or four week off work and you've got all these jobs to do, you kind of know that, "That's a big job and that's a small job and, right, I've got an hour for lunch, I can probably do a small one. Small job, not a big job." And I use those strategies, and it's not just in a normal way of working as well.

Paul Boag: Yeah. No, makes a lot of sense.

Paul Boag: I mean obviously Agile is a lot more than just those kind of sprint blocks as well. Are there other aspects of Agile that work particular well for you as a designer?

Paul Stanton: There's the general organization part of it too. You have morning stand-ups where you can get a sense of what everyone in the team's going to be doing on that day or what they did yesterday, which is good especially as a remote team member because we dial-in with video conferencing software. So you're aware of what your team's working on. [inaudible 00:29:31] they're all working on non-design stuff generally, and even knowing what the test engineers are gonna test, you're aware that they're gonna test something that you've worked on so you can be aware of "[inaudible 00:29:40] issues come up I can [inaudible 00:29:44] ticketing system," or whatever we [inaudible 00:29:46] that.

Paul Stanton: And then there's retrospectives which happen at the end of either a sprint or a series of sprints, where you can feed back to the rest of the team anything you've struggled with, get an awareness of the work coming up, which goes back to how I said that we work, which are [inaudible 00:30:03] in advance. So we can identify anything that needs our attention and speak to the team, or we're all in the same room whether [inaudible 00:30:13] virtually or not.

Paul Boag: Yeah.

Paul Boag: I often think there are many aspects to Agile that we … Whenever you think about Agile or if ever you present Agile to external people you always think about those sprints. But actually there's so many different aspects, little bits within that Agile working methodology that is beneficial, even if you don't do the sprints. Things like a daily stand-up is a great example of that. Things like having a more collaborative approach in the way that you work. These are all good valuable things anyway.

Paul Stanton: Yeah. Anyone's who done Agile for a while, especially within a company, like [inaudible 00:30:55] or a slightly larger company, [inaudible 00:30:57] probably knows and will probably nod and say you tend to find your own way of doing Agile.

Paul Stanton: We had a large project a few years back where we kind of went and changed the whole company to work in this way, and we all went off and got scrum master certification, [inaudible 00:31:17] I'm not certified anymore, so I'm an unlicensed scrum master now.

Paul Boag: Is that like being an unlicensed dentist? You really want to avoid them.

Paul Stanton: Yeah, you kind of hang around in shady spots and back alleys and do organized scrums for people and stuff like that.

Paul Stanton: I've found any company kind of finds their own way and picks the best bits of it and the things that work for them and not really the [inaudible 00:31:46]. Never seen a company that does it as rigid as you probably learn it, if that makes sense.

Paul Boag: Yeah. Yeah. It's like anything, that you need to be pragmatic about it and you need to adapt it for your own situation.

Paul Boag: Talking of which, I've taken … Because of course a lot of the projects that I'm involved with are big redesigns of an existing website and oftentimes the traditional Agile … I don't even know if I can call this, what I'm about to say, Agile or not. But the traditional Agile process basically, as you've been talking about, takes a slice of functionality within a site. We're gonna introduce a new checkout process, or a new order delivery page, or whatever else. You take vertical slices in the experience where you then do design on that part of the experience, you do the development, etc., the content, on all those things.

Paul Boag: Now that works very well when you're looking at a product like you're describing where it's a well-established product, but if you're doing something that's a redesign from scratch then I don't think that fits as well for all the reasons that we've just said.

Paul Boag: So one of the things that I've been playing with which seems to work really well is, instead of taking vertical slices out of a site, is instead to work in terms of fidelity. So you will actually do a series of sprints, and instead of saying in this sprint, "We're gonna deliver this feature, this feature, and this feature," you say, "In this sprint we're gonna deliver across the entire site to a certain level of fidelity." It might be in your first sprint all you're doing is establishing the information architecture for the entire site. In the second sprint you might be adding some typography and some design and a few questions. The third sprint you might start adding a little bit of layout, and you kind of divide in that kind of way. You're working horizontally across the entire thing in increasing fidelity.

Paul Boag: Am I only the person in the world that does that? I don't know. Is that something you've ever heard of before or have you tried anything like that?

Paul Stanton: I can't say that's … No, it's definitely not how we work. That classic image is in there where you've got the skateboard at the start, but then more [inaudible 00:34:35] bicycle and then a motorbike. And I know that's a contentious image. People will argue that's not how things work. But it's possibly, depending on the project you're working on, that could be a valid way of doing it.

Paul Boag: Certainly … Marcus, going back to the agency side of things, that works a little bit better, doesn't it? Because you're delivering entire websites from beginning to end.

Marcus Lillington: Absolutely, yeah.

Paul Boag: And of course that means you've got something after every sprint to show a client and engage the client with, and something tangible to test at every single step along the way, which I quite like as well.

Marcus Lillington: Yeah, that does sound like a good way of working.

Marcus Lillington: I think it's … My problem, and I'm gonna repeat myself here, is, because we're working on multiple projects all at the same time, to get everyone working on the same thing for a sprint or however long that might be is really hard to organize because obviously some people will be free more quickly to do something else than the other person might be. But we do approach our projects in a … "Let's work on the [inaudible 00:35:49]," and we'll be working on the aesthetics, all those kind of things separately. But to do it in a sprint kind of way, we just haven't found a way we can manage.

Marcus Lillington: But I do love the idea of everyone sitting around the table doing it together. We will do that at the end of projects, we'll get clients in for final snagging and all that kind of thing. We find that doing that in a kind of mini-sprint works once there's everything in place. But the early stages we struggle with.

Paul Boag: I struggle with that a little bit, you describing that situation, because I never understood … I look at agencies that do work in an Agile way and they simply just take on one client at a time. Obviously they move through those clients much, much faster because they've got the entire team concentrating on the thing at the same time. Why doesn't that work in practice, from your point of view?

Marcus Lillington: Yeah, because I'm not sure that works that well for them either because clients may not be able to work at the same speed that you can. That's a huge issue with finishing projects, because the people who've hired you, they've got another job, they've got another set of jobs that they're doing. So to get them round the table for a month or whatever would be impossible.

Paul Boag: Yeah.

Marcus Lillington: "Impossible"s too strong, but yeah.

Paul Stanton: How do you work with your clients? Do you embed them into your team as … Do you bring them onboard with the Agile journey or do you …

Marcus Lillington: We don't work in an Agile way, that's what I'm basically saying. We certainly take on aspects of it, as Paul mentioned, but the idea of working solely on one thing for a week or two weeks we haven't been able … It just doesn't work from a management point of view or managing-our-people point of view. Maybe it could do. Maybe I'm just being lazy.

Marcus Lillington: But it just seems, as I said, for us to be able to deliver on multiple projects … because, I don't know, we're probably supporting 20 or 30 existing sites that things will just pop up out of nowhere, and that's probably sometimes a few hours' work. So how do you fit that in … I'm going off in various tangents here, obviously but-

Paul Boag: No, no, that's fine.

Marcus Lillington: How do you fit that into a strict Agile regime, if you like? You can't. I guess you'd have to have, like, maybe for a week, a month, we're just gonna do support. But that's not quick enough for some clients.

Paul Boag: Or you have a separate person or people dedicated to those little things as they pop up.

Marcus Lillington: Yeah. And we're not big enough to do that. I think that's part of the problem. We have eight full-time people. We have to be able to flit from one thing to the other for it to work effectively.

Marcus Lillington: But the reason why I'm saying it would be great if we could find a way to maybe work in a more Agile way is because I know that some of the guys would really like us to do that. That's why I'm asking these questions.

Paul Boag: The point about the client I think is a really good one as well because you are right, a lot of the clients that you encounter are juggling 28 different things all at once. That is, for me, one of the fundamental problems that I see with Agile.

Paul Boag: And by the way, I'm coming across as a bit negative about Agile, which I'm not at all. I'm actually very positive. I think it's great.

Paul Boag: One of the challenges I see around it is that you get an IT department somewhere within an organization that says, "Hey, we're gonna go Agile." And they work in Agile but none of the other departments around them does. It's the same story where your agency works in Agile and the client can't internally within their organization. What you end up with this kind of Agile-waterfall hybrid where the client is behaving in a waterfall way, you as a development agency are Agile, and it all just gets a bit messy as these cultures bang into one another.

Paul Boag: And I think you're right, Marcus. I think ultimately you've got to put the client's needs first, and if it's not a natural fit for them it doesn't make sense to work in that way. [crosstalk 00:40:14]

Marcus Lillington: I think it's … Yeah, for some it'll be brilliant. For others, less so. But I also think, as you said, we tend to work on big redesign projects where you're starting from scratch, and I don't think they fit as well as: "We've got this thing and we want to change a part of it." That seems to fit a lot better in the Agile way of working as opposed to: "Look, we're starting from scratch. Where do we take this thing?" I think that's part of the problem.

Paul Boag: I fully recognize that Agile works absolutely brilliantly from a developer point of view. It makes a lot of sense. Totally get it.

Paul Boag: Do you think, Paul, from your point of view … How can we as designers support developers better in their desire to work in an Agile way? Does that make sense?

Paul Stanton: Yeah. [inaudible 00:41:10] support them [inaudible 00:41:11].

Paul Stanton: By the very nature, once you're working in this way and you're able to … Even if you're doing bigger designs or setting these visions out, having that ability to then be pragmatic and break it down into achievable chunks is gonna be the key. Because the developers, they will want to work within the sprints and your product owner wants to keep the pace and the velocity [inaudible 00:41:42] and deliver things sprint-on-sprint.

Paul Stanton: And this is really hard, but seeing your own solution to a design get boiled down into the minimum viable product, [crosstalk 00:41:59] this trap of version one, kind of where you've coined it. Because the first thing that is gonna have to be delivered is that basic subset of features. Then it's not falling into the trap of only ever delivering that basic set of features, because you've set the design, you've set the vision.

Paul Stanton: And I think this probably a cultural thing in where design fits in your organization, how much importance it's given, is to make sure that the feature is delivered eventually over however many sprints it takes, to [inaudible 00:42:35] the original vision as long as that [inaudible 00:42:38] fits. We've done it as much as we can, and sometimes we've not been able to do it, and that's really hard. But that comes with the mutual respect, I guess, between [inaudible 00:42:50] if [inaudible 00:42:50] your design team is separate from your development team, having this shared vision and everyone being on board with it and then working towards it.

Paul Boag: Yeah, because that is the danger, isn't it? Is that you compromise … The problem with minimal viable products, and again I'm a great fan and I think that should be the way that we operate, is minimal viable products only work if you do return to stuff and you don't go, "Well, that's good enough. Let's move onto the next thing." That, yeah, that's a challenging one. Totally get that.

Paul Stanton: MVP is almost never the right thing for the user [inaudible 00:43:31] in my experience.

Paul Boag: No.

Paul Stanton: It depends on who you're building this for. Is it to keep your user happy or to … and this is a whole other conversation … but to keep your development team and the engineering costs as low as possible; or either you're doing the best thing for the user.

Paul Boag: In theory an MVP should work in the sense that it's not making presumptions about what the user wants. You're putting stuff in front of them and seeing how they respond. But that requires a very good working relationship and a very close working relationship between the audience you're trying to reach in the organization producing it in order to get that feedback loop happening, where the users know that they're looking at an MVP and they can express their shortcomings and know those shortcomings are gonna be addressed.

Paul Boag: The problem is is often people deliver an MVP and then the users come back and say, "Well, I don't like this, this, and this," and nothing's ever done about it.

Paul Stanton: Yeah, you need a very good product owner to protect the vision of the product going forward and to know what ultimately needs to be delivered, and maintain that relationship with the client so that the client doesn't think, "Well, you delivered that stuff weeks ago. Why are we doing it again?" So [inaudible 00:44:55] explain [inaudible 00:44:54] we are [inaudible 00:44:54] making it better. "Do I have to pay for that?"

Paul Boag: Yeah, exactly. Yeah, I totally get it.

Paul Boag: All right. Well, there's a little bit about Agile and some of the challenges around it.

Paul Boag: I think the lesson that I would try and leave people with in terms of all that is feel free to pick and choose what you use and what you don't out of Agile. There's a lot of people out there that are very opinionated about the way that it should be done because they found success in doing it that way themselves. But every organization and every situation is different and you need to come up with the way that's best for you.

Paul Boag: Let's talk about second sponsor before we wrap up this week's show.

Paul Boag: Again, they've supported us through the whole season and I'm hugely grateful to them for that. That's Fullstory, which in my opinion is simply the best session recorder out there, and the one that I use personally on my own site.

Paul Boag: I have honestly learnt so much from using Fullstory on my own site. For example, I've been using Fullstory very recently, and as a result of what I have learnt through looking at the session recorders, running them, analyzing the results, etc., I've managed to reduce the bounce rate on my blog rate by over 5%, which I'm really, really happy with. Because blogs inevitably have a very high bounce rate, because people come and read one article and then go on. But by looking at their behavior of how they moved around the site, how they scrolled down a page, all those kinds of things, I was able to discover where to place certain calls to action that moved them on. And so I'm really chuffed with using it personally and I'm sure that you will be too.

Paul Boag: It's so easy to use. An incredibly powerful search. And if you're like me you're a … I'm a very visual person. I struggle with analytics platforms, and I struggle to find what it is I want to know and to be able to visualize what I'm looking at, so something like a session recorder where I can just type in what I want to know … It returns a load of sessions back to me. I can watch those sessions. I can look at heat maps, etc. It's been brilliant, absolutely brilliant.

Paul Boag: So anyway, you can sign up today and get a month of their pro account for free. No need to enter a credit card or anything like that. If you get to the end of your free month and you think, "Yeah, it's good, but I probably can't justifying paying for it across the whole site," then you can continue to use it for free up to a thousand sessions per month, which is obviously still really useful for looking and analyzing certain pages. Although obviously pay for the pro version because otherwise Fullstory'd go out of business and that would be bad. Don't just use the free program, kids.

Paul Boag: You can find out more about all of that by going to and sign up there.

Paul Boag: All right. As always, I want to leave you with a bit of further reading to check out on all of this kind of stuff.

Paul Boag: Really, the further reading for this week isn't exclusive to Agile but it's kind of further reading on the season as a whole. That said, mind, the first one does kind of touch a little bit on what we've been talking about. Remember, I was talking about that user-experience-focused approach to Agile where you take it in fidelity? That's something I've written about before, and you can read about that by going to

Paul Boag: The other thing that I wanted to share with you on a more generic sense of user interface design, which we've been talking about over the whole season … There's one article that I wrote a while back that is a really useful resources, which are ten principles I've learnt about user interface design that have been learnt through painful mistakes, and you can check that one out by going to

Paul Boag: And then also I wanted to end by recommending a book, a really, really good book called the Universal Principles of Design, which is just this big-arse book that you can flip through that includes all of the different principles that we use, from things like scarcity, to structure, to the uncertainty principle; all these kinds of … There's bloomin' hundreds of them, there are, and they're all explained and you can see how you can apply them to your site. So if that book sounds of interest you can go to

Paul Boag: All right. So that about wraps us up for this season, actually.

Paul Boag: What is the last joke for the season, Marcus? I'm sorry, Paul, we're still doing jokes all these years later.

Paul Stanton: Surprised he's still got any left to tell.

Marcus Lillington: Yes, please send me some more, people.

Marcus Lillington: I thought I'd finish the season off with a limerick from Chris [Florence 00:50:17].

Marcus Lillington: There once was a man from Japan,

Marcus Lillington: whose limericks never would scan.

Marcus Lillington: When he was asked why,

Marcus Lillington: he gave a thoughtful reply:

Marcus Lillington: "Well, I tried to fit as many syllables in the last line as I can possibly can."

Paul Boag: There we go. That's [crosstalk 00:50:36] quality. [crosstalk 00:50:37]

Paul Stanton: [crosstalk 00:50:36] not got better [crosstalk 00:50:36]

Paul Boag: No, they haven't.

Marcus Lillington: No, no, no, no. Of course not.

Paul Boag: No.

Marcus Lillington: It would be wrong to do good jokes.

Paul Boag: So if you want to see of the jokes Marcus has rejected, you can see them by going to Join our Slack channel, and there is a channel dedicated to bad jokes. There are some in there that really are just too good for the podcast and so have been rejected, but it's still worth quite a giggle. Oh, and we also talk about UX and stuff, but that isn't why anybody really goes.

Paul Boag: So, Paul, where can people find out a little bit more about you and what you up to? And also, obviously, the company you work for.

Paul Stanton: Okay. I'm on Twitter mainly, @stanton on Twitter. I'd say the next best place to find us would be [inaudible 00:51:26] the product team, product design team here have a Medium blog-

Paul Boag: Oh, cool.

Paul Stanton:, which we are trying to write more on. So if more people start reading then that will spur us to write more things.

Paul Boag: Sorry, I didn't quite catch what that URL was.

Paul Stanton: "pulsar." P-U-L-S-A-R.

Paul Boag: Excellent, thank you. Ah, your pattern library thingy is called Pulsar, isn't it? That's it.

Paul Stanton: It is, yeah. We've tried to write more about design systems, and more recently some of the problems that we have solved in terms of how and why we design certain things for what is effectively enterprise-level software.

Paul Boag: Cool. Oh, that's sounds really interesting, actually. Yeah, get your arse into gear. Write more.

Paul Stanton: And of course, which is the company I work for.

Paul Boag: Yes. Wonderful.

Paul Boag: Okay, so that is it for this season. We're gonna be taking a break for a little bit because we don't have Paul and Ryan to fill in when we get lazy now. We're gonna take a break for a few weeks. We're gonna kick off the new season on the 10th of May. Cor, that's over a month. That's outrageous, a long time to take a break.

Paul Boag: In the next season we're gonna be looking at building the UX culture in your organization. What we're gonna be doing is we're gonna be interviewing a load of different people from lots of different industries and backgrounds who are attempting to build a UX culture in their organization. It's gonna range from some companies that have got quite a way to go and are facing a bit of an uphill battle all the way through to, for example, I think we're probably gonna have somebody from Uber on talking about … who obviously are a very user-centric culture and that's built into their DNA. So we've got loads of different guests from loads of different sectors. We've got somebody from Virgin Atlantic coming on; but equally we've got people from the higher education sector, enterprise, B2B, you name it.

Paul Boag: And actually, I'll probably be asking almost the same questions every week. But I think the difference in cultures and environments that they're in could lead to a really good season. And best of all, I only need to prepare the questions once, which is good.

Marcus Lillington: Yes.

Paul Boag: Not that I-

Marcus Lillington: Excellent organizational skills there, Paul.

Paul Boag: I thought so. I was impressed by that cunning plan.

Paul Boag: So I think it's gonna be a good one. I'm looking forward to it. That kicks off on the 10th of May. But until then, thank you very much, Paul, for joining us on the last show of the season.

Marcus Lillington: Indeed.

Paul Stanton: [inaudible 00:54:13] for having me.

Paul Boag: Oh, a pleasure as always. You're welcome any time.

Paul Boag: And I suppose thank you as well, Marcus, for sticking with me.

Marcus Lillington: Very kind of you, Paul. It's been a pleasure as always.

Paul Boag: I don't think I've ever thanked you for being on the show.

Marcus Lillington: No, I think you have. Once.

Paul Boag: Have I?

Marcus Lillington: In 500 episodes or whatever it is.

Paul Boag: Yeah. That sounds about right.

Marcus Lillington: I think it could well be 500 episodes now. I say this every-

Paul Boag: Oh, it's well over that now.

Marcus Lillington: I don't know. I need to do some maths. I just think it is. I'll be saying it's a thousand in a couple of seasons' time.

Paul Boag: Yeah. Well we had over 300 the original, didn't we? Before we then took-

Marcus Lillington: Not quite there. 240 I think it was.

Paul Boag: Ah.

Marcus Lillington: But then 20 seasons since.

Paul Boag: Yeah. No, I've got the actual figure in front of me here. We're not hit the 500 yet. It's 459 episodes.

Marcus Lillington: Wow. That's a lot.

Paul Boag: It is a lot, isn't it? But ironically the other podcast that I do, the Digital Insights one, which is just my blog posts, 532 of those.

Marcus Lillington: Yeah, but they're only weenie.

Paul Boag: But they are much shorter.

Marcus Lillington: Little tiny ones.

Paul Boag: I know. It's quality, not quantity, Marcus.

Marcus Lillington: Yeah, absolutely. That's why we've done fewer of the Boagworld ones.

Paul Boag: Ah, cunning. I like your logic.

Paul Boag: No, I do think you need thanking simply because the show was so shit before you joined it. I can't argue with that, can I, really?

Marcus Lillington: For those two episodes, yeah.

Paul Boag: Was it only two? No, it was a bit more than that, wasn't it?

Marcus Lillington: I can't … Two or three.

Paul Boag: Oh, okay. Anyway-

Marcus Lillington: You said, "Help."

Paul Boag: Oh, right. "Help! This is painful. Why am I doing this?"

Paul Boag: There we go. That's a really rambling, boring silly end to season, isn't it, really? We're kind of just petering off at this point.

Paul Boag: Thank you for listening and goodbye.

Paul Stanton: Goodbye.