Design Delivery Principles: Accelerating Product Delivery Outcomes in a Complex World

Russ Drury at UXDX EMEA. Video: https://youtu.be/s-zxGVrdFM0

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.

Introduction

[00:00:00] Thank you very much, everyone. Good afternoon, it's great to be with you here today. I am privileged to talk to you for the next little while, and I appreciate I'm the only thing standing between you and free pizza and other delectable meals out there. I'd like to introduce you to a few of our colleagues who are going to help me talk a little bit more about design delivery principles today. I want to introduce you to Bran. Bran's our designer. We've got Zo [?], our developer, and also [?], who's the PM. They feature a little bit in my talk today and help me to explain some of the points I'm going to talk to you about. They operate in a world much like you and I. They have to make product delivery decisions, and they are constantly fighting many of the battles which you all have internally. The only difference between them and us is they live in a 2D world, which is far simpler in that respect.

[00:00:57] As I said a moment ago, I'm in awe of all of you. I find it a great privilege to meet with design, product and engineering experts like yourselves. We have wonderful researchers here who I've met today. I'm not from that background; I'm more from a business and software background, and so I find it fascinating to learn from you. I have been doing this in the design industry for the last five years, and I've had the privilege of being able to travel Europe, go to big brands that we'll recognize and use every day, go to their offices, meet with them on Zoom, meet them at conferences. I love learning from you about the way that you do your work and the way that you do your design delivery job.

[00:01:47] It's really interesting, because I do not consider myself a creative person by any means. Put me in front of an app to build or a site to design, and you'd probably end up getting something that looks like the Amazon site from the 1990s: buttons and ads and cards all over the place. I wouldn't have a clue, nor could I write a single line of code. But I aggregate all of these stories, and what I'm able to talk to you about is the things that I've learned over the last five years.

The complexity that kills us

[00:02:16] First of all, I want to pick on a couple of visits that I made right before COVID. I had grown up flying on an airline from a very young age, by myself, when I went to visit my dad in America. I won't tell you which airline, but I was somewhat of a fanboy of this airline and had been using their products, their apps and their website for many, many years. I had the opportunity to go and visit them at their head office and sit around the table with the designers who were building the designs, and the engineers for the products that I used very frequently.

[00:02:54] I tentatively and nervously asked at one point, "What's the most complex part of the work that you do?", knowing that they didn't have the most seamless experience for a user between their mobile app, their web experience and also in the airport. It's fair to say they could easily have been confused for completely different companies at times, even within the same web experience. The response came back: "Russ, we've got so many challenges with things outside of our control. The systems we work with are so complex. We have to deal with teams who don't even sit in the same office." And this was before COVID. "We're having to work across global boundaries." In the airline industry, if you know anything about it, they have antiquated, ancient systems for booking, which they had to connect to apps and websites in modern-day technologies, and it was incredibly challenging for them. The most resounding part of what they said to me was, "It's the complexity that kills us. We want to be able to do more, but we just cannot."

[00:04:13] Another story was when I was visiting a large sports brand of the German variety. They were launching apps for two very well-known global superstars, one by the name of Beyoncé, and one we'll call Yeezy, because he goes through several names. The experience they had with these two individuals was vastly different. With Beyoncé, they were able to iterate very quickly; it was very responsive. With Yeezy, less so, because of the layers of people that they had to go and speak to. What they found is that because of the interactions that they had, they were able to deliver less and less.

Delivery shrinkflation

[00:04:57] Growing up, I used to look forward to Easter every year. As a young child, I'd get a box of Cadbury's Creme Eggs. My dad would share them out, so I'd have one, my sister would have one, my mom would have two and my dad would have two. And I thought, great, when I grow up I get to be the dad and I get to have two. Fast forward, and I'm now a dad. I give one to each of my three children, my wife has one, and I have one. Wait, that's not how it's supposed to be. I'm supposed to have two, right? This is shrinkflation. We see this in life, and so it is with the work that we do as well. We have what we see throughout our jobs known as delivery shrinkflation: the more we try to deliver, the more we find that, through complexity, we're actually delivering less and less.

[00:05:55] If you're like me, you will have a tech stack that looks something like this. You could probably name at least half a dozen tools in that tech stack that you use today. We've got our Sketches, our Figmas or XDs. We've got our zeroheights, our Slacks, our Jiras, our FullStorys. Outside, we've got our Dovetails, our Mazes. Brilliant tools, but with them comes increased complexity. Often what I will hear people say is, "Oh, it's all right, we'll just reduce the number of tools that we've got, and that will reduce the complexity." Let me let you into a little secret: it's not about the tools. It's not about how many tools you have.

Why complexity has increased

[00:06:51] It's all because complexity has increased. We've heard wonderful talks throughout the last couple of days about many of the expectations and requirements that users have of us, and they have increased in their complexity. Users expect more and better features. It's not enough to be constantly releasing; they expect things to be getting better and better with every release. I'm sure, like us, you have heard, "Why can't you be a little bit more like such-and-such a tool?" or "Your competitor does this. When are you going to introduce this feature as well?" We're constantly being compared to others that do similar things, and that in itself creates pressure and complexity.

[00:07:44] Everything now is smart or AI, and I can't tell you how much I have enjoyed the talks over the last couple of days about AI. I had the opportunity several years ago to meet Brian Cox, and he was telling me about things of the universe, and I was lost in 30 seconds. I felt a little bit like that today when Fergal [?] was talking about all of the great things that Intercom are doing with AI. I could have listened to him for hours. Did I understand all of it? I didn't. But I knew how it impacted the product teams who are having to deliver it. We heard similar stories from Steve earlier, and yesterday from Ricardo and Pamela, as they all had you stand up when asked, "Have you been asked to introduce AI in the last six months, one year, two years?" These are new technologies that you're now being asked to implement and integrate into your tools. Sudev [?] yesterday talked about speed, and how speed is now an expectation in every tool and everything that we deliver. People expect things much faster.

[00:08:53] The other challenge we have is in the way that people use our products. Quite often we will spend more time designing for the ideal customer journey. We know what we want customers to do in our apps, our products, our sites, and so we tend to build for that and spend the most time on it. But as we're seeing, people are actually using our tools and products and apps in different ways, in more organic ways, and because of that innovation and evolution, that is placing greater strain on us as well.

[00:09:27] I think it was mentioned earlier today that we probably can't talk about COVID much longer, but of course we do need to give a nod to the fact that working practices have changed. I've been working remotely for, I've lost count, 13 or 14 years. But when everyone all of a sudden became remote, that placed greater pressures on all of us, and the complexities of having to deal with colleagues in different time zones and different countries, not least if you were outsourcing to different countries and to people who weren't necessarily part of your organization. We've seen a shift from colocation to remote to partial location to hybrid and back to the office, and all of these changing working practices are placing greater pressure on our expectations.

[00:10:14] Also, we've got the structure of teams and organizations. Something I'm hearing a lot more these days, and certainly as people have spoken here at UXDX, is team structures. In the forum session yesterday we talked a little bit about how team structures are moving more towards a design-dev hybrid combo, where we actually have designers who are somewhat technical, and engineers who are having a greater input into the design as well. The lines are blurring, and because of these blurred lines and the working practices, complexity is coming around.

The Doherty threshold

[00:10:54] I'm a big fan of the Doherty threshold principle. Walter Doherty, in the 80s, was looking at ways of speeding up the ways in which computers were responding and connecting to one another. What Walter Doherty and his colleague were trying to do was reduce the response time of computers from 2,000 milliseconds, or two seconds to you and I, down to 400 milliseconds. Anything that they were able to achieve that bettered 400 milliseconds was said to exceed the Doherty threshold. In our world of UX, it's clearly stated that the Doherty threshold suggests that productivity soars when people interact at a pace that ensures neither has to wait on the other.

[00:11:50] So that is the goal of what we're going to try and do: identify ways in which you can implement the Doherty threshold in your working practices. This will in turn reduce the pain of the complexity that you see in your work. When we exceed the Doherty threshold, we are said to enjoy things more. We are said to find them addictive, and we want to do them a lot more, and so we become more productive and more efficient in the work that we do.

[00:12:22] As I talk you through a few of these things, I want you to think about your own organizations. We've identified three. There are a number of hidden forces that are impacting your work and your ability to work at speed, and with a few simple tweaks we're going to be able to help you exceed the Doherty threshold. We're going to be able to help you identify ways of doing things faster, where you're not having to wait on people as long. These three things are, first, understanding design intent and requirements; second, changes and approvals; and third, measuring adoption in production. As I'm talking, perhaps rate these in your mind: good, bad and ugly, 1 to 10, maybe on a time scale. How can you reduce some of these things?

Hidden force one: understanding design intent and requirements

[00:13:17] Hidden force number one: understanding design intent and requirements. It doesn't matter how fast you are able to design something if someone then needs to understand the work that you're handing to them and they don't. This will typically require greater clarification, and you'll all know this. You will perhaps spend much more time in design review meetings, Slack messages, emails and conversations to clarify the things that you thought were quite simple. Or, worse yet, you're having to invest more time than the design work itself in making it clear for other people.

[00:13:56] You can get this down to 40 minutes, and this is because we have analyzed hundreds of companies across the world who are struggling with these exact challenges. The way in which we can reduce the time it takes to clarify design intent and requirements is by organizing your work in a standardized way. I've had the opportunity to talk to so many people just today and yesterday who have confirmed that this is a pain for them. Because the designs are organized according to your own preferences, and the people receiving the designs don't have that organization, they struggle. Additional clarity is required, and there is wasted time going back and forth understanding what is actually meant. Worse yet, if they don't understand what is meant and they need to start working, sometimes they go and implement the wrong thing.

[00:14:51] We saw this at Microsoft a few years ago. I won't tell you what release it was, but they had a major product launch for one of their products where the developers implemented the wrong design work and requirements because they didn't have clarity, and it was actually fairly well publicized as well. It cost the company 1.5 million. Now, I'm sure for Microsoft that was small change, but 1.5 million is a heck of a lot of money in my world. So: standardize your designs and organize them in a structured way, and a significant part of that is making sure that you separate the in-progress design work from the finalized, ready-to-build designs. That's principle number one.

Hidden force two: changes and approvals

[00:15:38] Principle number two: changes and approvals. When a piece of design work is done, is it really done? The reality is we know it's not. The design work is done, but we know that quite often something needs to be reviewed and approved, and there are changes and iterations. It might then need to go to other stakeholders, to product managers, to legal. This review will undoubtedly result in tweaks and changes, which may not be huge, but the first iteration of a design is rarely the last.

[00:16:15] The hidden force we want to highlight here is that, through the analysis we've done, 70 minutes per designer and developer per week is spent going around this iterative cycle. What we believe is that this can be reduced down to 15 minutes with one very specific thing: tracking changes to shared designs deliberately. Far too often we leave this at "I've made some changes, go and do it," and the person receiving that work doesn't understand what has changed. So be very intentional and specific about publishing changes, and make that information known to the people who are going to make the changes. You're probably sitting here going, "Russ, yeah, I know all that, that would be great." None of this is rocket science, but this is what we have seen from hundreds and hundreds of companies.

Hidden force three: measuring adoption in production

[00:17:11] The third thing: measuring adoption in production. I loved Ranna's [?] presentation just now. She and I had the opportunity to meet and chat several times over the previous weeks, and I'm going to take the title of her talk and tweak it slightly for the purpose of what I'm talking about: innovation without adoption is meaningless. She's talking about features; I'm talking about everything, and design systems as well. 90% of the designers we speak to say that there are differences between what they have designed and what is implemented in production, and it could even be more than that. What you design is just the vision of what the experience will be for the customer. If it is implemented poorly and it gets into the hands of the end user, production is what they end up experiencing.

[00:18:12] We've seen that measuring adoption takes engineers months, not even days or hours. It takes them months to measure what is in production and then work back and see the impact of that on their business. All of this complexity and lack of visibility results in the dreaded technical debt. The dreaded technical debt then balloons, and the cost of that is huge.

[00:18:44] Some of you may have heard of the 1-10-100 principle. If you catch the bug, the error, the mistake in development, it will cost you the arbitrary $1. If you miss it in development and it's not caught until the QA and testing phase, it's going to come at ten times the amount, because essentially you will have to fix it, reimplement it and retest it, and it's become a problem ten times greater. If it makes it into production, it's a hundredfold that initial problem, compared with if you had found it, identified it and fixed it right up front. The 1-10-100 problem is real, which is why it's so important that you are measuring what is in production and working backwards to ensure that you can eradicate it earlier on.

[00:19:37] Many of you will know this chap. He's the Jedi master of design systems and design thinking: Brad Frost, the inventor of atomic design. He recently published a blog post where he said this, and I love it because it clarifies what we think about when we hear "design system". I've had this conversation with several people again over UXDX, where I've asked about their design system, and sheepishly they've said, "Oh no, we don't have a design system. We'd love one, but we don't have one." Kind of like Ranna [?] was saying earlier, you think you're alone until you hear what everyone else is doing. There are a lot of people who don't have design systems, and it's OK.

[00:20:21] As Brad Frost says here: while a Figma library is super helpful for designer efficiency, and I agree, the true source of truth for a design system is a library of coded components that build real digital products. After all, the only thing that really matters at the end of the day is the actual user experience human beings interact with. What he's saying is that your production code is the source of truth, not your design system. So if you're feeling bad that you don't have a design system, don't worry, you'll get there, and it will be an important step for designer efficiency. But in terms of customer experience, what is in production matters the most.

[00:21:07] So how do we do this? Measuring design system usage, and I use the term design system to represent what's in production, measuring it while it's in the wild. Component adoption is nearly impossible to achieve if you are not measuring it. By measuring it, you get to avoid wasted time and inconsistent UX. If you're making changes, you can potentially reduce unexpected bugs. You can prevent and reduce customization, and customizations are one of the biggest challenges we see to a clean and efficient product, app or website. To repeat what Ranna [?] said earlier, innovation without adoption is meaningless.

Summary: simplify your interactions

[00:22:01] Let me summarize again the three hidden forces. Hopefully, in your mind or on your piece of paper, you have noted where you are today in these three areas: understanding design intent and requirements, changes and approvals, and measuring adoption in production. There is so much wasted interaction time that we can reduce, and that will help us become more efficient in the complex world in which we're operating.

[00:22:34] I want to leave you with this one thing. I'm a big reader; I love reading. If you were to buy only one more book for the rest of the year, this would be my recommendation: Essentialism, by Greg McKeown. Brilliant author, brilliant writer; he's done a few books. The principle of essentialism is about reducing all things to the most essential, and he says this: it's not about how to get more things done, it's about how to get the right things done. It doesn't mean just doing less for the sake of less, either. It's about making the wisest possible investment of your time and energy in order to operate at our highest point of contribution, by doing only what is essential.

[00:23:21] Martin Riley gave a great talk yesterday, and in it he said complexity is a trap for clever people. We are all operating in a complex world. Look for ways to simplify your interactions with other people, and that in turn will enable you to ship and deliver better products faster. Thank you very much.

Q&A

[00:23:47] Host: OK, if you can all just stay put for the questions. We have ten minutes of questions, maybe a little less, and I'm really looking forward to asking Russ some questions. Russ, a question from myself first of all: what has been the most innovative way that you've seen teams use the product?

[00:24:08] Russ: Our product? Yeah. Ah, man. One of my favorite ways: we all, or a lot of us, sit around Disney+ at home. With my kids, I sit around watching cartoons far more than I should. If you think about the platform they have in Disney+, all of the different brands, all of the different shows, they were really struggling to get a hold of their design system. They were using our tool, but they were using other tools to track and organize, in a consistent way, all of the different components that they were managing across the Disney+ platform, Hulu and others as well. They were able to gain significant efficiencies. I just love the story because, like I said before, it's brands that I use day in, day out. Disney+ is a big one in my house.

[00:25:00] Host: Yeah, that's great if you can bring it home. OK, we'll start with the questions from the audience. You touched on the topic of reducing complexity in terms of tools, but I missed how you do that. Can you elaborate?

[00:25:11] Russ: Yeah. I'm a big fan of tools; as I said, my background is in software. In our personal lives, we're in an economic environment at the moment where we're making personal decisions about budget in our households. Should I keep Amazon Prime? Should I keep Netflix? Should I keep Disney+? Should I cut this out, should I cut that? At some point in my personal life, I just need to stick the kids in front of Disney+, and so the value for me is greater than the tool itself. I talk about this in the micro sense because we're seeing a lot of those decisions being made in the macro world. In your businesses, you have tool stacks like the big long list I showed earlier, and people are going, "I'll cut that, I'll cut that, I'll cut that." They're missing the point that the value of having the tool is greater than the monetary value of cutting it.

[00:26:06] Russ: So in terms of reducing complexity, yes, of course you can reduce the number of tools, but as I said before, it's not about the tools. A lot of these tools are best in class and fit for purpose for the jobs that you're trying to do. Now, if you have three of the same tool, and I won't list them because I don't want to offend anybody, but if you had three metrics, analytics and reporting tools, then yes, you could probably reduce the number of tools you have. But just reducing tools for the sake of cost cutting can actually have a detrimental effect. So I would say, make sure you identify the tools that are important to you and adding value to you, even if it's only incremental value. Keep them, and do your job really well using them.

[00:26:53] Host: OK, very good. How do you measure the usage of design system components in production, and what are the tools that you use?

[00:27:05] Russ: Yeah, a really important one. The way we would do this is you would look at the components that are in use in production. Essentially, you're scanning the code repository. You're looking at the number of instances of those across all of your apps, products, sites and so forth, and you're identifying which ones are part of your core components and which ones are perhaps custom components. You're then analyzing and making decisions about those custom components, to see if they are indeed necessary, if they can be removed or eradicated, if they're introducing technical bloat to your system, or indeed whether maybe you need to bring them into your core components and build and maintain them.

[00:27:49] Russ: In full disclosure, we have a tool called Omlet [?], which we build and sell. It's actually been in beta for the last six months or so, and it's going live in GA next week. We use that ourselves, first and foremost, because we recognized that there was a problem for other people. To expand this further, what we have seen other people use instead is very manual things like React Scanner, which scans and scrapes your whole code base. But as I said before, it requires a lot of engineering time to then connect it to a BI tool, a visualization tool, that has to be maintained, and typically that has an overhead cost of a number of engineers. So that's what we use, and that's what I've seen other people use in the process as well.

[00:28:35] Host: OK. And how to guide a dev team to implement a more like-for-like production UX solution?

[00:28:45] Russ: Not sure I understand that.

[00:28:48] Host: OK, we'll move on to the next one. Someone can come and see me about that. What if designs cannot be implemented by developers? Should designers take this into account and adjust the designs?

[00:29:03] Russ: There's the technical limitation: if it can't technically be done, that's different entirely. I think a significant part of this is collaboration and communication, and the documentation that comes with it. Yesterday, in the other room where we had the forum, we were talking about how closely teams work together and how far in advance the development and design work was being done. What I'm hearing from you all is that if you're working at a cadence where it's far enough in advance to be able to plan, you'll come across some of these challenges and you'll be able to resolve them. But if the design and the development are being done too close together, iteratively, in weeks or sprints, this does slow things down quite a lot, because challenges come up and you're not spotting them until the moment of implementation.

[00:29:55] Host: Exactly. OK: people share screenshots instead of links to tools like yours. How do you think companies can better adopt Zeplin?

[00:30:05] Russ: Well, that's a big question that we haven't necessarily got hours to go over, but I could talk to you for hours. I do hear of people sharing screenshots, and going back to one of the things I said before about documenting design intent: if you're sharing designs and they're not in the context of the flow, not in the context of the design, you're having to put more effort into explaining, and more effort into actually building that documentation. So you certainly need to get away from using screenshots and very manual pieces of organization. From a Zeplin perspective, having everyone in there helps. But I want to be fairly agnostic. I'm from Zeplin, but I know that there are multiple ways of achieving this. What I'm talking about more is the principle of making sure that design intent is communicated in context, wherever you are.

[00:31:03] Host: OK, we'll keep going. How can research help in mitigating these three factors that are slowing down teams?

[00:31:11] Russ: I need clarification on this as well: research with the customer, or research internally? I'll assume we're talking about customer research, UX research that you do in the market. I think what that does is give you greater clarity and understanding of what the requirements are. We've got tools like Dovetail and Maze. We use Dovetail internally, and that helps clarify things a lot for people. Because of the research and the shared understanding that people have, it clarifies a lot of the misunderstanding when it comes to the approval and review challenge. I think research is really about understanding the requirements of what you're trying to build in the first place. We call it hopium in our company. If you're acting on hopium, that something's going to be useful, is going to work, or you hope that this is a feature, that's where you can have a lot of challenges when you're actually building something, and it tends to go through these cycles a lot more often.

[00:32:14] Host: OK. And how would you differentiate yourselves from Figma, and how would both tools get used together?

[00:32:23] Russ: I'm so glad someone asked, right? It's almost like an elephant sitting in the corner of the room, and at some point someone was going to ask this, so I really appreciate it. We use Figma at Zeplin as well. Figma is an excellent design tool. Before I worked at Zeplin, I worked at InVision; we saw how that went. Figma has very much changed the design industry. It solves design challenges for designers. I love it. As I said, I'm not a designer, but I try to use it as best I can. Figma is a design tool meant for designers, with a creative infinite canvas that allows you to innovate and create freely at will.

[00:33:05] Russ: Zeplin is a design delivery platform that comes after the design, and the key part of it is knowing when to separate the in-progress design work that you need to continue to iterate on, which happens in Figma, from the delivery work, which needs to be implemented by people from engineering, from product, from QA, who need that certainty, need that definition, need that intentional action of "here you go, go and do." As I said with the example of Microsoft, we have seen companies who don't have that structure and formation implement the wrong things. You've got the 1-10-100 principle, where you then have to go back and redo work.

[00:33:46] Russ: So Zeplin is the design delivery platform that enables you to connect to the stakeholders within your organization. I know that Figma are trying to achieve certain things in that area with Dev Mode, but they still have the fragility of the infrastructure, which is the infinite canvas and the freedom and the unlocked work. Again, I'm happy to talk to anyone about Zeplin and Figma all day long. Folks have been telling me over the last couple of days that they still struggle with scaling Figma when it comes to implementation. For design work, love it, great. It's the implementation.

[00:34:27] Host: Yeah, some people were asking the same question as well, about what you use internally. Are you using anything else besides Figma?

[00:34:32] Russ: Do we use anything else aside from Figma? We use Figma, we use Zeplin, we use Jira, we use Jira Product Discovery boards. We just left Productboard. Those are our main tools in the design-to-delivery process. We use Dovetail as well; I talked a little bit about that. So yeah, I'm unashamedly a Figma user. We are as well, and we use it because it is, in my opinion, probably the best design tool that's ever been around. I'm not shy about saying that.

[00:35:08] Host: That's cool. Listen, Russ, I really enjoyed it. I'm looking forward to seeing your Omlet [?], and these guys are looking forward to their lunch. Thanks a lot. Would you please give a round of applause for Russ? Thanks, Russ.