How designers and developers work together on a team

00:00 Hello and welcome to Perspective. This is a show by founders of small indie creative agencies, giving our perspective on starting and running our own companies. The aim is to provide some useful advice and inspiration to others as well as learn from each other and get others to become talk on the show. This is our ninth episode. My name is John Dark. I'm a director at Every Interaction and with me today standing in for Dan, I have Tom Johnson, Dan's co-founder from Lighthouse London. Hello. Hello, hello, hello there. How are you doing? I'm cool. I should say long time listener, first time caller. It's good to have you on. It's good to have a different voice.

00:38 Definitely. Well, his one's quite annoying, isn't it? So you and Dan obviously founded Lighthouse together and you are the design half of the partnership. Yeah, less and less so these days, but yeah, I suppose you could still call me a designer to a certain extent. Not that I've really designed much in a while, but that's a different story perhaps for another time. Oh, really?

01:02 Okay. Yeah, we'll have to bank that one. Yep. And that sort of touches on what we thought we'd like to talk about today. We thought it'd be interesting to get two designers perspectives from two quite different agencies and how our designers and our developers work together in our daily processes.

01:19 Despite some outside appearances that both of our businesses, I think day to day operate quite differently and we've got quite different team makeups between our two different companies.

01:30 We do. How would you describe the way that your team is structured? We have six people currently in the company. I'd actually say that every single one of them can code to a certain extent. Our newest guy is here. Hello, Simon. He's here to help us out more with running the place rather than doing work, but I think he's comfortable coding up a landing page or something. So even at the non-techy level of Lighthouse, I think people can sort of code. But from the other five of us, we're all, I guess you would call developers to a certain extent, even the ones who are also designers. So even our guys who are lead designers, Russell and myself, we both are, I suppose, we don't want to toot my own horn, but fairly skilled front end developers who have got a lot of experience there. So we're totally comfortable with anything front end related or not anything because that's a lie. But yeah, we're very familiar with HTML, CSS, a bit of JavaScript. And certainly from my perspective, I go down to PHP and all that kind of stuff. So I does Russ as well. The other guys in the company, they're more hardcore developers. They do the scary stuff. Yeah. The things that I don't really get, the things that most people don't get because it's insanity. But yeah, I mean, that's the kind of makeup in terms of designer dev of our company. But you guys are just design, right? Yeah. So all of our employees in-house are all UX or design focused. Yeah. So there's Neil and myself for doing the directing and sort of spanning a lot of UX and design ourselves. We have a dedicated UXer who's really quite focused on the UX and the research and the wire framing side of things, prototyping, testing.

03:30 And then we have two dedicated UI designers who are solely creatively focused people. And it tends to be a little bit of a waterfall effect through the business from starting to get the business in the first place and doing the initial planning, conception, kickoff work, usually with Neil and myself at the top. Then we'll start working with our UX designer. It'll go through that person in terms of wire framing, sketching, doing general ideation, basis of a project. And once that's started to take shape, then it goes through to design. But in terms of development in our company, yeah, it really depends on the project type. Like we do websites, but I guess today that makes up about 20% of what we do and shrinking actually. Okay. And I think when people come to you for a website that they kind of expect the whole thing. They don't just expect the front end, the UX and the design side of things. Because of that, we have some dedicated external partners who we've been working with for a very long time, who we trust to work with our team and develop all the front end HTML, CSS, any backend, usually WordPress or as in framework or something PHP based for the types of websites that we work on. So you generally go back to those guys again and again and work on similar projects with them. Yeah, exactly. Yeah. But that's only on the website side of things.

05:02 The rest of our business, the vast majority of the work we do, we're working with mostly product companies. For the most part, they have their development pretty well sorted out already. They come to us because they're missing this particular specialism of UX and design, and they want us to slot into their team to an effect and work with their product owners and with their developers. Yeah. See, that's quite different from our side. Everyone kind of shares the work a bit more, I think. So we don't, I mean, we do have specific designers and developers, so there are definitely two of us in the company who would design. And like I said earlier, there are two other people now actually, because Dan doesn't really develop anymore, which is good.

05:40 But we then often hand off the hardcore dev to them. But along the way from kind of interesting saying that you have a sort of pattern through a project as well, I think a lot of us, well, we actually kind of encourage everyone to share the early work as well. So we're always trying to get people more involved in the kind of early, like the ideation, the sketching, especially the wire framing, that kind of stuff. We try and get everyone involved with that as much as possible, so that even someone who's a developer is still having these kind of creative thoughts early on and can kind of contribute to a project before they then just get brought in right at the end as a developer, which I think doesn't really help stuff. And maybe we're lucky that we've managed to find people who are fairly creative people, but are also developers, which seems to be said to be a rarity, but I've never quite found it that way. I've always found people that I know that are really good at dev do actually have a fair bit of creativity to them as well.

06:38 Unicorns, as we call them. Yeah, maybe they're not quite unicorns. They're pretty good. Horses with horns. Exactly. It looks good from a distance, but when we get close, there's a couple of cracks there.

06:53 [laughs] Nice. How during a typical project that would involve design and development, does the project sort of flow from one team member to the next if it involves both a creative aspect and quite a heavy duty back end element?

07:12 Yeah, I suppose, I mean, like you, we've got different types of projects that we do. It's rare that we do a job that doesn't have dev, so there'll always be a developer involved in that, and it's rare that we do a job that doesn't have design. We'll always be doing an element of that with both. Kind of like I said earlier, it's getting everyone involved from the start, so we want to get people in the meetings early on to hear what's going on, even if they're only going to be involved later on down the line. Traditionally or typically, it would be Dan or I starting off the thing. Dan would sell the project essentially. It would come through to one of us, and we'd be doing kickoff meetings, but we'd pull in the key designer or key developer at that stage because certainly if there are a lot of very important design or dev decisions to be made down the line, we need to have that person's buy-in very early on to make sure we're not making mistakes, especially because these days it's probably not us going to do that work.

08:05 And yeah, and then we just kind of divvy the work up based on who needs to be doing that section, but it would usually be down to a designer doing the wire framing and making stuff look nice, and then chatting to a developer in the house and telling them what to do.

08:18 Okay, yeah. I guess it's not too different to what we do really. I don't think it is. We just have an extra level of communication between us and the developers. When it's a website, we tend to naturally fall more into a sort of waterfall process.

08:32 We're controlling the client relationship. We're working out all the decision-making parts of the process at the beginning, doing the design, and at some point during that process, we usually get the dev partner involved, get them to check in at key milestones just to ensure nothing too scary lies ahead, basically, to get their buy-in on the project, to get any input they might have at a few checkpoints, just to make sure that we're not designing ourselves into a corner.

08:59 Because obviously we're lacking the integration knowledge and we don't have the people sat right next to us just to turn around and ask, "Well, if I do this, am I going to be causing this problem?" So we do have these check-ins, but it usually does fall into that waterfall process where we would do most of the wire framing and then the designs before getting our hands dirty with the development and starting to get the thing built, at least with the websites.

09:23 Yeah, for the website stuff is very similar. I mean, some of the web stuff we do is fairly complex or can get quite complex. So we use WordPress a lot, but as most of us in the house know it really well. So even though I'm just a front-end designer, a front-end developer, I do know how to make a fairly complex WordPress site. So I think the good thing from our side, the thing that we've always found is really handy. Even back when it was just me and Dan sitting in a room making stuff together is both having that understanding in-house has meant it's quite easy for us to make those decisions without needing to kind of sanity check what we're doing so we can wireframe something or design something that we know is hard, but at least there's that kind of dev knowledge behind it.

10:04 So it makes us able to make those calls early on without having to kind of get a partner or even necessarily just tap someone on the shoulder in the corner to say, "Are we mad for doing this?

10:15 Is this possible?" We can usually tell whether it is, although sometimes you're kind of like, "I have no idea. This thing sounds insane." So we call Peter or Christy or whatever and say, "Can we do this?" And they always say, "Yeah," but then we say, "Can we do it for the money?" and they say, "No." How do you find the process differs from working on a website compared to working on some kind of product, for example? I'm sure you guys experience the pains of that stuff as well because it just gets far more complicated. We're usually roughly sure of what's going to happen with a website. If it's just what we call a brochure website, you kind of know what you're going to do. There might be some funky stuff you do along the way with some front-end stuff, animations, whatever like that. But on the whole, you're just delivering a fairly simple CMS backend. Obviously, like I said, that can get more complicated and you can start building quite a lot on top of that. But yeah, when it comes down to actually building a kind of fully featured bespoke app, that's when you have to be a lot more careful about how this thing's potentially running out of control, making sure it's all scoped out properly.

11:25 That will be a lot of work of a designer, a client, and a developer sitting together to make sure that everyone's role in it is properly planned out. We've thought of every eventuality and essentially just getting everyone communicating really well so we can all understand exactly what's going to happen and what everyone has to do because those things can spiral out of control quite quickly, especially if people aren't keeping on top of where this product's going.

11:53 Although the developer's role might be happening a little bit later on in the project process, these are the types of projects where you make sure that they are involved more in the beginning of the process. Yeah, definitely. I think we often try and get the developer on those projects to wireframe it because when we're building a product, we're doing loads and loads more of this stuff recently so we started out making websites and now we're trying to move more to do these kind of big product builds because they're fun and you can charge loads of money for it. The wireframing, those things will form a functional spec and I suppose it's got elements of design in there, but I think that's a really good way to get the developer involved early to start getting this big project in their head so they can start thinking about all these things that might pop up. The longer they're thinking about that, I think the less likely you are to have nasty surprises down the line. Obviously also that's great for a client perspective as well because you're getting the developer and the client working early, they're communicating, they're talking about all this stuff and the client seeing this functional wireframe will obviously, well, it doesn't always happen, but they won't come back with a load of stuff that hasn't been thought of later and suddenly surprise you. Having the developer involved in that stage is hugely advantageous to us.

13:15 Yeah, that makes sense. It is pretty similar to us to be honest. I think on those product projects, like I say, the client already has the development sorted. What we, especially recently, what we've started doing more of is insisting that the development partner is more involved than they might otherwise have been from the beginning. If the way that the project is going, it doesn't seem like we're going to get to speak to them or that they're just being kept out of the loop. In our experience, if that happens, then the project can quite quickly spiral out of control. Yeah, that doesn't sound good at all. So you've sometimes been not allowed to contact the developers at all.

13:52 There have been occasions where we've met people who keep the developers at arm's length. Either they're quite remote or they're waiting to pay to use their time in a concentrated burst after we've done our bit in more of a traditional waterfall-like model. If that's the case, it's starting to become a bit of a warning sign for us. We're going to try and insist on a closer relationship with that developer. Yeah, that sounds key to me. I think I'd never want to work on a project where people weren't talking to each other like that. I can see absolute disasters happening if that were the way it went. Yeah. I'm sure you've had a few, right?

14:30 Well, what we find, it's not a disaster, I'd say, but it just... It just... Issues. Well, you often find it often just doesn't launch or it launches and flops. Got it. It's about creating a successful project and something you'll be proud to put in as a case study in your portfolio. Yeah. I'm a firm believer that if it doesn't turn into a good case study, then what on earth is the point in doing the work in the first place? Yeah, yeah. That has happened with us before. We've built some fairly large things that we were fully behind. I mean, this is luckily long in the past now and more down to our naivety than a bad designer development relationship. But yeah, there's nothing worse than putting out something that you've spent a long time on and it just does nothing at all. Yeah, absolutely. But the ones that go well and the ones that go really well are where the client brings us into the project and there's a development team who are seriously involved from the beginning at every level. And we're regularly checking in, having meetings, standups, working a lot step with their sprints. Depends on how the client likes to work. It can range anything from what is a very traditional waterfall model to completely agile and anything else along that spectrum, which there are quite a lot of things. And if it's towards the waterfall lens, then that's when we just need to make sure that the developers are still involved, even if they're not working at the same time as us on the same things. Yeah. I think we've always struggled to fully sell the agile thing to people. I think we'd love to do it.

16:05 We've probably just done what everyone says all the time. And we're definitely changing now because we've done that too much in the past and we're becoming much better about pushing things into sprints and working in a sensible manner from both sides really and not just trying to do everything.

16:24 But yeah, we've always struggled to sell agile. Maybe we're not. I don't know why. I think the client themselves has to be fully bought into the idea. He tend to find that the clients we've worked with, who do it successfully, they've usually done it in the past before and seen the benefits. And I don't know what it was that got them to go through that the first time that convinced them that this is worth doing. Or they go to a development company who specialize in that. So we have some dev partners who it's part of their USP is that they only work in this methodology. It works really well and you can get pretty incredible results in relatively short timelines. Yeah. As a designer working alongside that process, it's also very interesting. You have to completely change the way you go about doing your work. You've got to really lock into the whole sprint based methodology to make sure that you're delivering the things that the team needs to work on for the things that are in the sprint ahead. And you've got to be a little bit ahead of them, but at the same time working alongside them. Okay. Interesting. It does kind of work pretty well.

17:30 I'd say it's great for products who are doing MVPs and trying to get something out the door quickly. But if you're looking to do something exceptionally polished and really high ends, I tend to find it's a little bit harder to achieve those results.

17:46 I can totally understand that. Yeah. I definitely think we've struggled to sell that idea to clients. And interestingly, you say that the ones who've done it before are more up for it because it makes total sense. And I think once you have experienced it, then you see the benefits. But yeah, maybe we've just not come across those people or been tough enough to force them into doing it.

18:05 Yeah. Cool. Getting back to the design developer thing with the way your team structured, how once things are built, do you manage your sort of QA process?

18:16 Oh, you're going to reveal us now. We don't really have one. Okay. That's fair enough. You know, I think QA is something that we know we need improvement on. I mean, it's simple really.

18:31 We push features live. We're all working on stuff. When we're doing stuff, we're kind of testing it as we're doing it, which kind of works and kind of going from the fact that we're all developers to a certain extent means that we kind of know what we're looking for. So we've been building the feature. We can push it out there. And I kind of know roughly enough what I'd need to test having worked on what I worked on in that day or that week or whatever. But yeah, I guess we don't really have like a strict process on doing that kind of stuff. And I know at the moment we're working ways to either have kind of QA partners, people who test the stuff for us, or build a process internally that means that our QA is a bit better. Because I definitely feel like at points that lets us down sometimes on some of the things that you push out and you're like, "Oh, well, that really shouldn't have had that little bug in it." Nothing massive, you know. But I know you guys do that extensively, right? Yeah. I think it's a necessity for us with not having the dev in house.

19:40 It's really important for us to make sure that we keep communication high around the details to make sure that the things aren't missed. I guess it comes down to the types of projects that we work on.

19:53 And one of our USPs is that we do try to put a very high level of polish on the things that we produce. And in order to maintain that, we've got to make sure that we've got a reasonably rigorous QA process that we go through and functionally tests everything. And from the design as well, like make sure that the person who did all the designs and has been working with the developers goes through and tests absolutely everything within an inch of its life from a design perspective and make sure everything works as they had intended at every snap point or every possible width in every browser. Well, it can take a little while. It's definitely a process that is time consuming, but it's the best way we've found to deliver the quality of results that we like to deliver with the team being external. We sort of manage that through a couple of different tools.

20:45 We'll use Slack for general sort of back and forth communication. We'll use Skype for talking. We identify individual issues and manage the workflow of getting them done, tested and signed off through Trello boards mostly, which we find really useful.

21:02 Yeah, we have done that before actually. So on these kind of bigger product builds, when we're testing stuff or going through and making sure it's all working, we've done exactly the same. So yeah, I'd forgotten that actually we do post bugs up in Trello and stuff to keep track of it. So it sounds very similar to why we've handled that stuff in the past. But we can use, sometimes we just use Basecamp list of things we found that are bugs that depends what that person wants to use really, or yeah, like you say, you can just nudge someone on Slack or whatever, even though they're sitting next to each other.

21:31 Well, that's the thing. This is where I think that everyone being external doesn't matter so much anymore. We've got all these great tools, brilliant communication platforms that allow us to feel like everyone's sitting next to each other, even if they're in different time zones.

21:46 Well, so brilliant there. Our entire team is sitting there and not communicating at all, except for through their keyboards. Yeah, I've got a terrible habit in our team of somebody will post me a question on Slack, and I'll just turn around and answer them like a human being.

22:04 What are you doing, you mad? Yeah, the kids hate me. Yeah, I think we try and encourage people to talk, because I feel that's really important.

22:18 I don't want people just stuck on getting a notification through Trello or getting a message through Slack. That stuff's great. It's good to... I like to use Slack to leave something up there that someone can look at later and come back to. But yeah, I'm a firm believer that people should kind of chat to each other and just tap each other on the shoulder if they need to talk about something, especially because we have the advantage they're all just sitting there and we're all working on that stuff and can answer those kind of quick, easy questions. We did kind of experiment or we're thinking about whether we'd have a way to show whether you shouldn't be disturbed in the office. So you could have like a flag or something when you're like in dev mode.

22:59 Right. Maybe you should just wear sunglasses. I like that. That's good. Go back to analog or hats. Yeah, we were thinking of having like a teddy bear or something. A hat's nice. This is much better than all the ideas we had. So yeah, I like that.

23:15 Non-technical solutions. Yeah, totally, totally. We make sure that we're just communicating all the time, basically, which is just the best way for that kind of stuff to move forward. Yeah, totally agree. I think even with the members of our team that are external, that's our philosophy. If you keep communication high, then you avoid the vast majority of problems.

23:35 Yeah, definitely. And I suppose it kind of moves into project management a bit more, but that's the way we kind of mitigate risk in those big builds. We're always doing meetings internally.

23:46 We're actually trying to do more, although not fill up the day with meetings, but kind of make sure that everyone every week knows what the project's doing, knows where it's at. The designer is talking to the developer or talking to the person doing the wire framing or talking to the person doing the research or talking to the client or whatever it is. Because it just builds better stuff. There's no point in getting everyone sitting off there doing their own thing. You've just got to be communicating.

24:10 Yeah, yeah, I agree. I think that's our main takeaway, really. Anything else to add in terms of how you might get your teams working together better? Get them all sunglasses.

24:21 That'll do it, yeah. Yeah, I like the idea of, and I always have, of trying. And it doesn't work for everyone, obviously, because all people are different and they all have different skills and stuff that they want to do. But kind of getting everyone involved where possible. So I've always said that everyone can do a bit of design and everyone can do a bit of dev, really. And I might be naive in thinking that. But certainly try and involve people early on in the project where you're doing the learning. I think there's no point someone like the salesperson doing that or the person that's managing the project just doing that and then just handing that all off to a developer or a designer. This is a bit more broad thing. But those people should be involved from the start. And that, just for me, has always made a better, especially when it comes to software or something, getting that third-hand knowledge from someone else.

25:18 It doesn't work. You want a developer involved from the start, wireframing, learning, chatting to the client, all that kind of stuff. That's always worked really, really well for us. That's interesting. It might be interesting for us to bring a bit of that into our process where we get our external developers to get more involved in that wireframing stage of the project, which we don't do at the moment.

25:38 No, I think it's worth trying. We haven't been doing it for ages, but when we've been doing that more, I've seen a big change in the understanding of the end product.

25:48 Nice. Yeah. On some projects, we've actually gone to the extent of wireframing the CMS to a degree as well, just because we're trying to make the whole thing as usable as possible. And you know what it's like with WordPress. There's always a thousand and one ways to do something.

26:03 And it's about picking the right way to actually go about building the CMS interface so that it is really useful, usable, and the people are using it day to day. There's less friction there for them to use it, and therefore they're more likely to use it and get their job done as faster.

26:22 So not only should we be getting our developers to influence the wireframes more, what we do at the moment is we get UX people to have a bit of influence on the work that the developer's doing on the backend that perhaps isn't so publicly visible as well.

26:38 That's really important. Yeah. I think that's key to get right, because if people don't use your tool, then it's failed, hasn't it? Yeah, absolutely. I think that's the sort of thing we've maybe glossed over too much in the past that we've handed off or built a bit of software that does something and then kind of said, "Well, we'll just make an admin area for that, won't we?" And that's just gone wrong, because you haven't allotted time for making that look great and that experience wasn't thought about. So these days we'll always make sure that that's highly thought out from the start.

27:10 Good. So in summary, talk. I would say so, yeah. It's quite an easy one really. Maybe it doesn't come naturally to everyone, but yeah, it works for us. We maybe should talk a bit more sometimes, but yeah.

27:23 Some of us talk loads. Some of us even record it and put it off on the internet. It's terrible. Shocking, isn't it? Yeah. Parting thoughts. I think that also when you do talk, I think it's important for the team members with different disciplines and specialisms just to explain everything to the other team member. Try and share the knowledge. Don't talk down to them. Don't talk to them as if they don't know what they're talking about, but talk to them in a way that helps share some project knowledge and helps that people learn something from the experience at the same time. And in doing so, next time they come across a similar type of problem when they're working with you, everything's just going to go a bit smoother.

28:06 Absolutely. 100% agree. We're always doing that. Always getting explained stuff that I don't really know what it means, but then next time it comes up, at least I've got that tiny bit of information that I got last time and I can make a better call.

28:18 Yeah. That's what's great about this job, right? There's a never-ending limit to how much you can learn. Oh my God. There's so much to learn all the time, but yeah, it's good. I guess I feel my brain's getting filled up every day, but I'm losing useless information at the other end, I suppose. But yeah, no, I can't complain. It's amazing. Good stuff. Nice. Well, I think that about wraps it up for this week. Thanks for listening, everybody. And yeah, you can find everything about this show at perspective.fm online. You'll find our show notes there, links to rate us on iTunes. Please go and do that. That helps us a lot. You can also send us any comments, questions, or feedback through that website. We're on Twitter at @_perspectiffm. I've been John Dark, @darkjohn on Twitter from everyinteraction @reinteract. And Tom, where can people find you? Well, you can find Lighthouse stuff at wearelighthouse.com. There's blogs and things there. There's also another podcast to go and listen to. It's very good. Everyone go and listen to it. Nice. Like it. You can find us on Twitter @wearelighthouse. If you really want to, I don't use it that much. You can follow me on Twitter @MrHaste, M-R-H-A-S-T-E, but you won't get much. That sounds like a story from another time. That actually is, yeah. We can discuss that another time. But I kind of just talk about heavy metal and I don't know, colors and stuff on there. Not a lot. It's just quite boring. That's a good combination. Don't follow me. That's the takeaway from here. Good stuff. All right. Well, thanks very much. And hopefully, have you back on sometime soon. Nice one. Thank you. Thanks, everyone. See you.