Good Design is Never Done

Robert Zikry at UXDX Community: EMEA Series: Design Process. Video: https://youtu.be/fdBSmZ14oFI

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.

Why iterative design, and a story about a bridge

[00:00:00] For our talk today, it's about how iterative design happens in large organizations, in product companies and tech companies, and how good design is never done. As product and UX designers, we often find ourselves dealing with a lot of concepts in the process that we are producing those designs: the Double Diamond, the Jobs to be Done theory, continuous discovery, definition of done, product market fit, feedback loops and many more other concepts that are necessarily relevant to how we produce a product that's relevant for our customers. But on the surface it doesn't look like it's related to the specific design process or the craft of design. Hopefully by the end of this talk, if everything goes well and if my internet holds up, we are going to clarify how those worlds belong to each other: continuous discovery, continuous delivery, continuous design, and the mindset behind that iterative design process when we are shipping software.

[00:01:14] But first let's start with a quick story, which is in Canada, near where Paul was telling his story earlier. It's a story about the Quebec Bridge, which at the turn of the last century, in 1903, was meant to be the longest cantilever bridge span in the world, which is a huge engineering marvel and a project that was aiming to break records. As you can see, this middle span is 1800 feet long, which is almost 550 meters long, which is nothing that was heard of before.

[00:01:52] And in 1903, as the work had been progressing and the bridge was taking shape, people were going through all the plans, and the engineers and the workers and everyone was working hard on building that bridge. However, knowing how complex this bridge design was, unfortunately a lot of those design, engineering and structural calculations were never double checked or properly checked within that completion for the design, and that created a massive risk on the whole project.

[00:02:31] What we know today is that in those initial designs the bridge's own weight was far too heavy for that carrying capacity, and as you can imagine, in summer 1907 disaster struck. Near the end of the day's shift, after 86 workers working hard on that project, 75 people lost their lives, unfortunately, and the rest were injured. It was such a disaster by any measure.

[00:03:06] And after inquiries and investigations, they understood that the real problem was those measurements, those designs weren't adding up, and they fixed that and they commenced the work in the year after. And unfortunately, for the second time within less than 10 years, another disaster struck, and the middle span, the central span of the bridge fell again, killing 13 workers, falling into the river.

[00:03:41] Knowing what we know today, those designs were risky, and the engineers, and the chief engineer specifically, his name was Theodore Cooper, was responsible for that disaster, because he took it lightly, he didn't go through the details, he didn't look at the designs, look at those calculations and give it the respect that it deserves.

[00:04:04] And to commemorate this kind of disaster and make sure that everyone is thinking about the responsibility they have in their hands, a popular story was that within that collapsed bridge, steel and iron, all that was broken apart and reused to create iron rings. Right now, I think many Canadians in the call might relate to this ring, that it's being worn by all graduates from Canadian engineering schools, to respect not only the death and the disaster that has happened building that bridge, but also to make sure that it's a good reminder for people to check their designs, check their calculations, double check once and twice and thrice, and as a symbol, a reminder of those ethics associated with the profession.

Design used to have a done state

[00:05:02] Thankfully our design discipline at the moment in tech doesn't require a lot of risk, or deal with that kind of life-saving risk, except of course if you are designing software for airplanes or something that can cost people's lives. But not only bridges, and design where designers and engineers have only one chance to do it right the first time around. If you can see all the design disciplines at the moment, they tend to get it right the first time, even though there are no lives at risk. Almost all forms of design can't do anything about their creation once it's been shipped, once it's been done.

[00:05:49] Design as a discipline has always had a done state: print, industrial design, interior design, product design, architecture and fashion. And that residue of a state of done, for example if you went a decade ago, when you see Photoshop files or Sketch files having final_V1, final_final_V2, there is always this final state in design, and that residue was actually coming from that background. And designers and product teams have, necessarily for those disciplines, to wait for the next year cycle where they can do anything about their creation, leaving the customers with outdated designs from last year.

[00:06:38] So the thing with design right now is, in any form of design or problem solving it's always a function of how flexible that medium is. So the less flexible or malleable that medium is, the more difficult it is to see a product being iterated on. Sometimes we're designing for atoms, like bridges or architecture or a mug or a chair, but some other times, which we currently are facing in the software industry, we're designing for electrons, for bits. And the beauty about that is, we're designing for software, it's in the name, it's malleable. Software design is flexible in nature, and we have to embrace that flexibility, because that's the medium that we're dealing with.

From waterfall to Double Diamond, and where they get stuck

[00:07:28] So how do we approach iterative design? A quick walk down memory lane. If you can remember a couple of decades ago, with the classic waterfall model we had the define and the speccing and the design and the requirements. It would take a few months to do, and then the engineers would go off for a few quarters with that handover, very little collaboration. They might be sitting in different departments, different buildings, maybe different countries. And then they ship at the end of the year, big deployment, big bang, hit or miss. A couple of decades ago, very little impact measurement, so it's usually hit or miss, and then they start over the next year working on the next version.

[00:08:17] Usually they would ship the software in something that looks like this, on a software CD, and the CD itself was the product, rather than the software on it. So you would see the business talking about the impact that they have sold x amount of CDs, rather than what kind of behavior we have changed through that software that we shipped, or what kind of problems we have. So it was very difficult to measure the impact.

[00:08:46] But about a decade ago we started to see the humanization of our design process, and how now people are embracing the discovery and the research process and prototyping and testing and iterating, which is trying to make sure that we don't leave any rock unturned, we validate every assumption. But it's still biased toward getting it right the first time, a very big investment at the beginning before handing things over to our engineering teams, and eventually they ship, hit or miss, they iterate.

[00:09:23] But that whole industrial-like assembly line was becoming a bit of a blocker for product teams, because the software industry was not meant to be that rigid, it was meant to be iterative. And software engineers were actually the ones that wanted to ship faster, and that's why they invented or came up with the Agile Manifesto a couple of decades ago.

[00:09:50] On came the Double Diamond process, which, as Paul mentioned, is a very solid process, it's actually a very good design process. But sometimes, if not used well, it's quite linear. As you can see, you go diversion, conversion, diversion, conversion, on problems and solutions. And sometimes if we follow the process as rigidly as we can, we might end up being lost in the process rather than the outcome of that process. The outcome is to define the right problems and solve those problems using the best solutions, so the idea of coming up with the best solutions requires iterations.

[00:10:31] And for the Double Diamond process, people who are embracing it, it suggests that for every act of definition there is an act of execution. But sometimes when you define a problem, sometimes problems don't really need to be solved, or some solutions don't really need to be pursued. So it's not clear, if we came up with a solution that doesn't work, where do we iterate? Do we go all the way back, like start all over, explore more problems, or do we go to the next best solution in the list?

[00:11:01] So you would usually find designers iterating on their designs, keep shipping more designs, coming up with multiple variations of that design, or coming up with concepts, testing it with customers, without actually shipping anything. And when it's coupled with an agile delivery process, you will see a big chunk of discovery and definition and user testing and development on those solutions done up front, and then almost like a waterfall handover going to the engineering teams, where they want to go for an MVP. They ship an MVP, they slice it, they fix it, they ship another slice, they refactor that MVP, only to find that they need to pivot, or there is a completely different opportunity in the market and the product that they have really discovered well and they coded well no longer fits the need or fits the market. Which is not really an iterative approach, but rather a big bang discovery and a big bang delivery, but just being incrementally shipped.

You can only iterate on something after it's released

[00:12:09] So Jason Fried, the founder and CEO of 37signals and Basecamp, has said it really well: you can only iterate on something after it's been released. Prior to release you're just making the thing, so even if you change it you're just making it. Iterating is when you change or improve after it's out. So if you want to iterate, ship it.

[00:12:35] And for that to work, the end goal for us is to ship faster, ship frequently, and have properly defined metrics of the problems that we're trying to solve, so that we can iterate better. Good design is a function of the time it takes us to ship, and that's why sometimes some companies over index on code reusability, on design systems, on CI/CD, making sure that every part of the whole ecosystem works well together. Not for the sake of quality only, and making sure that we are shipping quality code and shipping reusable, componentized designs, but also to make us ship faster, because the only way we can iterate on our solutions and figure out if they are working or not is if we ship faster.

[00:13:23] So how do we ship faster and more frequently? It starts by changing our mindset. We are no longer working in a linear process, it's iterative, it's continuous, and it starts with shipping. We are no longer working with the main idea behind, we need to do the designs, we need to check it, double check it, back to the ring and back to building bridges. We no longer need that, it's not necessary anymore in the software industry. We need to do just enough research on the riskiest assumptions and the most expensive and irreversible decisions, make sure that we get those right. We uncover opportunities and we de-risk the mission that we are after.

[00:14:08] And we do just enough design, making sure that these designs are all our hypotheses. So it's informed guesses. We can never know if those designs work unless we ship it. So we ship those solutions, and it's not about shipping code, it's about shipping experiments. And we do just enough validation in reality, in actual code, and everything we ship is a test, an experiment that can be successful or not.

[00:14:42] Which brings me to a very important point: unsuccessful experiments are not failed experiments. Unsuccessful means that we believed that this thing will work, the solution will work, whatever it was, maybe change the label, change the button, change the screen, or completely prevent[?] a section, and it was unsuccessful. But just the fact that we learned why it's not working and how we can make it better, and we have a very good idea where to go from here, makes it a good experiment.

[00:15:16] Versus the failed experiment, where we learned nothing. We just shipped, we have no idea why it didn't work, or worse, we have no idea why it worked. And that's actually dangerous, because if you ship something and you have no idea why it's working, it will be a big blocker for you to revamp it, because you are trying to keep it and uphold it, not to touch it, because it's working and we have no idea why it's working with our customers or why it's serving their needs. We do enough research on it but we don't want to revamp it. So that's the difference between unsuccessful experiments and failed experiments.

[00:15:52] Which Winston Churchill said it best when he said, success consists of going from failure to failure without loss of enthusiasm. We have our mission, we know exactly where we're heading, we will have bumps across the way. We know that designs inherently are going to be changed, and they are flexible, they're malleable, they are soft, so we're going to see failures across the way, but we're eventually going to get there.

Case study: rider tipping at talabat

[00:16:23] Which brings me to a very good case study from our team. Being in a big company that serves millions and millions of customers every single day, we know that our riders are at the heart of our delivery business across all the nine countries that we serve in the MENA region, and each rider plays a pivotal role in delivering a seamless ordering experience to our customers. It's always a priority for us to look after them and to do everything we can towards appreciating the rider efforts. We call them internally our heroes, and many of our users have expressed a desire to show their gratitude for the hard work that the riders do. Sometimes they don't have cash when they're opening the door to give them tips.

[00:17:09] So the first thing that we did a couple of years ago was to introduce a rider tipping design component in order tracking, when after you placed your order you are looking at the screen, you are waiting for your driver to come, so you just tip the rider. And at that time we have seen that not a lot of people were using this widget. In fact it was 0.3 percent of our orders being tipped, so three orders in every thousand orders being tipped, which is not a great impact if we want to appreciate our riders.

[00:17:44] So we decided to try a completely different bet. We said, how about we introduce this component, a better version of that component, but within the checkout flow? Which a lot of people were skeptical, like, how would you tip someone that you haven't seen the service for, you haven't received the food yet, why would you place that tip? And the only way for us, given the experimentation culture we have at talabat, and given the high ability to ship something, learn from it and move on from it, we said, you know what, let's do it, it's a bet. If it works, it works. If it doesn't, we're going to iterate on it and see how it works.

[00:18:30] So we shipped it, and when we added it in the checkout screen, to everybody's amazement we almost 10x'd the impact. So we took that 0.3 percent of tipped orders all the way to four percent, and kudos to the team for seeing that impact and that improvement right there.

[00:18:50] Shortly after, we discovered that people want to put their own custom values, they want to give more than the amount that we suggest to them. So we introduced that. We even iterated on it a couple of times by keeping your tip, and that doubled the impact, it went from four percent to eight percent. This is when we knew that we are on a very big path for us to even improve this component even further for the sake of all riders.

[00:19:23] So we came up with a very, very out there idea: how about we introduce emojis? What will happen if we visualized to people what this amount is costing you and how is it going to impact the rider's life? And that took the impact from eight percent to 11. And then we went all in with making it selected by default, and of course it's very intuitive and clear for people to clear that tip if they want to, and if they cleared it, honor that option and that desire from them. And we 2x'd that impact.

[00:20:08] So the idea here was not only to be bold and to validate the assumption and to ship something and see the impact yourself, but also, once you see that impact, don't stop there, keep iterating and test out different ideas even if you feel like they are out there. Eventually, good design is not one and done. Good design is a function of the number of iterations that we can ship. Iterating solutions is an absolute must to reaching great design, and successful design teams and successful product teams don't stop there. It's very proportional to the amount of experimentations that they launch, run and learn from. That's why product teams should always look after a problem and they should focus on it, working for months and quarters on end on that specific problem, rather than a one and done kind of project.

What is the MVP of a house?

[00:21:00] Which brings me to the next part, about MVP design. How do we define MVPs? What's an MVP looking like? Because MVP is zero to one rather than one to a hundred. Similar to the rider tipping example that I was talking about, it's more of an MVP on checkout, but one to a hundred of improvement and evolution.

[00:21:21] I was looking for the best description of an MVP, and this one hit home with me, with Allen Holub's description. Allen is of course the software engineering guru and an author and one of the godfathers of object-oriented programming and agile. He said that an MVP is the minimum thing you can build that tests the viability of a product idea. So an MVP is a test, and if we approach it from that mindset, an MVP is not a small scope of the project or the product that you're building, it's a test.

[00:21:59] So how do we scope those MVPs? Let's have a quick thought starter, completely moving away from software: what's the MVP of a house? Let's take a second, think about an MVP of a house, which is a good exercise[?], and I was actually doing it with my team.

[00:22:20] Some people would usually say, well, it might be a cabin, it might be a hut, a small shelter that's built with wood rather than an extravagant building, which can be true. It's true, it's a good solution. Somebody else would say, well, we can have zero price paid for that house, and the MVP of a house can be a cave. You go there, you stay there, you haven't paid anything and it can be a house, which is also true. Somebody else would say, well, it depends. If you're just needing a house to be protected from rain, then the MVP would be an umbrella, and that would be true.

[00:23:00] And one of the best answers came from the product lead and partner that I work with, and she said to me, well, if your true purpose of a house is to hold value and to invest, then maybe stocks or crypto, not maybe in the current inflation terms, but maybe it's a good solution. So it can be just buying some stocks with that money rather than going to a house, if you want to invest, which can also be true.

[00:23:32] If you can see those four solutions, they are not the same thing, they are completely different, and you have no idea where to start. The MVP of a house: I want to build a house, I want an MVP, and you have no idea where to go from here, because there are different parts. However, going back a layer of abstraction, what does a house solve for our customers? If we do just enough research and we found that the real need is not investment, it's not being protected from rain, it's being in a shelter, maybe from animals, maybe from the elements, maybe from snow. So with that said, after you are being clear and focused, you can clearly choose two winning ideas and two losing ideas.

[00:24:17] However, you can go a little bit deeper. Now that we know that our users need shelter, what other solutions are out there for shelters? Someone would say, well, we can have a tent. Somebody else might say, well, an RV van would be a good idea as well, a camper van, it's a good shelter as well as a tent. But you're not sure also which one you should pursue. You can pay for building a house or a hut, or you can pay for that camper van, or pay for the tent.

[00:24:51] But if you are clear about your research and you've done just enough investigation, you can see maybe your customers need shelter on the move, which again would go through prioritization and killing of your darlings, solutions that might have worked in the past. And you say, now that I know that people need shelter on the move, I'm no longer interested in building a house or going to a cave. Those two solutions can work, and you continue down that path of continuous discovery and continuous analysis and continuous measurement or comparison between solutions.

[00:25:31] And you come up with more ideas. Maybe now that we know it's a shelter on the move, and we investigate it a little bit more, that it is for campers, maybe a tent on top of a Jeep would work, or the hanging tents on mountains would work. Just by doing this, now you are zooming into your problem space, zooming into the actual need, which is shelter on the move, zooming a little bit more into your target audience, which are campers. You can go even deeper and check those campers, who are they, maybe they are mountain climbers, and that instantly cancels all those solutions that might create noise and makes you focus on the exact product that you need to build. The MVP of your product, of the house that you started with, is actually a shelter for mountain climbers, choosing the actual solution that you came up with.

[00:26:28] So as you can see, we started here and we ended up here. That's why iterative design and continuous discovery and quick experimentation is very important, because whatever ideas we came up with at the beginning of the discovery phase is almost never the thing that we ship at the end. We need to be laser focused on defining our problem statements and who we're solving it for, and keep iterating on those solutions and killing them fast, so that we can reach the right solution for the right customers.

Case study: reordering at talabat

[00:27:05] Which is something that we did at talabat. We were looking at reordering, and the problem statement that we wanted to work on, on one of the projects, was how might we introduce an intuitive and personalized swim lane for manual reordering? So just by using this problem statement, which is going back to how we build an MVP of a house, it was quite prescriptive. It said a house in that specific problem statement, saying a swim lane.

[00:27:38] So the team's first solution was a swim lane. They put this card on top of the menu screen and they thought it would work, we have seen it working in other apps across the industry. And then the team went into a tailspin, making sure that every use case for that card would work, and even experimenting with the copy, not even launching, because the scope was getting bigger as they started discussing all the solutions. For example, what would happen if the past order no longer has one of the items, or the prices have changed, or how are we going to display a big amount of items in our basket? And they went on and on.

[00:28:25] And then they decided, you know what, stop there, let's test this prototype with our customers, let's see how it works before building anything, before we go any further, because this is getting a little bit out of hand. And when they tested with the customers, users would swipe through it, they don't even notice that swim lane. When customers come to the menu screen they go into the idea of, I want to select whatever I want to select, and I know exactly what I ordered last time so I'm going to look for it, and they completely missed that swim lane at the top.

[00:28:58] So we went back to square one and we looked at our problem statement, which clearly said how do you build an MVP of a house, and we started defining that we're not building a house, we're building a shelter. So we rewrote it, and kudos to the team for having that flexibility and agility, and they said, you know what, we are here to build an intuitive way to order from any restaurant. This is the actual problem statement.

[00:29:26] And having a co-located product team with engineers, with data scientists, with product managers, designers, they came up with the simplest solution: how about we just introduce a new section called order again? It has the menu items and you go through it, you select whatever you want. And they shipped it in less than three days, kudos to the team for doing this, and they just reused components that are there in the design system. That's also a very important part of empowering teams and enabling teams to iterate fast.

[00:30:03] They tested this idea fast. Three days later they found the impact coming very staggering and surprising, that our menu conversion rates have more than doubled by just introducing this section. The simplest solution usually is the right solution, and it goes back to a well-articulated problem statement, which is another important mindset that we have to look at when we are approaching good design.

Recap

[00:30:30] I want to close with a very good quote from Stewart Butterfield, of course, as many might know him, the CEO and founder of Slack. He said, what we're selling is organizational transformation, the software just happens to be the part that we build and ship. So he is not specifically talking about the solution, which is software. He's looking at the problem itself, or the challenge or the mission, which is organizational transformation. Same as abstracting the problems to the next level and looking after the higher job to be done that you're trying to cover.

[00:31:13] So to recap: design is a function of its medium and how flexible and malleable that medium is. And good design is a function of the time it takes to ship, so the longer we wait, the less impactful our designs will be, so we should always optimize to ship faster with every sprint, with every iteration. Good design is a function of the number of iterations we can ship. It's almost impossible to get it right the first time, so the end goal for us is to keep iterating fast. And good design is a function of how well articulated our problem statements are. Because at the end of the day, good design is never done. Thank you.

Q&A

[00:31:56] Host: Great, thank you very much. That was a brilliant presentation, and finally we made it work without any technical issues, so thank you so much for that. And it seems both Lilia and Sophia and Kamal Hella have given some positive feedback there, so it obviously touched a nerve there. Brilliant. I would love to jump into some questions, because particularly there was a bit of conflict there between your talk and Paul's, and I was going to ask some questions about how do you avoid dead ends by going the wrong path and iterating into it. Or the second one was, it's great when you're doing a little design, but how do you avoid that kind of Frankenstein design where you're always looking at a little piece, so then you've got like a Frankenstein, one arm, a different head, so it's always coming together? I'm going to put those questions in our Slack channel, because unfortunately we are out of time, but I do hope that you can go in there and just answer those, because I'd love to hear your opinion on those.

[00:33:06] Robert: Happy to.

[00:33:07] Host: Excellent. So that actually brings us to the end. So thank you very much, Rob, for sharing your thoughts.