How to Make It as an Interaction Designer

Paul Boag

This week on the Boagworld Show we are joined by interaction designer Adam Silver whose career has taken him from Tesco and the BBC to the UK Government.

This week’s show is sponsored by The Digital Project Manager School and Optimal Workshop.


Paul Boag: This week on the Boagworld Show, we're joined by interaction designer Adam Silver, whose career has taken him from Tescos and the BBC to the UK government.

This week show is sponsored by Optimal Workshop and the Project Manager School.

Hello, welcome to the Boagworld Show, the podcast about all aspects of digital design, development and strategy. My name is Paul Boag. Joining me on this week's show is obviously Marcus Lillington. Hello, Marcus.

Marcus Lillington: Hello, Paul. How-

Paul Boag: You purchased Wave. You can forget the audio crosstalk 00:00:47

Marcus Lillington: I said hello as well. I did both aspects. Professional me. See? I do it all.

Paul Boag: Yeah. And, more importantly, than Marcus, we've also got Adam Silver. Hello, Adam.

Adam Silver: Hello. Hello.

Paul Boag: It's good to have you on the show.

Adam Silver: It's good to be here.

Paul Boag: So, I hear great things about you, Adam. You come highly recommended crosstalk 00:01:10 by Marcus, Marcus at Smashing Magazine.

Adam Silver: Oh, he's awesome, Marcus, and very kind.

Paul Boag: He is very kind. He basically told me that I had to have you on the show. Otherwise there would be serious consequences. Although he didn't need to threaten me, because I would have quite happily had you on the show anyway, but there was threatening, there was crying and begging … It was quite pathetic, really. crosstalk 00:01:37. And also a complete lie.

What happened was, is he was talking about the book that you've been writing for Smashing Magazine or have written, now, it's out, isn't it?

Adam Silver: Yeah.

Paul Boag: So, tell us a little bit about the book.

Adam Silver: The book's called Form Design Patterns. The subtitle is A Practical Guide to Designing and Coding Simple and Inclusive Forms for the Web.

Paul Boag: I see.

Adam Silver: So, there's like 10 main chapters where take some sort of chunky problem and step through all the options for it, analyzing those options and end up with an actual technical solution with code off the back of it at the end of each chapter.

Paul Boag: Ooh. What crosstalk 00:02:26 can you give me an example?

Adam Silver: Yeah. An example would be, the first one was a registration form, which maybe a few fields, second one's a checkout flow, third one's booking a flight online. But each one of those things, they sound relatively simple maybe at first hand, and then you break them down and there's like really nitty gritty design problems in there with some really interesting solutions for them as well.

Marcus Lillington: So, Paul, I'm just going to pull you up on the fact that that's somebody who writes a book that's both inspirational and useful. Isn't he? "You're an arse, Marcus."

Paul Boag: But I gotta say a book like that really appeals to me, because form design, I think, is like the … And it has a sensible name, Paul has just said in the chat room. Arse to you, Paul. He's thinking about what I wanted to call my next book which had the strapline … I can't even remember the strapline now, it's gone out of my head, but it was basically very rude. We're not really going to use it.

But no, form design. Form design, I think, is one of those kind of, on the surface, it's like you're just whacking a form, but it's the hardest thing to get right as an interaction designer, because it's where you're relying on the user doing something that's quite complicated. So it always goes to pot, doesn't it, really, if you're not careful?

Adam Silver: If you think about it, most of the interactions we have are actually through a form of some sort. If you're not reading or clicking a link, you're basically interacting with the form, you're creating something, you're editing something, you're deleting something, you're ordering something. So it all revolves around forms, so they seem so boring and so well covered and yet I think, actually, behind everything there's a form from crosstalk 00:04:13

Paul Boag: Go on, Marcus.

Marcus Lillington: It's the thing that every normal person complains about. Any non webby people, they always complain about, "When I was booking the flight …" that's a classic, and then it dumped me out or whatever and it didn't remember who I was, or I was left hanging. All of those kind of things. Absolutely the case, but I just wanted to say, that this has doubly reminded me of the fact that I spent a day doing usability testing on Wednesday.

Paul Boag: Oh yeah. How did it go?

Marcus Lillington: Really, really good. Everyone in this profession should do usability testing in my view, probably once every three months, minimum, to remind yourselves how other people use the Internet. This is a classic one. This was Find of the Day, by three testers, three different testers. "I didn't know you could click on the logo to go back to the homepage."

Paul Boag: Wow.

Marcus Lillington: I'll just leave that one with you.

Paul Boag: Yeah, absolutely. And forms are another really good example. Things like tabbing between forms, form fields, most people don't know that they can do that. And then also the other thing with that is when those people do know, and the designer hasn't designed it so that it tabs in a logical order, it jumps all over the place, which is why I'm so pleased at what you said when you started talking about this book, Adam, and you said you haven't just looked at the design elements. You've also looked at the code elements and you used one word that made me very happy, which was accessibility, and the accessibility of this kind of stuff as well. It sounds a really good book. I might actually have you buy it.

Adam Silver: I guess we'll get into this in a bit, I think you've talked about it in more of your other shows, but design is so much more, obviously, than just the way it looks and yet we think that that's what it is. And I'm preaching to the choir here, but you touched on it and I just wanted to say it again, really.

Paul Boag: So you call yourself an interaction designer, is that right? Is that the title you've given yourself?

Adam Silver: Yeah, yeah. I've crosstalk 00:06:21 settles on.

Paul Boag: Fair enough. It's fascinating, the titles that people come up with, because there's, who knows crosstalk 00:06:31

Adam Silver: Job titles?

Paul Boag: Yeah. Yeah.

Adam Silver: Job titles are one of those things, aren't they?

Paul Boag: Yeah, yeah, absolutely. So do you work for yourself, or do you work for somebody else? I know you've worked for Tescos in the past, you've worked for the BBC, you've worked for the UK government, are you still at the UK government?

Adam Silver: Yeah, I'm currently working as a contractor for Her Majesty' Courts and Tribunal Service. Excuse the mouthful.

Paul Boag: Yeah, they go.

Adam Silver: Yeah. It's like designing services, like letting users apply for a divorce online or apply for a civil money claim or appeal a benefit that's been taken away from them.

Paul Boag: So there-

Marcus Lillington: Complicated.

Paul Boag: … hence the book on form design, really complicated, difficult stuff.

So you work as a contractor, is that how you operate, going from company to company?

Adam Silver: Yeah. I've been contracting for more than 10 years now. I started off as a perm. It's one of those situations where I came out of uni, got myself a perm role, two different roles, actually. So the first one was for about 12 months, then I got another one for another 18 months, and then at that point, I'd ended up stumbling across this world of contracting, and I worked with a whole bunch of contractors and I was relatively junior, and I was in charge of about five or so front end developers.

I say in charge, I don't want to say like really in charge, but I looked over their code and reviewed their stuff. And so I turned around to the and said, "You're paying me relatively, not very much. Can I have just a few grand more?" They said no, and that was it. And then I was like, 'Okay, well, if I can't really beat them, I'll just join them.' And been contractor ever since.

Paul Boag: Right. So you tend to work for extended periods of time with one client rather than being a freelancer that just works on one little project at a time.

Adam Silver: Yeah, it's definitely more contracting than freelancing. But I have a limited company, like both would, I guess.

Paul Boag: Well, yeah, yeah, yeah. It would do either way. Oh, that's really interesting. We've not got anyone else on this series that is doing the contracting side of things. It's normally you interact directly with the client to deliver on a project as a freelancer as a consultant or something like that. So where do your contracts come from? Do you use some kind of agency or something?

Adam Silver: It's been varied over the years.going back to your previous point, quickly, I like roles that last a long time, then you can get into the nitty gritty of it, but that's not always the case. Sometimes projects have been canceled so I've been let go after a number of months.

But in terms of my current role, I've been in it for, say, I've been in unit for 10, 11 months, something like that. And I'm in the middle of a six month contract, so those things can roll on, maybe it gets cut short, you never really know.

But in terms of how I get my contracts, same as a permie, really, either through an agent or word of mouth. The last three or four jobs have just been somebody that I know that has just reached out and said, "By the way, there's a job over here. Do you fancy it?" And it sounded really good, and that was it.

Marcus Lillington: Well in.

Adam Silver: It was good because I got to avoid to recruitment agents.

Marcus Lillington: So, are you concerned when a contract is coming up to the end, where's the next job coming from or have you normally got that in place ready to go?

Adam Silver: Yeah. I would try and get early sight of if I'm going to be finishing the current contract or not. And it is one of those things where when I was young and didn't have a family, I was just like, "Oh, it's fine." I didn't really care too much, and I ended up getting a bunch of contracts … My first contract, actually, this is quite funny, my first contract was for two and a half years and it was my longest role ever. I've never had a role longer than two and a half years, and it was as a contractor, so that got a good foundation in place in terms of my confidence. And then now as I've got older, I've got more responsibilities. I'm like, "Oh God, I've got to make sure I keep on having a job lined up," and stuff like that. I get more worried about these days, actually.

Marcus Lillington: Yeah. Sorry to bring that up. But it's a concern for all of us, whatever role we're in, unless you are a permanent member of staff somewhere.

Paul Boag: But even with being a permanent member of staff, you could get fired with a month's notice and you don't see it coming.

Adam Silver: Yeah. It is to say there's not that much more safety in it, I don't think.

Paul Boag: And crosstalk 00:11:03 also you're getting advantages …

Marcus Lillington: We'll move on.

Paul Boag: Yeah, yeah. Well, this is why I like running my own business, because although you have the pressure of bringing in work, at least I can see, "Oh shit, I'm running out of work," and I could see it coming. While when you're a permanent employee, one day, someone might just turn around and say, "Sorry mate, you're out of a job."

And of course the advantage with being a contractor is the rates tend to be typically higher, because they're paying a premium for that flexibility to be able to drop you if they need to. So-

Adam Silver: There's an advantage as well in always needing to be on your toes. You go to different companies, you get more skills quicker, you're exposed to more things … For me there's an element of that worry, just keeps you on your toes. So I'm constantly … I mean, I love what I do, so it's fun to keep on top of those things and just keep on learning and making sure that you are as good as you can be to hopefully get yourself a job easily.

Paul Boag: Yeah, absolutely. Well, all of that was complete tangent, except it's very much in line with the theme of the show, which is about careers and what we do for a living. But I was interested because I've never worked as a contractor. I've been permanent, I've been a freelancer, I've run an agency, but I've never been a contractor. So it's an interesting world.

I just want to very quickly talk about our first sponsor and then I'll get into some better questions for Adam. Well, not better, more prepared questions. I'm going to talk about the Digital Project Manager School, which is an interactive learning experience. Sounds so cool, does it? Interactive learning experience. It's an online course, but that doesn't sound as cool. It's got video lessons, it's got a weekly panel discussions. It's got assignments and group discussion and coaching sessions, all around, as you would guess from the name, digital project management. And, really, it's for a whole load of different people in different positions.

And because it's not a video, it's not a purely video course, but there is this kind of interactive nature, it can adapt to you. So if you're trying to land or have just landed your first proper project management role, it can work very much for you. It can work well for those who are trying to boost their skills and confidence. As Adam was saying, you got to stay on top of your game, and so this would help you do that, especially if you're starting to manage more complex projects. It's also for seasoned project managers who want to refine their approach and stay up to date. And if you just feel like you can want to do some career development and you want to do it at your pace, in your fun and nice way without having to go traipsing into some lifeless, sunless room somewhere, why don't all … Whenever I run workshops, I always end up running them in a basement room somewhere with no natural light. I don't know why it happens, but anyway.

So they've helped people like Sony music, Microsoft, Siemens, Dow Jones, lots of people like that. If you want to join up, keep an eye out for their next course which will be coming up soon and you can find out more by going to the project … Sorry,

Right. Adam, back to you. So, you're an interaction designer. My first question therefore for you is where does that start and stop? Where's the aegis as far as you can see? Because we've already established it includes a bit of coding. So where are the edges as far as you're concerned?

Adam Silver: It's a really difficult one. I was just saying before we started recording to pull … When I saw this question as a potential one for this show, I said, what's an interaction designer? Where does it start? Where does it end? And I was just like, that's deceptive, that question, because it sounds so simple, and I really should know because that's what I call myself, but actually it's really … I was like, "I need to get my act together and work out what the hell is that I do."

Paul Boag: But it's true, isn't it?

Marcus Lillington: What do you say to your mom?

Paul Boag: It's true. So many of us … Yeah. What do you say to your mom? How would you describe your job to your mom?

Adam Silver: Well, I would use an example, probably. I'd say if you want to apply for a new passport, and you need to go on a website and get a passport renewed. Or if you want to go onto Amazon and buy a product, I helped design those things.

Marcus Lillington: That's a good way doing it, but as Paul says, you could do that on paper if you wanted to. You don't have to design what it looks like, you could almost do it as a bullet point list. I'm not suggesting you would, but why do you do the code part of it as well, I suppose is the question, and do you do the aesthetic part of it as well?

Adam Silver: Yeah. So, to talk about what an interaction designer does, where they start, where they end, I think you have to go one higher level. It's funny because when you were saying, well, how would I describe it to my mom? I would say what I said, but I don't do the whole of that thing. I do a part of that thing. And so what's the thing? So then the thing is, I would say, user experience design or service design, and to me, those are synonyms, basically. I can't really tell the difference between service design and user experience design, even if that's not how people interpret those words. So, for me-

Paul Boag: I've written a whole blog post on the difference between those two. But yes. We won't go in that rabbit hole. But yeah, I know what you mean. It's very hard to differentiate it.

Adam Silver: It's like everything that a person experiences, that makes up the entirety of user experience. Everybody is responsible for helping to deliver that. Anybody that works and helps shape the user experience of a thing is essentially a UX designer, which is why I would say that title is a bit of a problem in a way, which is why I specifically don't call myself a UX designer, because I don't believe that I am responsible for the whole of it. I feel like I'm responsible for if we're going to get into that level of detail now, I feel like I'm responsible for the digital bit of it, and that usually ends up being screens that users see when they type a URL into their browser. And I appreciate that it might not always be a browser, it might be an app, but for me, I specialize in web platform. So for me it's that.

crosstalk 00:17:59 And I thought in terms of what it … Sorry, go on.

Paul Boag: No, go on. No, no, say what you were going to say.

Adam Silver: I was just going to say, because your original question was where does it start? Where does it end? And that's a very tricky question as well, I think. I think an interaction designer should be involved from the very beginning of a potential service being created, and by "service," I mean service, a product, a website, an app. It could be any of those things or a mixture of them.

I think an interaction designer should start there at the beginning, and I think their job ends, not when they deliver a picture of a thing or even a prototype of a thing or even a video that describes all of those things, but actually when that thing is in the hands of a user and it's actually meeting their needs, and with a bit of luck, exceeding their needs. So I don't know if my role ends until that point.

Paul Boag: I don't think it does. I completely agree with that. You might not be as active in it, but you're still engaged with it up until the point of release.

Adam Silver: Yeah. And it's like I might be involved in discovery but I may not be absolutely part of the entire strategy of that. I'm helping to be part of the discovery and then maybe the user researcher is more integral there, more important or more dominant at that stage of delivery, and then you get more involved during alpha and maybe beta, and then when it's handed off to live it's like what you say. Then the curve goes back down. I'm less involved last stage.

Paul Boag: Yeah. I'm really glad you distinguish between what you do and a user experience designer, because you get so many of these UI/UX design roles. They just drives me nuts, because I wanted to. I actually don't, but I wanted to describe myself as a user experience designer, because I look holistically at the entire experience both online and off, and I care as much about the service design aspects of how the organization delivers that, et cetera.

But I've had to almost drop the word "designer," and I call myself a user experience consultant simply because if I say user experience designer, everybody thinks of a user interface designer. So it's a difficult one. There is interesting language about it. And, yes, to some degree it's all semantics, and yes, to some degree it actually doesn't matter, but for me, a user experience doesn't stop at the edge of the screen. And that's essentially what I think you were driving at. Well, you focus more on the screen, the interaction.

Adam Silver: Yeah. But even what I might do, mate, I might want to do something. Like if I understand something or if an interaction designer understands something that happened out of discovery, well, there's a user need. It might get me thinking about, how could this thing that I have in my head be delivered by backstage processes.

And it also goes the other way around. So that's me trying to influence the surface design bits of it. And then there's the other way around, which is where the service designer knows how things work today, knows how it may work tomorrow, and then that will influence what I can do on the screen. For example, I don't know, if you're designing a registration flow, there might be an offline process that validates that user. And it's like, well, what does that process look like? How long does it take? How long does it sit in this bucket? I may want to change the way that that whole underlying flow works, but that's not my responsibility. But it's like the edges, it's where the edge is cross.

Paul Boag: Yeah. And it's those edges where I'm interested. I love those those bits where, okay, so we've got this existing process to validate this particular form, but the optimal user experience is this, where do we make the compromise? Who shifts? Do we redesign the back end system or is it that the front end needs change? And so often the default is, well, we've got what we've got in the back end, that's it. Even goes into other areas as well. So compliance, it must be something that comes up with you all the time, when some lawyer turns round and says, "We've got to put this disclaimer text on the form," making the form considerably harder to use. But actually, in truth, there is ways of interpreting and acting upon the legislation that underpins that, and there is room for maneuver and back and forth over it. So yeah, that's, where it gets it right. It's crosstalk 00:22:52

Adam Silver: There may even be like policy or a business constraint that … You're job as a designer, not necessarily interaction designer, but all designers or people that influence the experience. Somebody has to fight to change those constraints and tweak those constraints, which is what it sounds like you would be doing a lot of. And actually it's interesting that you call yourself a user experience consultant because of the trickiness of job titles. And I was thinking off the back of knowing what we might be talking about today, I was thinking, 'If I think UX designer is a bad title, then is service designer a bad title?' And we have that title in government, and I really respect what they do and they do. They are designing services. But they're not designing every bit of it, but they design all the bits that you're talking about.

So I said to myself, 'Is service designer a good title? Service design is a thing, is service designer a title?' And if it's not, what would you call it? The person that deals with those bits behind the scenes? I don't know.

Paul Boag: We've got to get beyond this idea that a designer is somebody that producers visuals, because designing an experience, especially when you get into the word "experience," a lot of those elements of an experience and not something you look at. They might be an interaction that you have? There's all kinds of different possibilities. But going back to the service design versus user experience, that's a really interesting one, because I think really, the only difference between those two is I cover in the article, by the way, I'll put a link in the show notes to the article if anybody's interested in it, but essentially I think the difference is one of perspective, right?

So, a service designer starts by looking at the process that's happening in the organization, how that process can be improved, and by extension that then improves the user experience. A user experience designer starts from the premise of what does the user want, and that informs what the organization has to do. So that's why I would always call myself a user experience designer rather than a service designer because I always want to start, in my own methodology and way of seeing the world, I always start from the users need.

Adam Silver: Yeah, it makes sense.

Paul Boag: But there is so much overlap between these different roles. It's unbelievable.

Adam Silver: Funny enough, you talked process a lot there. So I'm wondering maybe that's a good name for it: process designer.

Paul Boag: Yeah.

Adam Silver: It doesn't sound quite as nice, does it?

Paul Boag: No. Doesn't sound as cool.

Adam Silver: No, it doesn't, does it?

Paul Boag: And also, the trouble is, is a big part of what I do is nothing to do with official processes and everything to do with people, culture, change management, those kinds of things. And that's a different … Who's interviewing who here? I was supposed to talking about your interaction design. I'm getting into the conversation.

Okay. Right. Let's just try and grab it back. I'm interested in your career path. Did you train as an interaction designer? You look young enough that you might have been able to. Such a thing may have existed in university. Or have you come a different route. How did you get here?

Adam Silver: I'm going to go back all the way to GCS, no, not GCSEs. Am I going to go back to GCSEs? No. I'm going to go back to A Levels, where I was doing an IT course. It was double A Levels thing, if you remember those, if they're still called that these days. I'm so old now crosstalk 00:26:29.

Marcus Lillington: Now you're so old. My God.

Paul Boag: Yeah, I know. I know. We're dead. crosstalk 00:26:35 We've deceased.

Adam Silver: There's a few gray hairs, I promise you, this is why I shave it.

There was one module called Web Design, and in that I was learning HTML, and that's where it began. I loved it because it was a mixture between creativity and also logic in terms of coding and stuff. So I started there, I got really interested in it. I've found forms, so I got a form on the screen and I was like, 'Well, when I press the submit button, nothing happens. And so what do I do there?' And so, as we did back in the day or maybe even still today, we looked at your source. And we were like, 'Well, how does it work?' And there was nothing. There was just an action on the form. They didn't do anything.

So then I started to get obsessed with Amazon and shopping baskets, and I tried to work out how those things worked, and I was like, 'Oh, I need to learn back end development. That sounds really complicated and way beyond me.' So at that point there, I finished off the course and I went to uni and I studied multimedia technology where I was just obsessed with learning classic ASP and and all those technologies. That's how long ago. And then I came out of uni and I got myself, I think the role was a web designer/ web developer. If I ever got that job today, you would have called it full stack. And I basically did HTML, CSS and JavaScript, I did some design in Fireworks, not that I was particularly good at graphic design. I set up SQL servers, databases and I even managed the client. And this was my first job out of uni.

So I don't want you to be impressed by this. It's just I did all those things.

Paul Boag: No, that was the way it was for a long time.

Marcus Lillington: Wild West.

Paul Boag: You did everything.

Adam Silver: Yeah.

Paul Boag: So how did you go from doing, because obviously you had very broad skillset and you've had to narrow that down, and you've just said that, "I wasn't particularly good at the design side." In that, you seem to be leaning very heavily towards the code, and now you're an interaction designer. So how did that happen?

Adam Silver: I didn't think I was particularly good at producing designs. Every one of my designs that I would do in my hobbies would just have boxes. My family used to say inaudible 00:28:51 "Oh look, he's done a design. There's another design, and there's another box. And there's a box within in the box."

For me, that's what we design was. I knew it was rubbish, but I couldn't put my finger on why it was rubbish. I felt like I always had a good eye for it, but couldn't actually produce it myself. But like you say, I was much more focused on the coding thing, and I was quite good at it, or I thought I was quite good at it, and so I ended up focusing on front end, because I was quite good at HTML, CSS and I was okay at JavaScript, and I asked so many questions at this first agency that I was joining of all the back end developers. I felt like I should just focus on the front end.

So then, having become a front end developer, my next job was actually as a front end developer specifically. In those days I was working with all sorts of designers. There was information architects, there was UX designers, there was visual designers, and they would hand over assets to me and I would have to build them. I wasn't involved with the design. Sometimes you change a few things, you try to make things a bit more accessible, you'd ask a few questions, but that would be at most what you do. And you basically take those designs and slice them up and code them up. And that was my job.

And then over the years, dealing with the browser and getting to know the way the browser works and seeing problems that happen when you try to build the design that isn't necessarily that materially honest for the web, you end up starting to think about how things could be better for users along the way. This just becomes part of your job.

So I was front end developer for quite a long time, just hopped from front end development role to development role. And I just found myself increasingly moving towards design. And what I mean by that is I'd either make a nuisance of myself and just try and get involved in the design process earlier, or I'd just naturally move towards sitting next to a designer and then just getting more and more involved that way, and making more bolshie statements of how I think the design should be.

Paul Boag: That's how career progresses, isn't it? By getting more and more bolshie?

Adam Silver: I think so. I think I was just an arsy developer, and then I was like, in my head … I'm flitting around here, but I actually moved from being a front end developer to being a UX prototyper. That's a cool job title.

Paul Boag: That's a good one. I like that one.

Marcus Lillington: I like that one.

Adam Silver: You can have it. Of course you can. I'll lend it to you.

Marcus Lillington: Write it down.

Adam Silver: And so I got myself a job as a UX prototyper Working at Just Eat in the designer team. They had a design team and they had a development team, but this was actually working in the design team. But I was a prototyper so I was coding, but at that point I worked with a really good designer, his name's Mark Jenkins. He was just awesome. He was just so modest but also so brilliant. And he was one of the first designers that I worked with that didn't think design was his responsibility. He was the one that was like it's everybody's responsibility, coming back to our previous point about kill the UX designer.

And he really embraced me in my role and was for, "Yeah, what'd you have to say about this?" He really cared about my opinions. And so design became far more collaborative, at least for me, for the first one in my career then. And I was like, 'Okay, I'm really interested in this.' Design can be the things that I say from a this is how it should work in the browser point of view was being valued. So then I could marry technology and design, I could marry accessibility and usability together before sign off. And I loved it. I just loved being part of that process and being part of the usability testing, and the A/B testing.

And from then on out I started making that transition, and my next job was as a UX engineer, so I was doing design and I was doing development, and then I just transitioned from then to where I am now.

Paul Boag: Oh, okay. crosstalk 00:32:54 No, no, no. You didn't, because he eats a very interesting career path, and it shows how, because we've got so much overlap in the different things that we're doing between these different job titles and because we need to work so collaboratively with one another. It does give us a degree of freedom to shift between roles that may be you don't get within other jobs. And so it's kind of nice. The fact that the fact that you had somebody, a designer in Mark who was happy for you to work in that very close, collaborative way enabled that transition happening. It makes a of sense.

Adam Silver: I mean, I guess it helped. It wasn't just that he was modest, but he one of the first designers that I worked with that was very user needs driven. He didn't try to make something cool because it was cool. He was like, "Well, if it was put in front of me, here's the most basic solution that I can do." And I was like, "You're speaking my language," because as a developer you sometimes think in those constraints and you think in terms of simple, and I was like, 'Oh. There's actually a place at the table for that kind of thinking.' You don't have to design cool things and shiny things and animated things to meet a user need.

Paul Boag: Exactly. And again, it's another different type of design that is often more overlooked. When you talk about design, you think about marketing type design, you think about flashy, attention grabbing, that kind of thing. Well, actually, the kind of design I lean towards and from the sounds of it you, is more like designing road signs, or designing the signage in an airport or something like that. It's information always, and saying what needs to be said in the simplest way possible.

So, you talked about some stuff there, you talked about A/B testing, you talked about working hand in hand with developers, you talked about sitting on a usability testing. So that brings me on a little bit to what your typical month looks like. I imagine quite a lot of time is sat in front doing prototyping, but what other kind of things are you doing on a regular basis?

Adam Silver: I'm glad that you asked about that in terms of over a month amongst timeframe, because what you can do, what I do seems really quite varied and it might be, I mean, we touched upon it earlier with where does it start, it might be discovering and defining and writing user needs and not. So they might not be a prototype in sight at that point. There might not be any design, classical design at that point in time.

So I think there's three things that I might be doing at a high level. There's discovering user needs and how things work today. There's high level design, like IA navigation flows in order, frequency of use, first time experience, second time experience, there's high level things. And then there's like the lower level design which you kind of yo-yo between low level and high level design, but low level design is what element should I use for this thing? What are even the HTML attributes on that thing that's going a little bit lower level, where does that thing sit in relation to everything else on the page? Is that a primary thing or a secondary thing?

And so this high level and low level thing, you're almost wrestling with that all the time. And what those things end up producing in the end is a prototype. I'll be sketching, I'll be writing down some thoughts, making some notes and seeing how other people have done it and then I'll create a prototype of the most basic version of a thing before going out to test.

Paul Boag: And do you do the testing yourself? Because I mean you've worked with quite large companies, certainly in your recent history, and of course the larger the company, the more divided the roles tend to be and the more specialized the roles are, so I'm quite interested in what you do, where you hand across to someone else, how closely you work with someone else. So for example, usability testing, is that done by user research, and if so, are you involved in that? How does that work?

Adam Silver: I love going for user research sessions. It's the most fun, because you just never fail to learn something. You think you've designed something that was obvious. It was like what Marcus was saying before, you think that you designed something that's so simple and obvious, but they will pick up on something else and you never fail to learn.

So I've tried to go to as much research as possible. That's not always the case. If my time can be better spent iterating a prototype while the researcher takes that prototype out to somewhere halfway across the country, then I might choose not to go, but I try to go to as much of that as possible.

But in terms of who's responsible, that will be the user researcher who's responsible for that. But I will try and go along with them and maybe I'll butt in and ask a few questions. But ultimately, the researcher that I work with, he'll create some sort of script and research plan, and I might overlook that and say, "Well, could you make sure you find out this, and really look out for this particular thing. Are they seeing that menu, and all they opening in it, and do they understand the options within a menu or something like that?" It's a relatively low level detail. Because normally the researcher I work with, he's great and he's already thinking about the high level things that he needs to research. I barely have to get involved in that. But that's his role.

And before that happens, when I'm designing, I'm not designing in isolation. I might do some designing in isolation, but I will run it past him and say, "Hey, what do you think?" Then I'll run it past the prototyper and then what do they think, I'll run it by my fellow interaction designer and see what they think. It's a collaborative, messy process.

Paul Boag: If you get stuck on something, because when I prototype, sometimes I get stuck on something. There's a particular interaction and I'm not sure whether the way I've come up with is the best way possible. Do you have an easy mechanism? The way that I solved that, as someone who's a team of one, is that I will shove it online somewhere and I will run a little first click test or a preference test or whatever else. So very little lightweight test. Do you use a user researcher in those kinds of situations, or do you just run it yourself, or do you have some other mechanism of dealing with that?

Adam Silver: Well, the first thing I would do there, is one of my strategies is to deliver the most basic thing first. So I try to go out of my own head. That doesn't mean that I don't get my knickers in a twist, I get my knickers in a twist all the time. But what I'll do then is I won't get too emotionally attached to a thing. I'll do the most basic thing and I'll show it to my entire team. And usually that will cover a few of those basic things that I might be getting stuck on.

And then the next level to that is in government we're quite lucky. We do a lot of qualitative research so I don't have to use tools so much, I just put the thing, hopefully we use the GovUK prototype kit, which actually is a proper high fidelity HTML prototyper which is great. And it's quick to prototype in as well.

Paul Boag: So a lot of these problems have already been solved in effect.

Adam Silver: Yeah. That's another subject we need to touch on, don't we? There's the GovUK design system where it's got a load of components, a load of patterns and a load of styles that I've already got to work with and I can just … Part of my job is sometimes just assembling the things in the right place and the right order. I look at a textbox prototype, is that the right thing to use? Yes. The textbox's the right thing to use. I'll put that as question one. Radio buttons, I need radio buttons for this. I need this layout for this.

Paul Boag: See, there's an interesting one, isn't there? Because again, that's a different mindset of this kind of designer who is … there should be a term for this. An information driven designer or an interaction driven designing rather than a marketing type drop designer. I remember early on in my career when I'd been to art school and I was all about creativity and that kind of stuff being driven nuts because I had forced on me this template that I didn't like because it didn't meet my, my design aesthetics, et cetera. But actually, now, that's good. Those kinds of standardization, those standard components are a good starting point. But I'm wondering how you feel about it. Do you find working with those kinds of design systems constraining if you weren't involved in creating them in the first place?

Adam Silver: I think it depends on the principles of the design system itself. How strict is that design system? Does it say that you must use this always? I don't see design systems as that. I see them as: Here's what we know, here's what we have. Here's some guidance, start here, because that's cheaper to do that and requires less thinking, test it and see where it might not fit. You might not have to test it in order to realize that something doesn't quite fit. You might see a pattern and see that you need to adapt it or you might need a whole new pattern.

That's totally okay. I think that's totally okay. But I think the main message is to start with the design system, start with what's there and iterate or change if you need to. I don't see that as limiting myself, because for me, I guess we all feel this way, I just mentioned textbooks and radio buttons and level one headings, they've been around forever. Is there anything new any more? Do you know what I mean? I'm really interested in how someone might improve the thing, but I don't really want to think about textbox any more. I just wanna go, okay cool. It's a text box. And then I want to think about, well, should that textbox go there in this stage of the flow, and how do I ask the question, and what are the words that I use? Those are really important, but the fact that I'm using a textbox, I didn't really want to think about that. I want to think about much bigger problems.

And those bigger problems might be high level things, but those bigger problems might be really low level things. You might be able to use the nitty gritty of some sort of auto complete component and making sure that works responsively on small screens, big screens, with keyboard, with screen readers, with dragon dictate and all the rest of it, and having a design system gives you scope to spend more energy doing those things. And that's where things get fun.

Paul Boag: Yeah. I would totally agree. It gets out of the way having to decide what border radius you're going to put on the text field. I mean, there's more important problems to solve.

Adam Silver: Yeah. Yeah.

Paul Boag: Okay, so you've built your prototype, you've gone through various rounds of testing, now, at some stage, do you then hand that across to someone who does the main build, the beta build? And if so, how are you involved at that stage?

Adam Silver: What I've been typically doing or we've been typically doing over the last four months in my current role is we work on Jira, which is a bit of a shame, and that's painful. But the site's not bad. And so the deliverable, I guess, to a developer is a story that's got good acceptance criteria with references to screens. And because I'm working on a prototype in order to get insights from testing, and because I'm always changing it, I don't really want to give a URL out of a prototype because it will change by the time a developer gets their hands on it.

So I might put a URL in there but just as a bonus, but really it's the acceptance criteria and the screenshots that should be the thing that's the source of truth. But as I said before, where does my job end? My job doesn't end when I've written a user story or helped to write a user story. I'll work with the developers as much as I can, wherever I'm allowed. I'm also basically breaking down silos. So if I can work next to the developer, that's great. And if a developer asks me a question, I will down tools, whatever it is I'm doing if I possibly can and work with the developer, because that's to get help them get their thing pushed across to done. That's the kind of mentality I have. I'm not saying everyone has that mentality or should have that mentality, that's what I like to do, and it means that … Because you can't get everything perfectly written into a story, you should try really, really hard and you should have grooming and you should have planning and all the rest of it. But nothing beats having a conversation and regular dialogue.

Paul Boag: How does multivariant testing fit into all of this? You've worked on some major e-commerce sites as well over the years where obviously multivariant testing is a huge thing. Who does that? Do you contribute into that? How does that work?

Adam Silver: Yeah. At the moment, I've done no A/B testing in over a year. One of the last times I can remember doing A/B and multivariate testing was at Just Eat, and we used Optimizely. Do you know that?

Marcus Lillington: Yep.

Paul Boag: Yeah, yeah, yeah.

Adam Silver: Yeah. So we use that, and as the UX prototyper that I was at the time, I would write those tests, I would go into the code and click on new A/B test or whatever and actually change the code there and then CSS or HTML or JavaScript. So I would be heavily involved in that and heavily involved in the results of that. I remember working closely with the product owner. But in terms of doing that today, I'm quite out of the loop, I've got to admit, because we do qualitative testing rather than A/B testing.

Paul Boag: Is that just the current contract you've got, or is it a reflection on the role you see for A/B testing? In other words, do you prefer doing qualitative stuff to A/B testing, or is it just the contract you're doing?

Adam Silver: I think it's a mixture of both. I've worked in two government departments, and in my experience they haven't done much A/B testing. I think there's probably scope for it, but it would be mostly focused on qualitative testing. Going back to your second part of that question, which is what do I prefer? I definitely prefer qualitative testing. I've really enjoyed doing A/B multivariant testing at Just Eat. It was fun. You could see that moving a button or changing the text of the button, just simple little things that were relatively cheap to do, you could how much of an impact they had. I think there's value in that.

I just find that there's a lot more value, I don't know if it's right to say a lot more value.

Paul Boag: They're very different thing, it's just hard crosstalk 00:48:18 it's an unfair question, really, isn't it, because crosstalk 00:48:21

Adam Silver: Yeah. It's not one or the other, is it?

Marcus Lillington: A/B testing that I've done, the only time that it's really successful is if you've got a heck of a lot of traffic. And I'm guessing if you're doing a really complicated form, for example, the kind of thing you're doing that might be very specialist, then, if you're not getting the traffic through, then you end up, I think, just sort of interpreting the results however you want to. Whereas if you're talking to somebody and getting some actual real human feedback, then you can interpret that as well, but I guess you're less likely to.

Adam Silver: Yeah. Can we rewind 30 seconds and just … Can I steal that answer, because that's great. That's exactly it, isn't it?

Marcus Lillington: crosstalk 00:49:03 I haven't said much today. What you've said has been brilliant.

Paul Boag: Okay. We are running out of time, but we've gone into some tangents that I think have been incredibly useful and very good. I do want to, however, wrap up with a question about how you see your role as evolving and changing over time. Do you think that the job that you're doing today is going to change, or do you imagine yourself moving onto a different job? What do you think the future holds?

Adam Silver: I definitely don't see myself in the near future wanting to be doing other things, in terms of replacing my job with something different. There's definitely one thing that I want to add to the list, is I want to get better at design facilitation, and I think learning way more about service … I'm reading about service design at the moment, I'm reading Service Design Doing, do you know of that book?

Marcus Lillington: Yeah, I've heard of it. Yeah.

Adam Silver: It's a really good book. What I really want to get better at is facilitating co-design yeah. Being able to run a really good and inspiring workshop with intimidating stakeholders and, like a multi disciplinary team with a diverse range of people, and just get them all in one room, and at the end of it make it really productive. But at the moment that scares the hell out of me. I'm more of a team player, like a cog in a much bigger wheel. I would say that's how I would describe myself, but I want to get much better at that and I like the idea of doing that and doing more coachy workshoppy things.

Paul Boag: So can you envision a world where you may be not doing hands-on design as much and that you're actually doing more of that kind of facility, more like my role, I guess?

Adam Silver: I want to say hands-on. I really want to say hands on. I love the fact that I've moved from being a front end developer to a designer by title, but I still get to code a lot. And I still really care about the technical solution, and I really care about the way the interface looks and feels and flows. I really want to stay hands-on with that. So I want to add being able to facilitate to the list of skills as opposed to replace and evolve my role, but that's how I feel today. I feel like I've got so much to learn. I feel like there's so much more to learn. It's never ending. I want to stay hands-on with that.

But I can see myself learning more about that and maybe writing another book and maybe doing a video course on the side and supplementing contracting with other things.

Paul Boag: Yeah, yeah, yeah. What about the role of an interaction designer? Do you see that role itself shifting and changing in the years to come?

Adam Silver: I don't know. I really don't know. One thing I will say, though, is that …

Marcus Lillington: It's a cruel question.

Adam Silver: Yeah. inaudible 00:52:11 Can I asked you the same question?

I was going to say, though, I think the role of a designer or even more specifically an interaction designer, I think that changes wherever you go. And you kind of have to adapt to the team and the organization and the project at hand. You might do more of one thing than another. Like for example, if we had a really good front end developer that thinks as a designer, then maybe I might do less coding, because he might just be faster with the coding than me. I'm just thinking off the top of my head. What I'm trying to say is maybe it's not time that will change it; I'm sure it will, but it's also just the culture and the organization, the people that you're working with that affect these things. crosstalk 00:52:54 I've been lucky to work in government where you've got quite a multidisciplinary team with content designers, user researchers, service designers, developers, and all of those different roles that come together to build something good, absolutely good.

Paul Boag: Absolutely. crosstalk 00:53:12

Adam Silver: That's not the proper answer, wasn't it? That was a bit of a cop out answer. But the same question to you, Paul.

Paul Boag: You never know what's coming around the corner, do you? I'm quite interested. I saw a really good talk by Josh Clark recently, I think it was Josh Clark, where he was talking about the impact things like machine learning and AI might have on interaction design and how we deal with some of the new technologies and the touchpoints those have with real people, where sometimes these AIs don't always get it particularly right as we know from things like Alexa and Siri, et cetera. So that's quite an interesting area.

And then also I'm quite interested in how maybe some of the interactions that we have at the moment could just go away. And it just happens automatically, you know? A classic example of that is we don't need really need an app in order to open our car door, but it will be great if we just walk up to our car and it opens itself. Sometimes an interaction should be invisible. And those kinds of things interest me a little bit. But who knows what the future holds?

Adam Silver: Yeah. I wonder if the screen really will disappear. I wonder if crosstalk 00:54:41 disappear. Probably not entirely, but feels-

Paul Boag: No. It's like anything. Vinyl never disappeared. Cassettes didn't disappear, but they just become niche, don't they? So, I suspect that's where it's going to go.

Marcus Lillington: Cassettes? Really? Cassettes? Come on.

Paul Boag: They're coming back. No, seriously.

Marcus Lillington: They are the worst thing ever.

Paul Boag: I know. I know-

Marcus Lillington: Vinyl's good. It scratches, but …

Paul Boag: Yeah.

Marcus Lillington: Cassettes, seriously?

Paul Boag: I know, but that's the thing.

Marcus Lillington: Why? crosstalk 00:55:17

Paul Boag: They've become trendy again.

Marcus Lillington: We can't leave that one.

Paul Boag: I don't know. I'm not saying cassettes are coming back. I just heard recently that there is now a growing group of people who are collecting cassettes. Don't ask me why.

I want to talk about our second sponsor before this show turns into a two hour one. Our second sponsor is actually very apt from what we've been talking about today, which is Optimal Workshop. So, Optimal Workshop have got a suite of usability tools to help improve your website navigation, to find your information architecture, understanding first clicks, capturing qualitative and quantitative data loads and loads of stuff that you can do via them. You can run fast, affordable usability testing if, unlike Adam, you don't have a person in-house who does that for you. "Oh yes, I have a user researcher. He does all of that, or she does all of that."

So if you end up having to do it yourself, then look Optimal Workshop, because, A, you could do it very fast, very cheaply. You can quickly set up and iterate and create studies that you can learn from you can reach as many participants as you need. They'll even recruit people for you if you want to. They've got over 60 languages represented. You could do in-person stuff, you can work remotely, and they've got some really great visualization tools which make it really easy to understand the data, because let's be honest, that's quite painful sometimes. And help you be more confident in your design decisions just as Adam's been talking about all the stuff today.

So, really, I would encourage you to check that out. It's a tool that I use all the time. You can find out more about

Right. Now, Adam, I don't know whether you've ever listened to this podcast before, but unfortunately we have to end every show with a terrible joke that Marcus is found on the internet. It's a stupid tradition that I have tried to get rid of many, many times, but there is always a public outcry when we do.

Marcus Lillington: I'm happy not to do it.

Paul Boag: Here is that moment.

Marcus Lillington: That's it. No more for no one.

Paul Boag: No, no. No, no, no, no. No, because I will get blamed if you drop that.

Marcus Lillington: I was just playing devil's advocate, a little bit of reverse psychology there, Paul.

This is a joke on the Boagworld Slack channel, by a joke Slack channel. It was on this morning, which did make me giggle, so here we go: Did you hear that Michael Bublé has contracted an unknown, highly contagious disease? They're calling it the bublonic plague.

Adam Silver: The blublonic plague. I can't even say it.

Paul Boag: You've ruined a perfectly terrible joke. You've made a bad joke even worse there. Brilliant. Thank you.

Marcus Lillington: The shame.

Paul Boag: All right, Adam. Thank you. Adam, thank you so much for joining us on the show. I hope it wasn't too painful an experience, and thank you, everybody, who has been listening to the show. I hope you find it useful. Next week we have a Mike Kus, illustrator, designer, photographer, and he's going to talk about his experiences. But until then, thanks for listening and goodbye.

Stock Photos from Chaosamran_Studio/Shutterstock