Streamlining the Design to Development Workflow

Russ Drury at UXDX EMEA. Video: https://youtu.be/xyPw0f9rVWg

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Welcome to the splash zone

[00:00:00] Russ: My name is Russ Drury, as was just introduced. I'm from Zeplin, and in today's session we're going to talk about streamlining the design to delivery workflow. This is very much an interactive session. I'm going to require a lot of audience participation, so get your phones out, because we're also going to be doing a lot of polls. If anyone's been to SeaWorld before, or any water-based theme park, you know there's a splash zone. You are all in my splash zone. So I am probably going to pick on you. If you raise your hand, that will make it easier for me. If you don't raise your hand, I'm just going to come up and pick on you, and you can help us out.

[00:00:40] The purpose of this session is for you all to share. This is a networking session. I know how difficult it can be sometimes when you're at a conference and you don't know anyone. You may be here with your group of colleagues, your friends, and you don't get to meet as many people as perhaps you would like to. So this is an opportunity for you all to share. Sharing is caring. We're going to learn from each other today about how you do design to delivery workflows and how you implement that in your own organizations. The answers you give will help us move on to the next questions, and so on and so forth.

[00:01:17] I'm looking for a clicker so I can click through the slides. It's just coming. As I said, we're going to have a number of polls here, so grab your phones if you haven't got them in your hand and use the QR code. Okay, thank you, there you go, thank you very much. At some points I might stand behind this pillar, because it helps me not get dazzled by the lights.

How design and dev teams are structured

[00:01:42] The first question we're going to ask, just for a bit of context, is to understand how your design and dev teams are structured. This is different and unique across a lot of organizations. You might do it by product, if you have a multiple product strategy. You might do it by brand, if you have multiple brands. You might do it functionally, a squad model, whatever. So go ahead and vote on these, and then I'm going to start asking some questions and we're going to have raising of hands. I think we have someone with a microphone running around who's going to help us as well.

[00:02:26] It looks like a lot of people are cross-functional, and if by cross-functional you're thinking of the squad model kind of thing, I'd love to hear how that's working as well: the pros and cons, the benefits of all of this. The votes are still coming in, but it looks pretty heavily skewed towards cross-functional and product organization. We've got some runners here with mics. Raise your hands if you are organizing cross-functionally. Let's hear from you first of all. You can pick random people, Rory, I don't have a preference. Tell us about your cross-functional model.

[00:03:10] Audience: I work for Airtricity [?]. I manage the team. We work in a cross-functional team. We slightly changed the structure, because before we were part of the Scrum team, but now it's all under IT, and the UX team is under product. However, we have home energy and business centers, so we have commercial and domestic customers, and the team works for the whole portfolio. Even though we are not part of the Scrum team, we give support to the dev team from the start to the end, so it's an end-to-end process with them. But we work ahead of them, two or four sprints, depending on the project.

[00:03:52] Russ: Excellent. Awesome, thank you very much for kicking us off. Who's next? Who's also doing this cross-functionally? Raise a hand, find a mic. Okay, go for it, Rory.

[00:04:02] Audience: Hello. I work for a Swiss bank as a designer. We had a similar model to the previous speaker, but we found that we were too influenced by the devs: too much pragmatism, not enough spotlight on the researchers. So now we split even more. There are some designers with the devs, like before, but we additionally have a strategy department where half of the designers are, and all the researchers. We needed this change. Now let's see how that works.

[00:04:36] Russ: Okay, I'm going to ask you another question. How many people are in a constituted group, a team? How many people do you have in total?

[00:04:45] Audience: In strategy, per product, there are four people, more or less.

[00:04:48] Russ: Okay, good, great. Do we have someone over here? Yes, in the center.

[00:04:58] Audience: Previously we were organized as a centralized UX team, so we had really good control over what we were doing on a product. Now we have split it up and ended up in embedded feature teams. But some of us are still thinking cross-product and sitting on a lot of knowledge. Some of us are focusing just on their features in the feature teams, and the other people are really trying to break out of that focused area and think more broadly. So that's kind of cross-functional, and what is waiting for us in the future is more cross-product, cross-functional. I'm really struggling to decide: are we just product, or are we also heading to cross-functional and product? That's where we are now.

[00:05:52] Russ: So we have a bit of merging, a bit of blurred lines here. Cross-functional at the moment, moving into more product, but it will be cross-functional and cross-product.

[00:05:58] Audience: Yeah, it's going to be across product lines and everything. I really wanted more of that for the broader future, not for now.

[00:06:08] Russ: What's leading to that change? Has something changed that's leading you to change the structure? Is the organization growing? Are there challenges in the way you've got it structured at the moment?

[00:06:19] Audience: Scale-up phase. We had a scale-up phase the previous year, so we were working really fast, and then we messed up a lot of details, and now we need to clean up after ourselves. I guess that's why we got put in embedded teams. On the other side, yes, scale-up: big growth at the employee level, big growth at the customer level, the customers we got in. And it's also a top-down decision that we should have a really compact, good customer and user experience across product lines.

[00:07:01] Russ: So being driven by customer experience as well. Love that. Okay, let's go on to another one. I want to hear from some people who are organizing by product. It sounds like there might be some blurring and merging of these. Who's organizing their design, dev and delivery teams by product? Raise your hands. I know there's a lot of you, because you said so on the screen. Okay, person at the front here, go for it.

[00:07:27] Audience: How are we organized? We have overall missions, and within each mission we have specific streams, so we'll have teams organized that way. I oversee app design, so within that we're organized by search, then by growth, and then by initiatives, which is basically a filter for everything else that doesn't fit into the products. And then I think there's also sell, which is part of the seller mission. Those are the streams, and within them we have dev, PM and design.

[00:08:01] Russ: It sounds like quite a complex structure. How many people are in your organization? Because there'll be some people sitting here thinking, "Well, that sounds like a lot," but if you tell me there are hundreds or thousands of people, that might explain it.

[00:08:11] Audience: Including everyone, including sales, which is a big part, it's around 600.

[00:08:14] Russ: Okay, so not huge. Very good. Anyone else want to comment on organization? Is there a right way to do it? Do you feel you've cracked it? No comments? Oh, sorry, go on, on the side here. Oh no, okay, never mind. Not to worry, we'll come back to you.

How work is sequenced between design and dev

[00:08:37] Let's go on to the next one, then. I'm interested to know how work is structured for these teams. Again, get your phones out. There are a number of options here. Design works far ahead: I think we heard that a little bit a moment ago, where you work a couple of iterations or cycles ahead, a couple of weeks ahead. Design works a sprint ahead of dev. Design and dev work on things together: this is the nub of the session today. I'd love to hear where design and dev are almost in sync, in the same cycle, delivering and designing at the same time. And the last option is design is involved after dev has started. Shudder. Hopefully not, but hey, if that is your answer, I'd love to know. We have one person saying yes. Wow. Okay.

[00:09:35] It looks like predominantly it's the first answer: most people in design are working far ahead of developers, which is great. I'd love to know how far ahead, and if there are any challenges with that. And the next two answers look neck and neck. For the one or two people, because I don't know how many responses there were, who replied with the fourth one, that design is involved after dev has started, do you feel brave enough to put your hand up? I want to hear about how that's working. Come on, we're all intrigued by this one. Go on, I want to hear from you. How is it happening that you're doing the work after dev has started?

[00:10:14] Audience: We are working on a digital twin product, which is very big scale. When we UXers came into this company, we were actually kind of part of the QA. They had already made something and thought it was a bright solution, but they didn't really think about the user at that moment. So they got a lot of feedback from users about how terrible the product was, and then they hired designers. They had tried to hire consultants, agencies, before, but those looked at the problem and went too far ahead, so the developers couldn't deliver their vision. Then the company decided they were going to hire in-house UXers. When they hired us in, they just used us as QA, to fix whatever terrible feedback users came back with. That was two years ago, and now we are moving towards maybe the third one.

[00:11:24] Russ: Okay, so working about the same time.

[00:11:27] Audience: Yeah, but we are still trying to change it to the first one, of course. That's a current challenge, because of the mindset: they treat the designer as someone who just makes something sexy.

[00:11:41] Russ: Wow, okay. So that's quite a challenge, helping them to understand this is way more than just pretty pictures on a page.

[00:11:48] Audience: Yeah, and a beautiful prototype. So that's very challenging.

[00:11:54] Russ: Thank you for being brave enough to say that. I absolutely love that. Do we have anyone else who answered that as well and feels brave enough to say? Go on, I'm fascinated by this. It's the least-responded answer, but I want to hear this. Go for it.

[00:12:06] Audience: Maybe a different perspective on this. In super under-resourced design teams, one of the things I've tried to do is fill my developers with a bit of a design mindset, because there's just too much surface for me to cover. Obviously I'll tackle the important bits ahead of time and lay them out, but there are a lot of things where I trust people to make sensible decisions and then review them retrospectively. Obviously, if I had way more designers working in my team, I would totally be moving to the left there.

[00:12:42] Russ: Give us some context of size here, when you say you're short on designers.

[00:12:46] Audience: It's me. Actually, that's a lie. Two weeks ago we had a second product designer start, so now it's two of us.

[00:12:51] Russ: Have you got any open positions right now? There might be people looking. Brilliant, congratulations, I'm sure that will help. Two designers for how many developers? What's the ratio there?

[00:13:04] Audience: Six or seven.

[00:13:06] Russ: Okay, very good. Right, let's go back to the first answer, then, the one the majority, almost half of the people, said here: design works far ahead of dev. I want to hear how far ahead and if there are any challenges with that, because I think that's the ideal, right? It seems most people are working far enough in advance, but what challenges does that bring, and how far ahead is it? Raise your hands, I want to hear from you all. Okay, right here on the end.

[00:13:40] Audience: I tend to think it's best to get UX involved at pretty much the start of an idea. But the best work I've ever done is when I've worked closely with developers, so I think getting them involved from the start too, so that you can understand where they're coming from with how they're going to build it, and they can understand where you're coming from, is a really helpful thing. I guess if it's a year-long project, you might work a few months ahead, something like that.

[00:14:11] Russ: A few months ahead, very good. Any raises on a few months ahead? Someone else, did you have your hand up over here? Okay, we'll come to you in a sec. We've got one over here, go for it.

[00:14:29] Audience: He was just way too quick. Basically, I'm working on internet banking, and the way we are structured is that backend development and all of the impacts on the local bank are done within my teams, but the front end is centralized within a group of banks. That means the front end is done way ahead of us, very often without our involvement. So we're trying to really sneak our way in there with my colleagues who are responsible for design, and they're amazing, so that helps. We're trying to get in as soon as development for the other banks starts, to really have our hands on the product. And until it came to us, it was actually years. Depending on the feature, sometimes it's months.

[00:15:20] Russ: Did you just say years?

[00:15:22] Audience: Yeah, I did. Years. We've been doing development for a year and a half, I think, around that time, and we're not yet in production, but soon, hopefully. Cross your fingers. And there are challenges to it, obviously.

[00:15:41] Russ: Okay, wow. So we've got a year or more. Did you want to throw something in there as well? Right at the front here, thank you.

[00:15:48] Audience: Hi, I work at MongoDB, a database company. Since we're tech, lots of our projects need a lot of research, and we call them blue sky. For blue sky projects, we usually work one year or more ahead of the implementation. We usually start with one engineering lead, one design lead and a product lead to initiate the blue sky project. That's the most exciting part. Then we break it into a quarterly plan. Usually the design deadline is at least one quarter ahead of the beginning of the engineering implementation. So we actually have a combination of those, because in the process of a quarter we have an additional 20% of our time that we can work on the low-hanging fruit, or ad hoc things that come up when engineering, product or customers have some urgent fix. We can work together with engineers to fix those small issues.

[00:17:04] Russ: Brilliant, thank you. We've had a variety here. It's still much longer than I thought. You were the first person who said quarterly: we work in a quarterly cycle, which is why I can relate to that. Does anyone work in a really crushed timeline, much shorter than a quarter, dev, design, dev, design? Do you want to tell us a bit about that and how short that difference really is?

[00:17:28] Audience: I work for Piccolo Energy [?], where we are in renewable energy. Ideally we would be working one sprint ahead, so designers would have designed what they want one sprint ahead. But quite often they've only spoken to the customer last week, which means I've only got the raw materials for the design right now. For our current sprint, for example, which we planned maybe a few days ago, we literally said, "What do we want to do this sprint?" and then designed it in that session right there. So we're halfway between the in-sync one and one sprint ahead. We want to move more ahead, to one sprint ahead, but currently we're a bit in sync.

[00:18:12] Russ: So you're laying down the tracks just in front of you as you get there. What challenges do you have? I'm curious, because that is a much shorter cycle. How long are your sprints, a couple of weeks? Two weeks. What challenges do you have in laying down the track before you get there?

[00:18:28] Audience: It seems to work for now, but some of it is due to our customers. Our customers aren't always available to talk to, and because we work in a semi-regulated environment, with energy, we don't always have the flexibility to do what we want. We have to integrate with our customers and how their workflows work, so we don't always have that information available. They're not always available, so we can only build what we want for the customer once we have spoken to the customer.

[00:19:02] Russ: Brilliant, great, thank you very much. Anyone else got a short time frame in this cycle? Okay, over here on my left, your right.

[00:19:12] Audience: I work for Liberty Mutual Insurance in the fraud space. As you know, fraud is ever-changing. There are new ways to commit fraud, so we have to work really quickly. Currently we leverage models to detect the fraud, and these models get deprioritized and prioritized all the time. So I find we end up working in a very close time frame, nearly with the developers: the trend this month is this, so we need to get new data points into the UI. It's very quick, and to be honest, ideally we'd like to be the second one, given our industry and how quickly fraud changes. But we are sort of the green one. That's our goal.

[00:20:00] Russ: I've heard that a lot, especially in financials, and in pharma as well, where it's heavily regulated and you have to be very responsive. That's where the much shorter time scales occur. With fraud, obviously, if you detect a new fraud or some insecurity in the system, you've got to fix that pretty quickly.

[00:20:17] Audience: Right, especially because we leverage AI, and that's changing so quickly, with the new technologies coming out and different models being developed so quickly, that we end up working in that short time frame. We went to production this year, so I feel like we're ramping up really quickly to try and bring in as many fraud models as we can.

The most complex part of design to delivery

[00:20:42] Russ: Brilliant, brilliant. I'm going to throw in another question that's not up on the slide. If you ever have an opportunity to meet with me outside of this forum, I'll ask this question, because I'm fascinated by the answer. It's also a bit of research, because I'm talking on the main stage tomorrow about this topic, and I don't want to give too much away. But as I travel Europe, I'm always interested to speak to people and hear what the most complex part of their design to delivery workflow is. That's what I'd like to ask you before we have time for another question. What is the most complex part of the work you do in your design to delivery, and working with other people? Right here again, in the middle.

[00:21:30] Audience: There are probably quite a few, but for me it's making sure communication is kept up between the different departments, so everyone's on the same page. That's probably the hardest.

[00:21:39] Russ: Communication, absolutely. Anyone else? I'm struggling to see the splash zone at the back, but you're all safe for now, because these lights are blinding me.

[00:21:54] Audience: Hi. Sometimes we design ahead of time, one, two, three sprints ahead. But then when development happens, not everything gets developed. We agree on something, and then not everything gets developed. So we get to a point where we have designs done ahead of time, they get developed, and then the developers ask us, "Oh, this didn't work the way we were planning it," and then we have to design after the fact. So that's one challenge.

[00:22:30] Russ: So you're saying the capacity planning part of it, the planning and the iterative cycle of knowing how much is going to go into a period of time, a sprint?

[00:22:39] Audience: A very simple example: maybe we are designing a delete functionality, and it stops being delete and becomes archive. So the design might completely change, because maybe it's easier to do archive, and maybe that suits us better than delete. But we have to design it after.

[00:22:56] Russ: So one of the complexities is a changing requirement that then spurs on different work. Very good, I like that. Yes, right in the center here.

[00:23:12] Audience: One big challenge is planning for the unknown. We do a lot of planning. We do iterations, whether quarterly, or sprints, or whatever you do. We plan for the things we know at the moment. A lot of things change; changing priorities are one of the things. But you also have a lot of context switching. You're a designer, a PM, a developer, and you're working on a lot of different levels of context in the same sprint, the same day, even the same quarter. You have bigger initiatives, you have small things, you have feedback from customers, you have bugs, you have a lot of things. How do you manage that on a daily basis so it's efficient for your teams? That's where all these agile processes, lean, everything comes in, trying to help us with that. But there's no perfect solution. I have never seen a company that has cracked that. So that's one of the biggest challenges and complexities.

[00:24:01] Russ: I love that. So changing velocity almost in the moment, because things are uncertain and you're having to adapt. There's a concept of shrinkflation, where perhaps you're not getting as much into your delivery, you're not releasing as much, because you're having to deal with everything else that comes in as well. Brilliant. Another comment quickly, and then we'll finish off. Yes, over here in the center, the chap in the cap.

[00:24:26] Audience: Thank you. We work in iGaming, and we try to work on a design-a-sprint-ahead basis, but sometimes we need to be flexible with that. Every time we try to bring a new feature or a new redesign into the product, or if it's seasonal, that's where the challenges come from. You need to plan ahead and be ready for that.

[00:24:55] Russ: So keeping it on a flexible basis. Brilliant, thank you very much.

Communicating design intent and requirements

[00:25:01] Russ: Do we have time for one more poll? Let's go for it. One more poll: how do you communicate design intent and requirements today? This came up earlier, communication being a challenge, one of the most complex things. We hear this all the time. I want to know how you're communicating design intent and requirements today. Is it documentation? Is it conversation, design review meetings, daily standups, through tools, or the dreaded no handover? Factor into this, of course, that we're now in a distributed world, working from home. Lots of things to throw into that as well.

[00:25:44] All right, now this is interesting. About a third so far are doing it through tools, a quarter through documentation, and another quarter through design review meetings. Just by a show of hands, real quick: how many people here work from home, or work in a heavily remote-based company? Okay, quite a lot. I would imagine that has a huge influence on this answer. Maybe it was different a few years ago. So, tools. Let's talk about tools. What tools do you use to communicate design intent and requirements? Throw your hand up. I just want to hear a tech stack, and any challenges you have with it as well. Raise a hand, otherwise I'll pick on the splash zone.

[00:26:40] Audience: We use Figma.

[00:26:43] Russ: Figma, yep. That's your main tool for communicating everything?

[00:26:48] Audience: No, we use Slack. But Figma for the designs.

[00:26:52] Russ: Okay. What challenges do you have with communicating everything through Figma when it comes to requirements?

[00:27:02] Audience: We use Figma, and then we use a ticketing system. It depends on the client which ticketing system we use. For one client it's Azure DevOps. We use everything, because we're a vendor. Like your previous question, we do all the steps. We've done all of them, depending on the client.

[00:27:26] Russ: You do everything and you use all the tools. I'm not being flippant about this.

[00:27:30] Audience: Well, we're very flexible, because we just integrate into the customer's system. If they use Jira, then we use Jira. But internally we use Figma for our designs, and then we use Slack to communicate.

[00:27:45] Russ: Okay, very good. The chap on the second, well, third row here, behind you, sir.

[00:27:52] Audience: How's it going? We prioritize what goes into the monthly Scrum on Jira, and we usually have a discussion on Teams with the main dev for that. Then we actually use Zeplin for our documentation, which is what the devs refer to when creating a component or whatever it is. If there's any communication about something that isn't clear, that's done in Zeplin as well, via the comments. And if anything else has to be updated in terms of documentation, we do that in Figma and then re-upload to Zeplin. We just find keeping everything in Zeplin is the best place for component-specific communication with the dev team, because it prevents anything getting lost in Teams chats or emails or something like that. And you can always show the unresolved or resolved comments if something's missed.

[00:28:53] Russ: Brilliant, thank you. Do we have any more tool stacks? The lady at the front here again. What are you using to communicate?

[00:29:00] Audience: The design team is using Notion, actually, and Figma, a combination of the two. We use Jira for the development teams, but the designers really hate using Jira for the design work, so they use Notion for that. It's a bit of a combo, and then Productboard for product management. Integrating all of it is a bit of a mess.

[00:29:19] Russ: So how are you using Notion, then? I heard Figma, Jira, Notion, Productboard.

[00:29:26] Audience: There's a product space in Notion where the designers have their own projects that they work on ahead of time, where we collaborate a lot between developers, PMs and designers. And then Figma has the actual designs and user workflows. The difficulty with Figma, from my point of view, especially when you transition it to the developers, is that if you just send the link to the Figma file, they're going to be like, "Okay, what am I supposed to do with that?" It requires a meeting, or someone to walk them through it. You can't do it without some sort of communication.

The next five years

[00:29:58] Russ: Okay, good stuff. Anyone want to throw a hand up? Otherwise I'll go to the next question. I'm going to keep going till I get kicked off this stage. Three minutes. Let's go for one last question, then. We've talked about tools. How do you envisage changes in design and development workflows in the next five years? Working closer together, about the same, or working further apart? And I want to hear your answer with the why. Why do you think it will be different in five years' time? I'm not surprised by this answer. If anyone here answered working closer together, throw your hand up. Let's get some people further at the back, in the bright spots I can't see, or at the front. At the front's fine, let's do that.

[00:30:46] Audience: I think, given the accelerated pace at which we have to make changes, we need to get more and more responsive. The idea that you can be a quarter ahead is fading away. We're all seeing it. It's much more a case of fast changes, and to do that you have to be close together. If you're in a global organization like I am, that's tricky, because you don't get to huddle in one room with a whiteboard. We've got to figure out better ways to do it.

[00:31:13] Russ: Very good, very good. Can I just throw something in there, because I love that answer. But every person who was saying they were a design sprint ahead said they'd love to be a bit more ahead. So how do you reconcile that valid point about needing to work closer together with that frustration of laying the track as you're going? Does anybody want to take that?

[00:31:44] Audience: I think what we need to realize is that design and development are very intertwined. We're not separate teams, and that's where we've been up until now. But the future we're going to is just people with different perspectives coming in to do the same work. That doesn't mean design has to be done before development, but that designers and developers and the rest of product, and whatever stakeholders you have, need to work earlier in the process as a whole, to then come up with a solution that has followed that entire process and that you're working on now.

[00:32:27] Russ: Yeah, I think certainly from the developers' perspective, I know they're keen to get involved earlier in the process as well. Kind of the opposite of what you were saying there: we don't want it to skew too far, where they say, "Actually, you know what, we don't need the designers at all," because then of course there's a complete mismatch and a misunderstanding. All right, I think I'm just about done. Thank you very much, everyone. I appreciate your input today. If you have the opportunity to come back and see us tomorrow, I would love to see you in the audience. Thank you very much.

[00:33:01] Host: Don't go anywhere, Russ. First of all, thank you. This was really so much fun, and interesting to see how, despite us having these conversations for a very long time, we're still struggling with some pretty fundamental ways of working together and communicating. I really loved your question, the one previous to this one, about how you communicate design. And, not being mean-spirited but inquisitive, I would have loved to see how you communicate beyond the binary of design and development, how you combine that. There's a wealth of tools and a wealth of ways of doing this, but we are still struggling with it, and it's a good tension to have. Really good questions. Love the format. I love that everybody could participate.