What Is the Role of the Developer in Interface Design?

Paul Boag

On this episode of the Boagworld Show, we look at the pivotal role that developers play in creating a great interface.

This weeks show is sponsored by Balsamiq and FullStory.

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

Transcript

Paul Boag: On this episode of the Boagworld Show, we look at the pivotal role that developers play in creating a great interface. This season of the podcast is sponsored by Balsamiq and Fullstory.

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

Azlan Cuttilan: Hey, Paul. Hey, Marcus.

Marcus Lillington: I don't know what-

Paul Boag: Hello, Azlan. Good to have you on the show. I don't know why I got quite so overexcited. I couldn't even tell you what I was excited about, but there you go. That seemed to be how we're kicking off the show this week.

So, Azlan, it's been 20 gazillion years, hasn't it, since we spoke?

Azlan Cuttilan: It has. It's been a long time.

Paul Boag: We were just babes in arms, weren't we, when we last spent time together? The last significant time, you were saying, was probably South By, is that right?

Azlan Cuttilan: I remember about 10 years ago sitting on a rooftop bar with the pair of you, and whiling away the hours.

Paul Boag: Yeah.

Marcus Lillington: Yep. Yep. The Iron Cactus.

Paul Boag: That was it.

Azlan Cuttilan: That's the one.

Marcus Lillington: I love [crosstalk 00:01:31]

Paul Boag: That was a good conference, because, basically, you'd go along to a bit in the morning and then mid-afternoon somebody somewhere would crack, wouldn't they, and just write the words, "Margarita" or, "Iron Cactus" or something like that, and then that was it. That was the rest of the day gone, sitting there and talking web stuff.

Azlan Cuttilan: Indeed.

Marcus Lillington: Early March.

Paul Boag: But we did-

Marcus Lillington: Yeah. In the sunshine.

Paul Boag: Well, it's just been.

Marcus Lillington: Yeah.

Paul Boag: It's just happened. It's so big, mind, now, I don't think I'd want to go.

Marcus Lillington: I keep talking that I would like to go back once, but I just-

Paul Boag: Would you?

Marcus Lillington: I just say it and I never do anything about it even slightly.

Paul Boag: The thing is is I think if I went back it would really be more for the Iron Cactus than it would actually for the conference.

Marcus Lillington: Yeah, that's fine.

Paul Boag: Which is probably not a good sign.

Marcus Lillington: Oh, no, is that right? No, that's all right.

Paul Boag: But that means-

Marcus Lillington: I'd want to go just to check out a few of the talks, just to see what people are talking about these days, but you can do that by half ten on most days and then you can go to the bar.

Paul Boag: But you need the right people there. You know, Azlan's got to be there. All the Brit people that all used to go out, otherwise what's the point?

Azlan Cuttilan: I think that would be it. Maybe to catch up with everybody that I haven't seen in a while.

Paul Boag: We need to do a reunion. That's what we need.

Marcus Lillington: Andy Budd has been saying this for about five years. He said it on this podcast. We go, "Yes, yes, good idea, Andy," and then nobody does anything about it.

Paul Boag: Well, yeah, of course. That's how these things work. Isn't it? All talk no action.

Marcus Lillington: He has been trying, bless him.

Paul Boag: So, what are you up to these days, Azlan? Changing the subject entirely, because we can't live in the past. What are you up to now?

Azlan Cuttilan: I have just recently started a new role working with Ross Bruniges at Kalo.

Paul Boag: Oh, yeah?

Azlan Cuttilan: So that's where I am now. I've gone from agency back to being in-house, and yeah, exciting times, for me.

Paul Boag: Good. So, basically, you've just started a new job, and then already, at four o'clock on a Monday afternoon you're slacking off to do a podcast.

Azlan Cuttilan: Yep. Yep. No, that's good.

Paul Boag: I'm glad your employee encouraged such behavior in your.

Marcus Lillington: He had to start at 5:30 in the morning.

Paul Boag: Yeah. He wasn't allowed to go home over the weekend. So, what kind of work is it that you do? Give us an idea of the … So, you're primarily development, but what kind of development do you do?

Azlan Cuttilan: These days I am focusing on front end development.

Paul Boag: Okay.

Azlan Cuttilan: Where I am now, specifically using technologies like React and then test-driven developments. So yeah.

Paul Boag: So, you're one of the cool kids that's using React, then, are you?

Azlan Cuttilan: 'Fraid so, yeah.

Paul Boag: That's all right. That's forgivable. But if I understand it rightly, shouldn't you actually be the Prince of some island somewhere, and just sitting around in luxury? I remember you dropping that in a drunken conversation once and I've no idea whether you were just bullshitting me or whether it was actually true.

Azlan Cuttilan: Technically I do have the title of Raden.

Paul Boag: Which means?

Azlan Cuttilan: It's a bloodline title that has been passed down for generations. Originally from Malaysia, Indonesia.

Paul Boag: Ah, okay.

Azlan Cuttilan: Not that there is any throne for me to go and claim or anything.

Paul Boag: Ah. That's a bit disappointing, then. But that does instantly make you much cooler. I don't know why, it just does.

Marcus Lillington: Well-

Azlan Cuttilan: Being an allegorical lion isn't cool enough?

Paul Boag: No, that's true. That's pretty cool as well. Yeah. All in all, you've got it made, I've got to say. Marcus, do you have any kind of royal heritage that I don't know about?

Marcus Lillington: Well-

Paul Boag: Are you a prince of somewhere?

Marcus Lillington: Funny you should mention that.

Paul Boag: Oh, for crying out loud. Am I the only commoner on the show?

Marcus Lillington: No. I have recently been made a lord.

Paul Boag: Of what?

Marcus Lillington: I have got a full title. I'm trying to find it. Lord of the Manor of Hougun or something like that.

Paul Boag: What the hell are you talking about?

Marcus Lillington: I have a 5' square of a piece of land up in Cumbria. My son and his girlfriend bought me this title for my birthday. So I can refer to myself, legally, as Lord Lillington. I'm not going to, but I could if I wanted. But that was paid for.

Paul Boag: But at least you have something. You have a 5' square chunk of land, which, it sounds like-

Marcus Lillington: Yeah, I can't sell it though, because it's National Trust.

Paul Boag: Oh, right. It sounds like more than Azlan has got in his. At least you can go and stand on your 5' square bit of land.

Marcus Lillington: I can do that, yes, and I can use the coat of arms and all that kind of stuff, if I so wish. I've been known amongst some of my friends, or, me and Caroline have been known as Lord and Lady Lillington for about 20 years, locally. So that's why he got it. So I can now officially call myself that. There you go.

Paul Boag: Well, I feel very common compared to you two. I still think that that is hilarious, Azlan. The combination of having the coolest name in the world and being, I don't know, royalty or whatever it is, is pretty damn impressive. Has it helped much in life? Do you feel that it's enabled you to succeed to a huge degree, having this kind of pedigree behind you?

Azlan Cuttilan: Well, nobody over here knows what it means. So it makes no difference, does it?

Paul Boag: Well, they do when you explain it drunkenly in a bar at South By.

Azlan Cuttilan: And you remembered it, as well. I'm amazed.

Paul Boag: Oh, yeah. Well, of course you do. That's the kind of thing you remember. It's just stuck with me, that's all. Anyway.

Marcus Lillington: It's nothing to do with what you might have had to say about, you know, the latest web things of the day or anything like that. No.

Paul Boag: Oh, yeah, but let's be honest, that was so long ago, it was like, "Oh, yes," you know, "Web 2.0, isn't that exciting?" I mean, who gives a shit about any of that stuff now?

Marcus Lillington: Good point.

Paul Boag: I mean, it wasn't React. Because obviously React will be around forever.

Azlan Cuttilan: Of course.

Paul Boag: So, let's quickly do our first sponsor, and then we'll get into why we've got Azlan on the show.

Marcus Lillington: Are you not going to talk about the snow again, Paul? Come on.

Paul Boag: Oh, do we have to?

Azlan Cuttilan: It's sunny here.

Marcus Lillington: It's sunny here, now. But I had to take five inches of snow off the car. I measured it, because that's how [crosstalk 00:08:55] I am. I was like, "Ooh, that's a lot of snow." I had a phone call from my son this morning saying, "I've crashed into a fence, Dad, and I can't get my car off it," so I had to go and rescue my son, who bought me the title, actually, bless him.

Paul Boag: Ah. Right. So, basically, he buys you a title and then treats you like a servant.

Marcus Lillington: Yes. Exactly.

Paul Boag: That sums up children in my experience. So that's good. So, Azlan, have you not got snow where you are, then? Have you not had any?

Azlan Cuttilan: No, I'm in London at the minute, but I only live a few miles up the road from Marcus anyway. So back home is probably covered in snow.

Paul Boag: Oh, right. Ah. I didn't know that, that you just live near Marcus.

Marcus Lillington: I just remembered.

Paul Boag: See, again, that's why you've both got titles, isn't it? Basically. Because you live in a posh area, not down in Dorset.

Marcus Lillington: That'll be it, Paul, yes.

Paul Boag: Do you live in a stately home as well, Azlan?

Azlan Cuttilan: Yes. Yes.

Paul Boag: Yeah.

Azlan Cuttilan: Definitely.

Paul Boag: Thought so. See, I knew. Marcus, is it all right now if we get on with the show? Because I know you like to waste at least 20 minutes, but I was just trying to be good for once.

Marcus Lillington: Oh, all right, then. Talk about … What are you talking about, Balsamiq?

Paul Boag: Well, first of all I was going to tell them what we're doing on the show.

Marcus Lillington: Oh, okay.

Paul Boag: Because-

Marcus Lillington: What are we doing on the show?

Paul Boag: Well, so, you might be wondering why we've got Azlan on the show who is a self-confessed front end developer, when we're supposed to be talking about interface design, but I thought it was really important to actually emphasize the role that developers have in the design process, and in creating user interfaces. So who better to have on than Azlan for that? So, that's what we're going to be talking about in a few minutes.

But, before we get to that, I do want to quickly mention Balsamiq, because they're awesome and they've supported the whole season, and everybody in the whole universe has used the product so I don't know why they're bothering sponsoring the show, because I bet even Azlan, as a developer, at some stage, have you either heard of or used Balsamiq?

Azlan Cuttilan: I have indeed used Balsamiq.

Paul Boag: See, there you go. Even developers use Balsamiq. Now, there is no link between what I just said then and the next comment. I just said, "Even developers use Balsamiq," and I'm now about to say, "Because it's really easy." I'm not implying that developers who use-

Azlan Cuttilan: Cheers, Paul. No, it's all right.

Paul Boag: I'm just not implying that, that it's so simple even a developer could use it. But it is. It's as easy if not easier than pen and paper. Because a lot of people feel intimidated by pen and paper, and Balsamiq is drag and drop, and you can't move things around with pen and paper very easily. You have to rub them out or cut things out and that kind of stuff. Could be done straight in Balsamiq. Of course, on top of that, you've got all pre-built components, so you don't have to draw out a calendar and all the rest of it. It's all just there and you can use it.

So, it's great for meetings, when you want to visualize ideas in real time with the client or stakeholders or developers or anybody else. It's also great for selling ideas with minimal effort, because often, if you just explain what you're going to do people don't get it, they misunderstand it, they misinterpret what you're going to deliver, and it causes problems down the line.

But on the other hand, you don't want to spend hours creating design comps that might not get sold off … Sold off? Signed off, that was the word I was looking for. So, instead, you could put something together really quickly in Balsamiq to make sure you're heading in the right direction.

Also, it's great that you can use it for engaging and collaborating on the design process, with everybody from project managers to developers to everybody across the whole team and stakeholders, obviously. Of course, the great thing with getting stakeholders involved in collaborating to create a design is that if they feel that they have been involved in creating it then they're less likely to reject it, which is obviously good news for everybody. And, they're more likely to defend it with other people inside the company.

So, to give it a go, you can get a 30 day free trial where you can just have a play with it, by going to Balsamiq.cloud. After that 30 days, if you decide you want to sign up, when you do sign up you can use the code BalsamiqBoag alongside your billing information when you create an account, and that'll give you three months for free, which is a bit of a bonus, really. So, there you go. Give that a go.

Right. Time to talk about developers and developers' role in the design process. Now, Azlan, you've worked both in-house and for agencies, did you say?

Azlan Cuttilan: Yep. That's right.

Paul Boag: So, at the moment you're working in-house. Had you worked in-house from your previous job, or had it always been agency before that?

Azlan Cuttilan: I've flip-flopped between the two.

Paul Boag: Ah. Okay. Cool. Why's that? Do you just like changing it up, or is there any particular reason for that?

Azlan Cuttilan: I think there's things that I like about both sides of it. So, with the agency thing, it's lots of different projects, really varied range of clients and the variation in the projects makes a big thing for me. With in-house, you get to revisit things that you've already worked on and had to put to aside, because it might not have fitted the timescale of a delivery, previously. So you get to go back and polish up things that you may not have done in an agency role. So, there's benefits to both sides, and I enjoy both sides of that.

Paul Boag: Would you say there's a difference in the way that you work with designers in that kind of situation? You know, doing things like creating a user interface, do you have a different working relationship or is it pretty much the same?

Azlan Cuttilan: It's pretty much the same. I like to work pretty closely with the designers anyway. Having a language that is common between us, and being able to talk to design, and work through the process and understand what a design comp that's been put in front of me is going to achieve, and how I'm intended to implement it, all comes together in pretty much the same way, regardless of whether its an agency or an in-house role.

Paul Boag: So, how do you like to work alongside a designer? What's your preferred approach?

Azlan Cuttilan: Generally I would work talking through the design comps as they're put across to me. Ideally, I would like to be talking earlier in the process, so, when a feature is being requested, then discuss through what things are we going to be doing with that, if there's any tech reasons that we might have limitations on particular things that we can or can't do, and try and help understand what is available to us to be able to deliver, so that when it comes down the line to actually having to implement it, then we've got a good understanding of what we're going to be putting together, and it saves time in that development process.

Paul Boag: Does it help you to actually sit beside a designer? To actually see them producing work as they go along, so you can pull them up on stuff? Or is that a bit intrusive?

Azlan Cuttilan: I think that might be a bit intrusive. I would generally be doing my own thing, but then, when there's things that need to be discussed, then sit down and have a chat together. If you've got a small team working on a project or a feature, then sitting together as a team can aid that so that it's easy to just ask questions as you need to, rather than having to send messages over Slack and wait for replies.

Paul Boag: I always think-

Marcus Lillington: What we've found … Sorry, Paul. What we've found is a really key part of the conversation between developer and designer is ensuring that the designer is remembering all of the design elements that are out there that can be reused. You mentioned that. So, rather than maybe going off in a completely different direction, you know, "Have we got the tools in place to re-implement this new thing that we're looking at?" That's something that we come across a lot, that we've found over the years, to ensure that's part of the conversation between designer and developer.

Azlan Cuttilan: Definitely. I'd second that, having some kind of design system or pattern library, whatever you want to call it, Paul, being able to reuse anything that's existing is going to help save time, and reduce the lines of code that are necessary. So, reduce the bloat of the code and make the site a bit more performance.

Paul Boag: That can be quite a tough one for some designers, mind. I've been working with a designer recently who when he designs, it's very instinctual, you know? It's not very systematized. I've had to physically pin him down next to a developer, so that the two sit side-by-side that you don't end up with different padding between similar elements, or you don't end up with slightly different shades of blue and all of that kind of stuff.

That's one of the ways I think a developer can really help, certainly a front end developer can really help in the design process, is by bringing that level of consistency and attention to detail that some — not all — but some designers struggle with.

Marcus, I always think about Ed and Dan's working relationship, in terms of a good working relationship between a designer and developer, because they're always batting backwards and forwards between one another, which I think is really healthy.

Marcus Lillington: Yeah. I mean, Lee and Dan are even more a better example, because obviously, Lee doesn't do so much in the way of front end development.

Paul Boag: Oh, right.

Marcus Lillington: The key here is finding the balance between allowing the designer freedom to design without feeling like, "Oh, I've got this constraint and this constraint," while ensuring that you're not creating something brand new with every new feature or page design or whatever you're doing. So it's getting that balance right is key. Sometimes there'll be arguments, and other times it'll be fine.

Paul Boag: Talking of balances, mind, I mean one thing that I'm always a bit struggle with when I come to working with developers, is that on one hand … I mean, you said it yourself, Azlan, you said, "Ideally I would be involved in a project earlier, and discussing user interface, and when features are created." But then, there's a balance with that about how much time do you want to spend in those meetings and having those discussions, compared to actually being able to get on with the work? Does that make sense? I mean, do you have a preference with that? How much do you actually need to be in the room?

Azlan Cuttilan: Yeah. It's a difficult one, and it's one that comes up quite regularly in discussions. So, with developers, generally tend to find that you're at the end of a chain and you're the last line before the product gets delivered, whether that's a feature or whether it's the full product. Then, it's going through UAT. So, there's a lot of pressure on the developers to be able to deliver on time. The developers really do like to be focused on just coding.

So, minimizing the amount of time spent in meetings is important to us as devs. But, at the same time, you do need to have some knowledge of what's going on, and have some input into things earlier in the process. So a balance does have to be struck.

Sometimes, that could be that a member of the team can sit in on those early meetings, help make the decisions with a technical view being put forward at that point, and that doesn't necessarily need to be the developer who is doing the coding at the end stage. It could be the tech lead who is sitting in on those meetings at the early point. But, it's somebody who has some technical knowledge.

Paul Boag: Yeah. That'd be nice, wouldn't it? A lot of decisions seem to be made without actually having someone with any technical knowledge in the room. I also think, sometimes, it's about the way that those meetings are organized. The trouble is is that a developer can get dragged into a two-hour meeting, where probably he needs to be in there for 10 minutes. There's a small part of it which is relevant to him or her. Then, the rest of the meeting, really, they could just dip out and get on with work. So, I think that helps, as well.

But, I do agree with you. I think having someone with technical knowledge in at the beginning of the process, when things are kicked off, so you've got context for the rest of the project and even ideally the developer that's actually going to work on it, I think is really useful.

But this is also where daily stand ups, I think, work quite well, because that means that every day the whole team is just saying what they're currently working on, and that's a good moment for the designer and the developer just to … I was going to use the phrase "touch base" but I've got … A chance to make contact with one another, and ensure that nothing's going weird or strange from a development point of view. How do you deal with that, Marcus? Because, I mean, you've got developers that you're trying to corral and keep busy, but on the other hand, you want to keep them informed, too.

Marcus Lillington: The ideal way … It doesn't always work like this, but we try to ensure that the full team, so, everyone — back end developer, front end developer, designer, project manager, et cetera, everybody — attends the initial kick-off, which usually, if it's a UK client, will be for a day.

Quite a lot of that time, particularly for the back end developer, will be just … They won't have a great deal to input, but we've found that, as you said, Paul, just getting that context of why this project is happening and who the people are involved and what their likes and dislikes are, we've found is really valuable further down the line, that everybody gets to get that initial input.

But, we tend to do weekly meetings with clients, and we will basically just look at what's on the agenda, and we'll say, "Look, it's up to you whether you want to attend this weekly call or not," because quite often they'll be an hour, maybe even two hours, sometimes, and it's a better use of everyone's time if certain people don't attend. But it's more a case of, "Do you want to attend this?" And if it's like, "Well, no, not really," then that's fine.

Paul Boag: And you can always, you know, if you know that they're working at their desk, you can always drag them in if a specific issue comes up, rather than trying to bullshit in the meeting, you know?

Marcus Lillington: Yeah, I've never done that, Paul.

Paul Boag: What, bullshit in a meeting? No, I'm sure you haven't. What about usability testing, Azlan? Is that something you've ever sat in on? Does it hold any value to you?

Azlan Cuttilan: I have sat on a number of usability tests. I was doing a project with a client, and we were doing design sprints. We put a team in. Within a week, we were identifying a problem that they had on their site. Coming up with possible solutions. Deciding on something. Building a prototype to a working point that we could then take into a testing lab on the Friday, and then as a team we would all be sat there watching through the glass. From my point of view, that was really enlightening.

Paul Boag: Oh, good. Good.

Azlan Cuttilan: There's so many things that we expect people to do, and we think is going to be obvious. We're trained in a way of thinking. We know how we intend something to be used by the way that we build it. But somebody to be sat there and doing something differently to that, it can be really surprising to us, and without actually seeing them doing that, I would never have thought that a general member of the public would even contemplate trying to do things in a different way. But it happens. So, yeah, it really does throw a new light on things. There is value to it, definitely.

Paul Boag: Just going on a little bit of a tangent, you mentioned there that you'd been involved in a design sprint, which is a week-long exercise where you have a series of different things every day that results in a prototype you then test. How was that experience for you, from a development point of view? Because that required you to do a lot more than just code. You were coming up with ideas of what the features could be. How the product worked. Did you find that a satisfying experience, as a developer? Did you feel you were bringing value to the table from that side of things?

Azlan Cuttilan: I really enjoyed it. It was a lot of fun to do it. It was really hard work, to go from identifying the problem through to building something that could be used in the testing lab on a Friday meant that on Thursday night, I could be working through the night to try and get something ready. But, I wouldn't want to go through that on a long-term way. It would just be not sustainable. However, the experience was amazing. It was really good to work in such a small, tight-knit team and be bouncing ideas off of each other, and coming up with things.

No matter how off-the-wall the idea may have been, there were no bad ideas. There was always something we could come up with, we could take away something from, even the most ridiculous of ideas.

Paul Boag: Also, I think that's a great opportunity to break down those perceived roles of who does what. Because, typically, as a stakeholder in a digital project, you wouldn't necessarily think of a developer as somebody that you want to talk to about creating user experience, but there's a whole load of stuff that you can imagine as being possible, while other people in the team might go, "Oh, but that's not feasible," or, "That's not doable."

I think having that different perspective is really worthwhile, and it's good you got to contribute in that, rather than it just being a load of marketing executives and design people and stuff. I think that's healthy.

Azlan Cuttilan: Yeah. There's definitely a lot of things that, from the development point of view, because we have to stay on top of what technologies are capable of and what is becoming available to us, we might be able to put forward some ideas that aren't ones that are established ideas, because it's something that's new to the table.

Paul Boag: I mean-

Marcus Lillington: That's so true, though. Sorry.

Paul Boag: Go on, Marcus.

Marcus Lillington: I butted … Cut in there. Often, I like to have developers in meetings to ensure … Because I often think of it in a negative way, sort of keep me on a leash or keep designs on a leash. I'd start saying things and people start rolling their eyes from a development angle.

Paul Boag: Yeah.

Marcus Lillington: There's another side to that. Quite often I'll think things are hard and going to take ages, whereas if a developer comes up with an idea that I'm thinking, "Oh, that's going to be hard," but they're coming up with that idea, then I know that it's something that's quite feasible, that we should be considering. So it's great to have that input in amongst people that might be described more as creatives than developers. So, couldn't agree more. That's a reason why it's great to have people there at the start of projects.

Paul Boag: I think, as well, from our point of view, Marcus, as the geriatrics in the room … I meant that from the point of view that we've been doing this for a very long time. I think that in some ways we can be almost a little bit out of date in terms of what's possible and what's feasible.

For example, I know that there are gaps in my knowledge around certain areas of animation these days, of what you could do there, or flavors of interactivity, or connecting to various APIs that can pull in data. So, sometimes I think having that knowledge and understanding means that developers are able to think of things that wouldn't have even occurred to me, that could potentially improve the experience.

Talking of which, I mean, there's all kinds of areas that I think developers have a huge impact on the user experience that we don't necessarily consider, and Azlan, I'm interested in your perspective on that. If you've got a load of designers listening to this, thinking, "Yeah, well, it's user experience design not user experience development," what would you say to them in terms of how you shape the user experience and the effect that you have?

Azlan Cuttilan: Sure. I really think the user experience is on all of us, everybody who's involved in delivering the product. We need to have an understanding of what we're doing with regards to user experience, specifically from the dev point of view. Having a site that performs well can make a big difference. There's a lot of tricks that we can use to our advantage for that.

So, example might be a critical CSS, so that we can deliver the CSS with what is going to be initially displayed straight away, and then have the rest load asynchronously. Lazy loading of things that are off-screen, as well. Another way that we can make it appear that the site is loading faster.

Then, something that I've been looking into recently is particularly with React's Isomorphic Javascript.

Paul Boag: What on earth is Isomorphic Javascript? That sounds so cool. It sounds very Sci-Fi. Go on. Educate me.

Azlan Cuttilan: With something like React, it's Javascript. You're looking at the site being rendered on the client's side. That means that you have API calls going off to get the data from the server, and then it gets rendered on the client's side. You can initially have a Flash of the site loading up, but without all of the-

Paul Boag: Ah, yeah, yeah.

Azlan Cuttilan: So, Isomorphic Javascript means that on server side, you create a version of the page that already gets that data, you pass that to the client, render that whilst the more dynamic client-side version of it is getting delivered to the client.

Paul Boag: Wow. I love that. So you avoid all that Flash of loading that's so irritating. And that's a big part of, I think … We talk a lot about performance, which is right and proper, but performance isn't just page load time. It's not a hard number. It's that perception of performance.

So, things like avoiding those kinds of Flashes where things are obviously loading, or lazy loading images which feels like it's all loading quicker than it really actually is in the background. I think that's another really good point, is that oftentimes a designer might want to do all these amazing things with lots of fonts and imagery and that kind of stuff, which is great because that does enhance the experience, but there is a balance if that's then a trade-off that affects performance and that kind of thing as well.

Then, of course, there are other areas, as well. I mean, stuff like security is a big area you must spend quite a lot … I suppose you don't as much, do you? Because that's more server-side than client-side. Do you do much with security stuff?

Azlan Cuttilan: I haven't been recently, but I have had a play with a few things. With things like Firebase, whereby you're handing over to, and using Google Firebase Service, to do authentication using social media.

Paul Boag: Oh yeah.

Azlan Cuttilan: So you can use Google login, Facebook, Twitter, that kind of thing. So that's quite a fun one that I had to play with.

Paul Boag: Yeah, and again that kind of thing helps their experience, because that's one less password to remember, because you're logging in with something you've already used. Form validation is another one that I always think that developers have this huge impact on the user experience in terms of how they pass data, and whether they're forgiving over how somebody chooses to format their postcode or telephone number or all those kinds of things, and how errors are worded. There's so many areas that developers impact the user experience. It so often is underestimated, in my opinion. But that's a little rant on my part.

The one last question I wanted to ask you about, Azlan, is, you've been doing this for a long time now. As we established from our South By talk. So over those years, obviously, you pick up a lot, don't you? You pick up a lot about user interface design, about what your designer colleagues are doing. Are there certain things that you've thought developers need to understand about user experience design? Little nuggets that you've picked up along the road that you think, "Yeah, that's a good one to remember"?

Azlan Cuttilan: I think understanding what the pain points are going to be for a user. Looking at what you're doing and thinking, "Is this going to be a pain point for a user?" Classic example might be asking somebody to choose a password. We've been through this so many times, where you get so frustrated when you submit the form and it says, "Nope, you can't have that password. It's not strong enough." "Okay, why's it not strong enough?" So, one, you've submitted it, and then have to wait for the response to tell you, "No," and then it doesn't tell you what's wrong with it.

So, you're just repeatedly trying. Then, eventually, if it was me, I tend to give up and go somewhere else. So just thinking about what might be a pain point for the user as you're going through things.

Paul Boag: And I'm guessing that's where the usability testing was really useful for you, because it's very easy as a developer to think everybody knows how to do this kind of stuff, use the web. Even little things like I'm shocked at how few people tab between form fields, because they don't know that you can tab between them. So they're painfully clicking from one field to the next.

Until you see that kind of stuff in usability testing, it doesn't really sink in, does it?

Azlan Cuttilan: Yep. Definitely.

Paul Boag: I think the thing that I would really encourage, just a few lessons that I would encourage people to take away from this, is if you're a developer, get yourself in on usability testing. Sit in the room. Find time to do that. Because that is so, so worthwhile.

And, for people that aren't developers, to not underestimate the role that a developer plays in the creation of a user experience, and make sure they're involved in those key moments, where that user experience is being decided upon. Whether it be in something like a kick-off meeting where you're setting the aims and objectives for the project, but also when you're looking at why framing. That's a great time, I think, to involve developers, as well. It's such an underestimated area, the impact that developers have.

Okay. Shall we talk about Fullstory, our second sponsor? Before we wrap this baby up in a reasonable length of time, Marcus, for once, as I managed to get control of you at the beginning. See, this is efficiency.

Marcus Lillington: I might have a 10 minute joke to tell at the end of this show.

Paul Boag: That wouldn't surprise me. I wouldn't put it beyond you. Anyway, let's talk about Fullstory first. Fullstory have been supporting the whole season, and if you're trying to convince your colleagues or clients that you want to make improvements to your site, in my experience, those people fall into one of two categories. Right?

When you're trying to convince somebody of something, whether it be to change the way passwords are dealt with, like Azlan was just saying, or whether it be any other element, you're going to have to convince other people, and they are going to respond in one of two ways. They're either going to want hard data to back up your argument. "Oh, we need to implement a new password procedure." "Okay, why? Where's the data to back that up?"

And then there are other people that respond much more empathetically, that you need to be able to show them that users are struggling with this, it's frustrating them, it's making them angry. That two fundamental types of people is why something like Fullstory is such a great tool for winning people over, because Fullstory allows you to show videos of users struggling with experiences, getting frustrated, which obviously is great for when you're trying to reach those people that are more empathetic.

I talk about creating X rated videos of user sessions, which consist of all the sweary, angry bits, where they're using inappropriate language about how frustrating the product is. That's a very powerful tool for people that are more empathetic in how they approach decision making, but also, Fullstory provides the hard numbers that you require to prove statistically significant results to those people that think in that way.

In some ways, a tool like Fullstory is that real sweet spot between the numbers of analytics and the empathy of usability testing. Now, I'm not saying that it replaces those. Absolutely doesn't, but it does reinforce them both. So, that's certainly why it's something that I think you ought to check out and consider adding to the mix.

You can sign up today. You could get a free month of their pro trial by going to Fullstory.com/Boag, and you don't need to enter any credit card information or anything like that to give it a go. You can just sign up and have a play. If you get to the end of the month and you're not convinced, or you might only just want to use it a little bit on certain key pages or that kind of stuff, then you can get 1,000 sessions per month absolutely free and use it for a long as you want, which is kind of cool.

Right. So, that is Fullstory. I wanted to share a little bit, before we wrap up, of some potential further information. I really believe … I'm going to get on my soapbox here. I really believe that the term "user experience designer", as Azlan said earlier … User experience is something that we should all be doing, and it shouldn't just be seen as a designers' job. It is as much a developers' job. It is as much a project managers' job. Anybody's that is involved in that user experience will impact that.

That's not to undermine the role of a user experience designer, but I certainly would love to see more people starting to call themselves user experience developers and become advocates for the user experience to start approaching development work from a much more user-centric point of view. This is actually something I've written about. If you go to Boag.world/UXDev, you'll find an article where I lay out that developer mindset towards user experience, and how important it is.

Another post that I wanted to point you at is this issue of performance, which, again, Azlan's been talking about a lot today, because that's one of the biggest ways that a developer impacts the user experience. I've written about that before at Boag.world/Speed, where I talk about why, in some ways, I would argue that performance is the best way of improving user experience, which is a bit of a bold statement, but I think has got, certainly, an element of truth to it.

Marcus Lillington: Can I add to that, Paul?

Paul Boag: Yeah, yeah. Go for it.

Marcus Lillington: One of our developers, Chris Henderson, wrote an article, which is on my Headscape site — I will give you the link — called, Sorry, Your Site is not Responsive.

Paul Boag: Right.

Marcus Lillington: He's basically making the point it's a responsive site but it's not responsive. It's so weighty and slow that you can't claim that it's responsive.

Paul Boag: Yeah, I see.

Marcus Lillington: So, underlining the point that performance is massively important in the user experience. I will share that one, too.

Paul Boag: Cool. All right. And obviously, all of that's going to be in the show notes that you can find at BoagWorld.com/Show. Then, select Season 20, Episode 10, and we'll include those links in there.

The final one that I wanted to mention was, I came across a really good article that I really enjoyed about how designers should work with developers and how the two should work together. If you fancy reading that, you can go to that at Boag.world/designdev, all one word, all lowercase.

Right. I think that about wraps up this week's show. Now, Azlan has on many occasions submitted jokes that we have used on this show.

Marcus Lillington: He has.

Paul Boag: Azlan, do you happen to have one handy that can show Marcus how it's done, or not?

Azlan Cuttilan: No. I bow down to Marcus today.

Paul Boag: Oh, for crying out loud.

Marcus Lillington: Right, then. My 10 minute joke. Not really.

Paul Boag: Don't you ruin it.

Marcus Lillington: No, no. I won't. This is just a short one as usual. This is from Paul Edwards, from the BoagWorld Slack channel. Police arrested two kids yesterday. One was drinking battery acid, the other was eating fireworks. They charged one and let the other one off.

Paul Boag: Oh, dear. That is so terrible. Wow. That's a new low.

Marcus Lillington: That's a new low, is it?

Paul Boag: Azlan, we need to get-

Azlan Cuttilan: Yep.

Paul Boag: Yeah. You need to be submitting more jokes, mate. We need the quality to go up.

Marcus Lillington: More jokes. Please. More jokes. Give me more jokes.

Paul Boag: Talking of which, talking of the Slack channel, do you need to join it, people? If you're not already in it, you should check it out. BoagWorld.com/Slacking. Azlan's there. What else do you need to know? You get to hang out with royalty. I'm going to argue. And also lords, now, with Marcus there.

Marcus Lillington: Yes.

Paul Boag: It's the cool kids' place to be. Isn't it, Azlan?

Azlan Cuttilan: That implies-

Paul Boag: Isn't it the cool kids' place, Azlan?

Azlan Cuttilan: Are you suggesting Marcus is cool?

Paul Boag: Oh, no. You've got a good point. Damn. You caught me in my own web of lies.

Azlan Cuttilan: But he does have the most twinkling eyes, doesn't he?

Paul Boag: He does. Yes. Yes. Wow, you remembered the-

Marcus Lillington: You remembered that one, then.

Paul Boag: … twinkling eyes.

Marcus Lillington: That's 10 years ago as well. Blimey.

Paul Boag: Oh, it's not. 10 years you were on Never Mind the Buzzcocks?

Marcus Lillington: Correct. 2008.

Paul Boag: That is unbelievable.

Marcus Lillington: Very nearly 10 years to the day.

Paul Boag: Wow.

Marcus Lillington: And how old do you feel now?

Paul Boag: I must be pretty close to death by now. I felt old back then. My word. So, before we get into me diving into death and my age, Azlan, where can people find out more about you?

Azlan Cuttilan: I'm Azlan on Twitter. A-Z-L-A-N. And where I'm working is Kalo, which is KaloHQ.com.

Paul Boag: Cool. Good. And obviously, in the Slack channel as well, which he frequents regularly-ish.

Azlan Cuttilan: Indeed.

Paul Boag: Although, you've been a bit quiet recently, because you just started a new job. You're still in that working hard and making a good impression stage, aren't you?

Azlan Cuttilan: I am. Yeah.

Paul Boag: Okay. So, next week is the last episode in this season, because obviously 11 is a good, common number to do a season. Why on earth I decided on 11 is beside me, but anyway. We're going to be looking at how to design a user interface in an agile world. we're going to be joined by Paul Stanton, another blast from the past.

Marcus Lillington: Cor blimey.

Paul Boag: Paul and Ryan Taylor actually used to host the show when we wanted to go on holiday, didn't they? Back in the day.

Marcus Lillington: They did. It was the Northern version, wasn't it?

Paul Boag: It was.

Marcus Lillington: [crosstalk 00:50:14]

Paul Boag: We didn't like them to do it for too long, because actually, they were better than us and we couldn't handle that, so there we go. All right, so Paul will be joining us next week, but for now, thank you very much and Azlan, thank you for joining us.

Azlan Cuttilan: Thank you.

Paul Boag: Bye.

Azlan Cuttilan: Bye.

Boagworks

Boagworld