From Opinions to Outcomes: How Clarity Builds Trust and Better Design

Rahul B at UXDX EMEA. Video: https://youtu.be/Ydo5Ndix05E

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.

The New York subway map argument

[00:00:07] Hello everyone. Nice to meet you all. Today I'm going to talk about opinions and outcomes, how clarity builds trust. A little bit about me. I come from this little landlocked country called Luxembourg. It's stuck between Germany, France and Belgium. I've been working for the last 15 years, and I've been 10 years with Amazon.

[00:00:35] This is how the tram lane of Luxembourg looks like. And that's where I come from, Bangalore. The tram lane in Luxembourg is a straightforward one lane, and in Bangalore it's five lanes. So why are we talking about maps? Why are we talking about trams and metros? There's a very interesting story I want to tell you guys today. How many of you guys know this gentleman? Okay, anyone knows? Okay.

[00:01:11] He is Massimo Vignelli. He's an Italian designer who moved to the US, and he designed this particular map, which is the first New York metro map. There was a very interesting argument between him and John Tauranac, who's a cartographer, who argued that maps do not work this way. Vignelli's map was about a very simple system of vertical, horizontal and a 45 degree angle, which is what most of the maps across the world are based on. But many New Yorkers argued that the map shouldn't be this way, that maps should be realistic, maps should depict what's underneath, the map should show what's happening in the city.

[00:02:02] They had a very interesting debate between both of them and they invited the public. In April they invited a bunch of public. There were 150 participants who came to argue about the two maps, which would work, whether we should go with the geometric map or with the realistic map. Ultimately they replaced it with the realistic map by John Tauranac. But what happened a few years later was they realized they're running out of space. They realized it's not going to work for them. In 2025 they brought back the map. Unfortunately Vignelli was not alive to see this comeback.

[00:02:48] Sometimes this is what most of our design arguments are about. Some arguments take time. This particular argument took close to 46 years, but it ultimately wins. And that's what I'm going to talk about: how do you condense complex information into communicable, simple, everyday design solutions? One of the key takeaways from these arguments is, how do we think between simplicity and complexity? How do we think between abstraction and realism? How do we think about constraints and clarity? The work that lasts is not really the prettiest. It's basically the most systematic one that survives.

[00:03:37] It's not just about making good design. It's about making your design survive. It's about making sure that you are able to argue with the right kind of examples, the right kind of systems, to make the design survivable.

When a single comment undoes five weeks of work

[00:03:52] When you're going to argue, we're going to talk from a point of view, and everybody means good. But sometimes we go into a review where we had spent three to four weeks working on our solutions. We would have done our research. We would have done our solutions. We would have done our prototypes. Then somebody in the room says, hey, something feels off. All your three to five weeks of effort just gone, probably in a single comment.

[00:04:24] Then you go back and repeat the whole system. The whole system not just creates a problem for you but for the overall ecosystem, for what you're trying to build. The first thing which happens is your competitors are actually shipping in that particular time where you're arguing, having all the design arguments.

[00:04:44] As a designer, one of the core things you are going to do is to find a very beautiful intersection between these particular parts, between users, business and system. A designer's job is to find something which users find desirable, which is viable for the business to make, and your engineering team should be able to build it in a very easy way. That magic should happen. That's where the intersection actually happens.

The queue outside the fulfillment center

[00:05:18] I'm going to talk about a very small story, a very personal story from my work. How many of you guys have heard of FBA here in Amazon, or how many of you guys have purchased from Amazon? Okay, so I'm assuming that most of you guys would have seen or bought items. What happens behind the scenes? I'll tell you.

[00:05:41] This is a very common scene in India in 2018, where the trucks get lined up outside the warehouses. They literally had to wait hours and hours and there's a lot of chaos. The drivers actually come with a bunch of documents which they show at the FC entrance, at the gate. They share what they brought, what are the items, what are the invoices, do they have permissions to ship these items inside. They literally have to do this every single day.

[00:06:15] Based on the documents that they give, the teams were preparing the labor planning. They would plan, hey, how many people would be in unloading, how many people would be using the forklift, how many people would be in the packing. This led to a lot of chaos.

[00:06:32] Inside the fulfillment centers, one of the major problems we had was the manpower. Everything was happening manually. They had to note down everything that was coming into the FC. They had to manually note down. One person had to literally look at each box that's coming in before loading it, noting down each and every element. Then whatever was noted down was uploaded into Excel. This created a lot of churn, especially when you are in peak demand, especially during Christmas or any other different times. It led to kilometers and kilometers of traffic jams. It led to a lot of chaos.

[00:07:14] The team came back and said, hey, we want to solve the queue problem. How do we solve the queue problem? But the queue is only the way the problem became visible. The queue is actually not the problem. The queue is a part of the problem which trickles down into a larger effect. First, when the trucks were waiting, the drivers were losing their earnings, because they could be spending a couple of hours to a couple of days if the slots are not available. Then the sellers, who are actually shipping the products, who want to start selling, are actually waiting and paying additional holding charges, because somebody had to bear the cost of the trucks. Then the whole manual process of noting down everything slowed down the whole process. This actually led to folks like you and me getting the packages much, much later, or not being available for you on time whenever you require.

Ninety interviews, three hundred pages, fifty stakeholders

[00:08:15] How do you solve this problem? Just like any other classic design thinkers, what we did was, hey, we'll start doing interviews. When we started, we thought, hey, we identified a gatekeeper, we identified a dock master, we identified a truck driver. Then we thought, oh, we're done. We're done with eight good interviews. Then people said, no, no, no, there are more people. There are more folks involved. Then the interviews went into 20 people, 50 people. By the time we finished we had interviewed almost 90 plus people.

[00:08:47] Then the requirements. I think this is a very classic problem everybody has. You would say that, hey, I'm going to deal with one product manager, one business manager or one program manager, and done. But when you're going to solve a problem like this there are a crazy amount of stakeholders. There are 20 plus active stakeholders, then there are onlookers who want to know how you're going to solve the solutions, who have a shared goal.

[00:09:13] How did we go about solving this? The interviews were crunched. Our researcher crunched through the data, listened to all the interviews, put together a requirement document for us which was almost 300 pages, because you have 90 stakeholder interviews and you cannot miss out anything, because everybody talks about a very critical requirement. When we started writing BRDs, when we started writing about our operations document, if you would have printed all of them it would have piled up like this. Every particular person is important, and in some teams there could be people who are directors, and sometimes there could be a lot more leadership involved. How are you going to put all this together and solve a problem which is about queues in an FC?

[00:10:02] Like any other classic designer, what do we do? You take all the requirements, you start creating solutions, you start presenting in various rooms, you start presenting in rooms after rooms, then you realize it's not going to work. One of the problems we faced was everybody was giving feedback in an isolated forum, but because there are so many stakeholders, so many folks involved, nobody was able to see through the full journey. Why? Because everybody is isolated on an island and they are concerned about their particular pain point, their particular business metric which they want to move.

[00:10:51] This was one very classic thing many of us would have gone through, where you have four different functions speaking in four different languages. Your research is going to say, hey, this is the insight we got, we have to work with this. Your delivery teams or your development teams are going to talk about, hey, this is the timeline, we have to adapt, when is the design going to come out. Stakeholders are going to talk about, hey, I feel this is not going in the right direction, please work with this. And we designers, classic, we're going to talk about, hey, this is a very good solution, this should work, this solution should work versus others.

[00:11:28] Once we analyzed, what we found was we were mostly trying to pay attention to whoever is loudest in the room, whoever is more hierarchical in the room, and whoever had certain kinds of preferences. When you have a director or a leader who's trying to say, hey, I want something like this, you're going to give them the preference. It started to show up in our design solutions. We're constantly changing our designs. We're constantly trying to talk to stakeholders. It's not working.

Giving every opinion a measuring stick

[00:12:02] Then we started looking inside out. What are the exact user goals we have got from the team? What are the business goals we have got from the team? What are the team priorities, and what are the stakeholder opinions that we have? That's when we decided every opinion requires a measuring stick. The moment you hand over the stick to them, they're going to do it very differently.

[00:12:27] How do you hand over a measuring stick? We took all the solutions, all the process, whatever we were hiding behind the walls, hiding behind the decks. We opened it up and created a large wall. I'm sure most of you guys in your organizations would have done it. But what this created was we stopped doing presentations. We stopped doing anything like, hey, can I get a review with you? We stopped calling it a review. We started calling it a walkthrough.

[00:12:55] Everybody would come in, everybody would look at the process and everybody would start commenting, and if they want to add comments they could add them to the Post-its. The moment you hand over Post-its, make them stand and do the work, the whole attitude of it changes. What people start doing is they change their mindset from a reviewer perspective to a builder perspective, because ultimately everybody wants to give you a solution. Everybody wants to improve the product, and now they're able to connect and see, hey, what does the ecosystem look like? How is my work going to impact the next person's work?

The solution: a rolling calendar and two documents

[00:13:39] This helped us map the final customer journey like this: what the sellers would see, what the labor team would see, what the transportation team would see, what the fulfillment management will see and what the dock master would see. These are the key five stakeholders we identified.

[00:13:59] Post that we built a system like this. We wanted something very simple for the customer, who could just do this in probably three to four clicks, and all the complexity was taken care of by the systems which we put together in the back end. The solution ultimately looked something like this, where they get to choose the location where they want to ship to, and they mention how many boxes, how many units they are shipping.

[00:14:30] The second step of the process is it shows a rolling calendar. The rolling calendar is basically like your calendar which says, hey, based on the number of boxes, based on the number of loads, it gives you a slot saying that this particular day this is available, you can ship on this particular day, and it'll give you a time slot. The moment the time slots are chosen, you get a confirmation.

[00:14:55] This particular confirmation already tells the fulfillment center, hey, this many boxes are coming in at this particular time, at this particular hour. And for the drivers it became very easy, because they just had to carry only two documents. One is a mandatory document from the government, which is the invoice for what they're carrying. The second one is the printout of this particular confirmation, because all the items they were shipping, all the documents they were trying to bring to us, was already available with us online.

[00:15:28] This is what the outcomes of this whole exercise were. Within 15 days the system was launched. Truck queues were almost zero, and there was 80% less workload for the people who are manually noting down everything, because everything was already available to them. They just have to work with the systems. It led to 25 plus minutes of more labor free time, which was very important for the company, because when you have more free time they were able to be a lot more relaxed. There was less chaos in the system.

The recipe: before, during and after

[00:16:04] What did we learn out of this whole exercise? What is the recipe? The first thing is, if I have to abstract the whole process into three simple steps, before, during and after. What we were trying to do was set a direction. Before, we were trying to define what good means. Before showing Figma, we told everyone, hey, these are the principles we align with, these are the concepts, and these are the models we're going to work with. So before even looking at the designs, people aligned, saying these are the items you're going to work with.

[00:16:49] Then we started showing reasoning during the review. Once we started showing Figma, we started to open every review by saying, hey, we are optimizing for XYZ metric, we are choosing this over this because of this particular reason, we are considering this particular design because of XYZ reason. This framing helped us reduce the debates. It helped us reduce the time where we are debating over what needs to be built, why you're choosing certain things, why you are optimizing, what is the metric you're trying to work with.

[00:17:29] What we started doing was, instead of showing, hey, here is something we have made, we started showing, here is something we're solving for and we all can win together.

Translating unpleasant feedback

[00:17:43] The last part: how do you translate some kind of feedback which is slightly unpleasant? You have to start talking to people. When they say it feels cluttered, you have to redirect them towards the goal. Can it be fixed in five seconds? Can they find the information in five seconds? When somebody says it needs more impact, you define what exactly the impact is. What is the action here you need to take? When they say it is not premium enough, or when they say, hey, the competitor does this, ask them for references. When somebody says something feels off, ask them whether it is in the flow, is it in the hierarchy, is it in the style.

[00:18:32] The learning we had from all of this is you should not be ignoring anyone's feedback. You should give them a place to land and you should hear what they're trying to say. The moment you try to hear and clarify their thoughts, your designs will actually get much better.

[00:18:50] This is the last part I was talking about, where whenever somebody says, hey, this feels off, you ask them, why do you say it's off? Is it an interaction problem, is it an information problem, or is it the visual which is a problem? By clarifying the layers it becomes very simple, it becomes very easy, you would save a lot of time.

[00:19:15] Clarity isn't about fewer opinions. You will get opinions. We had almost 50 plus stakeholders. Everybody had opinions. But you have to give everybody a measuring stick and you have to give everybody a useful place to land. It's a system where you can learn, and as you try and practice it more and more, I think you would be able to incorporate it in your work.

[00:19:48] One very beautiful example of what I have seen getting implemented is F1. Nobody talks to each other, nobody discusses anything with anyone, nobody argues anything, there's no chaos, and everybody has a role and everybody finishes the job on time. Everybody finishes everything very beautifully. This was the previous record. The current record is 1.88 seconds. So much happens, so many different points of view come in, so many different things come in, and they finish the whole task within 1.9 seconds. With coordination, with bringing in multiple opinions, when you put a system to those opinions, your teams could also work like the F1 story. Thank you, and thank you for being a wonderful audience.

Q&A

[00:21:01] Host: Thank you so much, Rahul. I used to watch Formula 1 a lot, so I was always fascinated about how quickly they can coordinate, and I always envied that thing and wished to have something similar in my own work, with the teams I was working with. I wanted to switch to questions now if anyone wants to learn more from Rahul. In the meantime I have a question, because I'm working on this myself a lot, on building a shared language and shared meaning across teams and inside big organizations. One curiosity I have: how do you see teams can make clarity a habit, and not just a workshop or a get-together session, but embed it into their ongoing practices, ongoing habits?

[00:21:56] Rahul: What we have seen, at least in our teams, is you need to give everybody the shared language, just like how devs are going to talk to you in their coding language. You have to tell them that there's a design language where you're going to talk about, hey, this is the process, this is the user empathy, this is what the words are that you're going to use. Then the moment you start sharing your work more and more, the teams are going to follow, the teams are going to talk in your language. They're going to start going from, hey, the space looks off, to the kerning looks off or the spacing looks off. So first is that you have to teach them the language. The second is that you have to...

[00:22:41] Host: Make sure that they actually practice it, right?

[00:22:43] Rahul: Yes. Then the second part is making sure that if somebody is giving you a hard feedback or a comment, analyze the feedback, just like your users when they're going to give you hard feedback or negative feedback. Similarly, your stakeholders are also the same way. You have to analyze the feedback, where they're coming from, and dissect the feedback and get back to them and tell them, hey, this is what we think. That helps you, the clarifying cycles become less and less as you spend more time in an organization.

[00:23:14] Host: Was there any friction, for example with management, shifting from designing outside in to inside out, and if so, how did you handle it?

[00:23:26] Rahul: Yes. Any new process, any new thing you're going to put through, there are going to be friction. The first friction is going to be from the loud voices, as I spoke about. They're going to say, hey, my point of view is not being heard, my point of view is not addressed. So the first thing you're going to do is you're going to flip the whole thing and say, hey, this is what the user says and this is what you're going to say. You have to talk from a user perspective. That's where your research data helps. Any argument you're going to do without data, it's just an argument, or it could end up in a brawl. So the moment you present data saying, hey, what you're saying is X and what the users are saying is Y, what do we follow?

[00:24:08] Host: But if you still get pushback even after showing that? Because I've been in such situations myself.

[00:24:13] Rahul: Sometimes, yes, definitely that happens. What we do is we create something for them and say, hey, we did this, we followed your feedback, but it doesn't seem to work. Some people, you don't want to hurt somebody's ego if it is so high, you just have to create, you're probably going to spend another one or two hours doing the solution, but just to show them, hey, we have tried this, we have gone particularly this path. Sometimes, very interestingly, because of the experience that management is going to bring in, they're going to bring in some solutions which could actually work. We have had certain situations when they gave a suggestion and we had initially ignored it because the user data said something else, but when we actually started building the solution it was actually good. So it's a two-way door. You're going to try it and you're going to try and figure out. First is data. The second one is, if it is not working, try it out yourself and say, hey, we tried this, it's not going to work.

[00:25:13] Host: Interesting, right? Thank you. How do you measure the 80% reduction in workload?

[00:25:20] Rahul: The 80% reduction in workload was basically folks sitting and spending how many hours writing. They were basically spending close to six hours in a day writing down everything and then manually uploading it. The moment they started doing everything online, they just had to take a printout and verify them, so the job of verification became very less. When you don't have to write, when you don't have to go back and create everything in an Excel, your job is actually going to reduce. That's how we measured it for that particular task.

[00:25:57] Host: For that specific task especially. How was the adaptation from your stakeholders of your adapted design review approach?

[00:26:06] Rahul: Not sure I clearly understand this question either.

[00:26:12] Host: How the stakeholders adapted.

[00:26:16] Rahul: The review approach, initially. Initially people were odd, because when you go into a corporate office you don't really see a huge wall which has maps, drawings, which has Post-its, which has all those colorful things. The first time when they come they're going to be odd, then they're going to look for those particular sections that they want, and then they're going to say, hey, this particular part is missing, I spoke about this in this particular review. Then you're going to give them a Post-it and add it. So it took some time, but the review approach really worked with a lot of them, and we replicated this over till COVID happened. We had multiple walls, and then at one point we were in a position where we were running out of meeting rooms, because every room was blocked and we had walls created in them. But till COVID happened, that wall exercise continued. People loved the offline world, people loved working with Post-its and stuff. Post-COVID we were not able to continue. A lot of things have changed in the post-COVID world.

[00:27:16] Host: I'm curious, how long did it take to actually fill up all the walls and all the rooms?

[00:27:21] Rahul: It's probably what we do just like a design sprint. We spend about a week doing everything. Sometimes you're going to print out big sheets, or sometimes you're just going to write, or sometimes you're just going to put up a white sheet and just going to brainstorm on stuff. So it's different processes for different teams, depends on the complexity obviously, and the number of stakeholders as well.

[00:27:45] Host: Of course. Can you clarify what the measuring stick for opinions is?

[00:27:51] Rahul: Okay. The measuring stick for opinions is a very interesting concept. Let's say that when you get an opinion you have to first figure out where it is coming from, whether it is coming for you as a design feedback, or is it coming as a metric level feedback or a business level feedback, or sometimes it could be about how we are operating, as an operational feedback as well. So first is, locate where you're going to place it. Then probably give it the hierarchical structure. When I say hierarchical structure, when you compare that with your user needs and business needs, how important is that particular feedback? Is it a blocker? Without this, your user will not be able to finish their task. Is your business going to lose money? These are the two very key things we look at. The third part is basically locating that exact layer, is that going to bring in any kind of value? Those are the three things we look at, but mostly we would get our answers in the user needs versus business values.

[00:29:01] Host: Right, thank you. How do you separate valid feedback from personal preference with 50 plus stakeholders?

[00:29:09] Rahul: Yeah, that's a very interesting thing. I think you would have seen all the sheets, right? First is listening to everyone, and second is making sure that all your data that you have about user interviews and everything is from their stakeholders as well. It's not really like, hey, you're going to speak to your set of folks. You're going to make sure that you're going to talk to their particular stakeholders, and we say you have to act on their behalf as well. That reduces a lot of churn. Sometimes you get certain preferences which say, hey, the competitor is doing something like this, why don't we replicate this, because that's the easy route that they've seen. It's very important to evaluate that and say, hey, this is why it works, why it does not work for us.

[00:30:01] Host: Thank you. Someone is curious to know what model you've used for the pictures for your presentation.

[00:30:09] Rahul: Mostly Gemini. The pictures were from 2018, 2017, so a lot of them were not of very good quality, and then some had some proprietary stuff, so we had to remove that and I regenerated them through Gemini mostly. Gemini Pro should be able to give you, nano[?] should be able to give you all this.

[00:30:31] Host: How long did the project you showed take, and how long did it take to have feedback and decide what to implement?

[00:30:41] Rahul: The overall project was around 18 to 19 months, and it took about probably two years to implement, because we had to build a lot of systems. You saw only the consumer layer, which I'm allowed to show, but there are multiple different layers that we built. You have seen those five layers. All those five layers, all the data, everything was built in. More than anything, it is a business transformation. A lot of them had to be trained, a lot of them had to be checked, whether this data can flow into something. So it took about another one year to build the whole system to go live. Now it's live in almost 18 countries, I think.

[00:31:24] Host: Thank you. I actually also have another question for you specifically. What are the signs that you look at to notice when a design conversation is more opinion-led than outcome-led?

[00:31:40] Rahul: Sure. Can I repeat the question? What are the signals that you look at in a conversation...

[00:31:47] Host: To know whether it's opinion-led or more outcome-led?

[00:31:51] Rahul: The first sign is basically you look at, is it backed by data? Are they going to say something saying, we are telling you XYZ because we did XYZ things, or are they going to talk more in terms of, hey, I don't like it? Then that's an opinion.

[00:32:14] Host: Supported.

[00:32:15] Rahul: Yeah. Saying, hey, I worked on this XYZ flow, it doesn't work, is a data valid question. So you can separate that from that particular perspective.

[00:32:26] Host: Right, thank you. How big was the team working on this project, and what expertise did they have? What was needed?

[00:32:38] Rahul: It was basically one designer and probably around 40 people. In India we have very small teams, so probably the whole team would be less than 40 people including devs, program managers, the core team I'm talking about.

[00:32:54] Host: So the roles you had were designer, developers.

[00:32:58] Rahul: Yeah. Designer, developers, program managers, product managers. Then you could have somebody who could be in the operations who can help you with the operation. Then supply chain experts, who are more important for building some processes like this.

[00:33:13] Host: Thank you. Any more insights into how crits go at Amazon? I don't understand that question myself. I don't know what that specifically refers to, honestly.

[00:33:33] Rahul: Any more insight on how crits go at Amazon? Amazon has leadership principles, so we don't really go into crits. You guys can Google it up. What Amazon does is, if somebody's critiquing your work, somebody's being very mean, we ask, hey, what leadership principle is it not aligned to? That solves a lot of problems, and then you go into the leadership principle and then you're going to talk in detail about it. Most of them understand it, most of them embody it. So crits are slightly easier if you spend a lot more time. I've spent 10 years, so I understand. We ask, hey, what is this aligned with? Then they'll say, hey, this is not a think big solution, or this is not a dive deep solution. So we know exactly where the problem is.

[00:34:17] Host: So now I know what the short term for design critique is. I've never heard this one before, so that's why I was a bit confused. Thank you so much, Rahul. Appreciate it. Round of applause for Rahul here.