Creating the perfect workflow between UX/UI and development teams

Tom:

Hey, welcome to the product leadership podcast from Lighthouse London, where we talk about how to validate, launch and maintain successful digital products with product owners, innovators, digital experts and founders. Lighthouse London are a digital design and product development team who spent the last 10 years helping people conceive, build and steer digital products. You can find out more about us, and more podcast at wearelighthouse.com, enjoy the show.

Hey everyone, welcome back after a long break to the Lighthouse Podcast. It’s been about half a year, I think.

Russ:

Yeah.

Tom:

Shameful.

Russ:

I’m glad you acknowledged that actually. I wondered if we were just going to pretend, paint-

Tom:

No.

Russ:

— over it like we never disappeared.

Tom:

It’s been going through my mind as to whether we should talk about that, and I feel like honesty is always the best policy.

Russ:

Yeah.

Tom:

So I’m being brutally honest, I think it’s actually more like nine months. Anyway, I’m Tom, and I’m joined by Russ.

Russ:

Hi guys.

Tom:

Hey, you’ve not been on here for even longer.

Russ:

No, it’s been even longer I think. In fact, I guess you were just-

Tom:

It’s been

Russ:

for a while-

Tom:

— for a long time.

Russ:

— with a lot of special guests.

Tom:

Many funky guests, and you can go back and listen to the archives of all the fun things we’ve been talking about from a product perspective. But today we’re back talking about something slightly different or related, and I think that the focus for the next few podcasts is mainly going to be around UX and UI.
So Russ leads up our design team, and we wanted to talk a little bit about a load of the projects we’ve had in recently, and some ways in which we think us and you as UX or UI design teams can work well with development teams.

Russ:

So I think we’ve got a unique perspective on the collaboration team, design and development teams, partly just because we’ve always had in house development, and also just ourselves. We’re both design and dev, and that gives us a little bit of perspective of where that collaboration is difficult, and yeah, some of the things that you … problems that you can run into.
One thing that we find is that design and development teams need to find a common ground. They’re quite different skill sets and yeah, there needs to be some kind of shared language and understanding between those parties. Yeah. And often we find that, that issue is maybe realised to late in a project.

Tom:

Yeah, definitely, we’ve seen that loads. I mean, we’re guilty of that as well, but part of the reason why we’ve tried to solve that in recent years. And yeah, you kind of find that when that kind of breakdown happens, or when that kind of common ground’s not there, a lot of the work you do is undone. Management breaks down as well, so it’s a kind of recipe for disaster. It might not be something that kills the project, but we found that good work to find that common ground will stand you in good stead for the start of the project, and an ongoing relationship as well.

Russ:

Yeah. I think that lets the investment pay off if you’re investing in design, you’re then sure that once the handovers happened that it’s worthwhile.

Tom:

Yeah, definitely. I mean, so there’s a … We’ve just listened to a few examples of when this can wrong, so bad thing are going to happen so we might as well just quickly run through them.
The kind of first one from us is, when we come in as an external design team, it is quite easy, and we’ve seen this happen as well, is to come in and design something amazingly beautiful that then the team you’re working with can’t really easily implement. It’s quite simple to … It’s quite easy to come in and sell the dream, and then walk away and not have to fix a kind of problem that actually you’ve caused, so that’s a big bone of contention that we’ve seen happen in the past.

Russ:

One thing that we’ve seen is, a design team can put in a lot of work and effort in to set of deliverables, and then don’t put in the time to explain it and give their reasoning, their thinking and how they imagine it being implemented, and that kind of just leaves the next team with a void.

Tom:

Yeah, definitely. I suppose it’s like you’re doing creative work, but that doesn’t mean that you shouldn’t document what you’re doing. It’s an important part of any development plan, is to document your code, what you’re after and what you’re doing, sorry, and that should also apply to design.
Next one is the idea of skills gaps, or available resource really. It’s really important that you understand what skill you have available to you from a design team when you’re working with a development team. What are they good at? What can they handle? Where might they struggle with the things that you’re doing? And also, what time have you got there? How many hours, or days, or whatever of implementation time have you got so that you can build something or design something that’s appropriate for the resource that you have.

Russ:

So then we also were thinking around development teams that, by no fault of their own, don’t prioritise and don’t quite understand what the user experience [slant 00:04:49] is of what they’ve been asked to deliver. And again, that isn’t their fault it’s just a completely different skill set, so it’s up to the designers to kind of communicate and be the voice of that in the project.

Tom:

Yeah. I think the last one that we identified, and probably like the most important really, is just communications breakdown. So a lot of what we’ve talked about here is solvable just by chatting to people. And we’ve often found that the bigger the teams, the larger the company, the easier it is for people to work in silo’s. And just regular coms and talking to each other is often the way to solve a lot of these things.
Tom here, we’ve been working with a bunch of larger clients recently to build Bespoke Digital Upscaling Programmes. This is usually creative workshops where we come in, help people understand top skills that they can use in their everyday work life that many of the main startups and entrepreneurs around the world will use. If you want to find out more, head over to wearelighthouse.com.
So, I mean, I suppose, why do you trust us, right? Well, we do this kind of thing all the time, and I think, like we said at the start, there’s a lot of projects we’ve worked on recently where we are kind of guns for hire. We come in and help people kind of create a makeover for their existing product, or do detailed UX UI work on a kind of complex tool. So yeah, we’ve had a lot of experience doing this, and we’ve been trying to solve these problems, so where do we come in? There’s a product team in place there managing day to day feature builds, they’re pushing the product forward from a technical perspective. No UX UI in house. I mean, there might have actually never even been a UXer working on the product at all.
You’ve got a set … a team who are really keen on making changes like they’re invested in this product, they want to push it forward, and they probably see the value of what UX team can provide but they have no skill, and not necessarily any understanding of how you get good results from a project like this.
So what we’ve had to do is, design that a process that gives you a way to communicate what you’re doing with dev team, senior stakeholders that gives them the right assets they need to kind of push things and implement everything.
So, I mean, coming on from that, how do we fix this?

Russ:

Yeah. I think one of the main things to nail is communication, as you mentioned, that’s one of the most important things. They kind of old idea that you can bring in the design team, they hand over the work, and then suddenly the next team has to deal with doesn’t really make sense, and really you need to have all parties involved as often as you can. That kind of constant conversation where you have different disciplines collaborating together and discussing a problem, means that the solutions that you come up with make sense and are realistic.
Yeah. You don’t want to have two teams just working in Silo’s completely in isolation, then you do have issues with when those teams come back together again. So yeah, I think the regular checking in with people, and also being able to see what another team is working on, make sure that everyone has that kind of single kind of central location that they can work together in.

Tom:

Yeah, I think the second one is probably communication first, but then visibility is really important as well. You as a team are going to be delivering stuff on a regular basis, and that needs to go to the right people to sign off. So it’s no good doing a load of work with one or two people who were the kind of stakeholders and senior people who are running the project, you’ve got to have people seeing what’s happening along the way who are going to be implementing that work. Because often, you get to, to late a stage the dev team, or the person whose actually coding the feature you’ve designed come back to you and say, “Actually, this is completely impossible, or it’s not suitable, or this has just added another week to our schedule.”
So that’s something that really important to kind of … that kind of feedback loop, that feature design loop has to be designed in fact. And you’ve got to make sure that people have got their eyes on what you’re doing so that you just don’t spiral out into something that causes a mess.

Russ:

Yeah. I mean, I think sometimes the client feels that they can be the in between person, and they kind of sit between two teams and they’re fielding both sides, but actually you just need to connect those two teams together otherwise it only leads to problems.

Tom:

I mean, most of the times when we’re working on these kind of product makeovers, we’re working quite closely with the dev team and that’s ideal. But you do get into a situation certainly, when you’re with a kind of more enterprise client, when the person you’re talking to is potentially a project manager who is great, because we need people to manage projects, but that can … that barrier maybe, or that go-between between you and the kind of tech partner, that can often cause an issue.

Russ:

Yeah. I’d also say that the next thing that is crucially important is planning, and that usually breaks down into a backlog and a schedule that both teams can work towards. So usually in our projects we’ll have at the end a discovery a phase, we try to work in backlog of our top to-do’s that both teams can be looking at. There’s some instances where you might have two backlogs, one for each kind of workflow, but yeah, those are kind of different situations either side.

Tom:

Yeah. And I think it’s important to plan in a way that makes sense per team, per project. So we work Agile, so kind of Agile UX is something that we try and do quite a lot. I’m sure many people out there work in exactly the same way, and that really comes from the fact that most teams we’re working with, most product teams are working in exactly the same way. So we’re booking in tasks to carry out over the next week, two weeks, whatever the sprint length is, that directly feeds into their kind of product life cycle.
So it’s kind of important to assess the situation of the teams you’re working with, and try and fit in with them as best as possible. There’s no real point, it usually doesn’t work when you dictate how you want people to work. That kind of completely spoils the flow of how their product team works. So it’s kind of important, like I said, at the start of the project to assess how you’re going to arrange your workflow, and how you’re going to deliver stuff to the people that are going to be implementing the work.

Russ:

Tom, have you got an ideal sprint length yet? Have you found your preference?

Tom:

No, yeah.

Russ:

Okay, that’s good, yeah, yeah. A sort of giant project over a year, that’s a good sprint.

Tom:

You might call it waterfall. No, that’s a very bad idea obviously. Two weeks?

Russ:

Two weeks?

Tom:

I don’t know.

Russ:

I’m into one day sprints.

Tom:

Wow.

Russ:

The first one’s called Monday, and it’s got deliverables at the end, planning at the beginning.

Tom:

Retro on Tuesday, Wednesday, Thursday and Friday.

Russ:

Oh dear. Just kidding one week is the only sprint length.
Hey, this is Russ. Recently we’ve been helping our clients overcome huge complex problems using design sprints. It’s a really interesting tool for us to get in a room with a client, share this big workspace and come up with lots of ideas and solutions for big problems. If that sounds like something that you could be interested in head over to wearelighthouse.com for more.
I mean, in terms of managing a roadmap, one thing that’s obviously helpful for prioritisation, is how much effort an item, or a task, or a user story involves from each team. We’ve seen quite a few ways people have approached this in terms of assigning points, number of hours. I like low, mid, high traffic light system, but it’s important for anyone involved in the project to be able to order that list by the low hanging fruit versus high impact items that might take six or seven sprints to get to. But having a backlog that’s prioritised by efforts on both sides, that’s definitely the way to kind of plan your next few sprints.

Tom:

Yeah. We’ve often … When coming into a new project, obviously it’s quite hard because some of the things we work on are really complex. They’re tools that have existed for years, and we’re doing total re-hauls in some cases of the entire sort of design system of them. And it’s … When you’re kind of starting out, and know the least about a project or a product, it’s very hard to know what goes in the roadmap, so that weighted feature set at the end is something that’s really important, because it allows us and the product managers and the dev team to look at stuff, and kind of assess collectively what we should actually be working on. What’s the first step? What’s the most sensible stuff to do? Because if somethings got a huge dev effort, but is easy from a design perspective, having not done that weighting you might move down the wrong path and essentially start building something that’s impossible to implement.
Another thing that’s, and this just goes down to how you’d initially engage with someone, is that low hanging fruit idea is something that’s quite good to think about. So they might not be super major tasks, or might not be ones that completely bring immediate huge value, but as a way to test out your first sprint and see how working with this new team goes, just do a bunch of smaller tasks. What can you do really quickly and easily that simple from a UX perspective, and simple from a dev perspective, and just see how that relationship goes. Because it’s like anything, you can plan as much as you want until you do something and actually collaborate, you’ll never know how that relationship works.

Russ:

Yeah, definitely. Even just completing those smaller tasks gives you a bit of a velocity for your team, right? So what you thought was a small task, you now know roughly how long it takes for both teams to complete it, then you know how long you spend to do that kind of thing.
So yeah, definitely ticking off a few smaller items from the list makes a lot of sense in the beginning.

Tom:

Yeah. I mean, that’s an interesting point, because I mean, we can do entire podcast season on estimating probably. Everyone knows it’s one of the hardest things you can do, and I think velocity is a good word there, because you do want to just see how this feedback loop goes, how people mesh together, and just how easy collaboration is, and it’s just a great way to do that.

Russ:

Yeah. I think the last point to make there around prioritisation is, we tend to build a new backlog for a product by starting with the research phase. So talking to stakeholders and talking to existing users, and to finding the middle ground there of what’s important for both parties, and that gives us a nice kind of list of good reasoning why we should work on something. If you just came in blind designers would be saying, “Well, that doesn’t work very well, and this is rubbish.” And the developers would be saying, “Well, this framework’s outdated, we want a new version.” So actually coming up with the reasoning behind you’d be working on something first, settling that by what the users are saying makes a lot of sense as well, and gives that kind of external voice to settle those arguments.

Tom:

I suppose there’s only one more thing really to talk about, and that’s reporting on what you’re doing. So this is a really important thing, and I think we’ve been guilty of it in the past, and everyone out will really be kind of nodding along with us. That’s something that actually provides massive value to the team you’re working with, so you’ve got to be giving reports regularly on where you’re at, what’s happening. And that could be face to face, it could be calls, it could be documents you’re sending over. But we found that projects go a lot better when risk is shown early, a change in direction is communicated quickly, and just that you’re being open about how long things are taking, and how one task might be going over its estimate a little bit. And that’s something that’s just vital really to any team that’s kind of collectively working on a big complicated product.

Russ:

Tom, if you were to summarise those previous four points, how would you do it in a list?

Tom:

I can do it as four things in the list.

Russ:

Good.

Tom:

The four key things to think about are: communication, visibility, planning and then reporting. If you can get a grip on all of those, I think it stands you in really good stead to have a successful project. You’ll kind of notice that we’re not really giving a lot of solutions here, like the way that we implement stuff, that’s just how you do it. They’ll be different, and every projects completely different, but those are the things that I think are really important for people to focus on when working with any external team really, it doesn’t have to be a UX and dev team. But, implement that well, build a workflow that works for you and your client or your partner, and it should go swimmingly.
Thanks for listening. If you want more product leadership content, then head over to the Lighthouse site, wearelighthouse.com for more podcasts and blogs. To find out more about our product leadership framework, check out wearelighthouse.com/plf. Find us on Twitter using @wearelighthouse, and if you’ve enjoyed the show then we’d love a rating in iTunes to help spread the word. Don’t forget to subscribe wherever you get your podcasts to see the archives, and get any future shows.
Until next time, we’ll see you then.