Alignment Through Design

Tristan Charvillat at UXDX EMEA. Video: https://youtu.be/C8fXMtIab0M

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.

BlaBlaCar and the scope of design and customer experience

[00:00:00] Hi everyone. I'm Tristan Charvillat, I'm based in Paris and I work at BlaBlaCar. BlaBlaCar is a carpool company that has been operating for 10 years. We offer drivers the possibility to publish their empty seats on the app, so passengers can book them, and it's cost-sharing. It's not professional drivers. It's a marketplace for people who want to travel and share the cost of the ride together.

[00:00:31] Now the platform is evolving a bit: now we have bus tickets that you can book, and probably trains will come. So it's a ground transportation app, but still a marketplace where you have drivers, passengers and now professionals. The company has grown pretty fast, and now we've hit probably close to a hundred million users across the globe, operating in 22 countries, and it's still growing. So all good for now.

[00:01:04] My role at BlaBlaCar is VP of Design and Customer Experience. It's a pretty broad scope. I started leading the design team, so pretty classic product design, research and content design, and then the scope expanded along the way. Now we include the CRM, the product marketing team, the brand team and the creative assets, so everything that we would create for brand campaigns or advertisement campaigns in general. It's a team that tries to cover most of the customer touch points.

[00:01:37] That makes sense from BlaBlaCar's perspective. We're a very design-driven company, and we care about user experience a lot. I report into product, so you can imagine that the product organization has a very large scope: from the brand through the marketing and the design, and of course the product management and the data team. That's what we do, and that's how we organize them.

Why we needed a new way of working

[00:02:12] Three years ago, I think, we sat down with the management there, the product stakeholders, and figured out how we could improve the way we work, with the company growing so fast. I'm sure most of you are experiencing that. The team grows by two every year, or sometimes by three. The working model is challenged with newbies and new product lines that we want to develop. It's constant change. So three years ago we said, "Maybe there's something we can do. What can we do to help our team work better together?" That's what I want to talk about today.

[00:02:52] A little bit of context. I just said that we are a customer-experience-centric team, so the first thing to do was to send a survey across the company, even beyond the product organization, and ask, "What's your perspective on that? How can we improve the way we work together as human beings?" As always when you ask people, you start with a crafted, precise question, at least you hope, and you end up with paradoxes. That's how humans are, and that's what we got.

[00:03:24] It was a mix of: we want more rigor, but we also want more autonomy; we want new methodology and we want high-level vision; we want quality. That's what they wanted. Very interesting insight. We tried to reorganize that to understand it better, and it came out that they need some creative room and they need autonomy, and at the same time they need structure and discipline. That's something we needed to figure out for the group. So that was the team insight.

[00:03:56] Of course, from a stakeholder perspective, we also had some expectations and some challenges, and this is how I would summarize our challenges. We are an organization where there are chapters. I guess most of you know what a chapter is: a product chapter, a product design chapter, a CRM chapter, so the different teams, let's say. Those chapters are organized through squads, working on projects. This is the classic mature organization.

[00:04:30] Our challenges were, first, how can we make our chapters work together? How can we improve the collaboration between the chapters? At the same time, we also wanted to ensure that we have consistency in the way we approach projects and in the way we deliver projects: consistent in terms of practices, and consistent for our members. At the end of the day, members won't care if this is a marketing project or a squad search project or whatever. They're just looking at one single experience, which is BlaBlaCar.

[00:05:06] So: chapter collaboration, execution consistency, and it should work in a company that is scaling and growing super fast. It has to be a scalable approach. It should not be a one-shot that we need to reconsider in a couple of weeks. We know that we'll have to reconsider it in a couple of years, but we want something pretty resilient to the current company goals. Those were the challenges we had.

[00:05:35] With all that, we decided to move away, go next to the sea, where we could find fresh ideas. We used BlaBlaCar, of course, to go to the sea for some days, and figured out, "What can we do to fix all those expectations and challenges?" What we got out of it was: let's build a framework for the team.

The product design framework

[00:06:01] The product design framework is a framework for product and for design. It's not a framework for product designers; it's a framework for the team. As I said, we're very design driven, and the way we look at design and product is that it's just one team working together. We have one product manager for one designer. That's the ratio we have, we're very proud of it, and they work together all the time. So the product design framework needs to be understood as the design of the product experience in general.

[00:06:33] That's what we ended up with: let's build that. Let's create a backbone for the way we work, and then let's try to plug other teams in around that backbone, and that backbone is our product design framework. I will tell you a little bit about the framework principles and the detail of how it works. You will see that this is not a unique framework that you've never heard of before. It's just a composition of pieces that we find interesting.

[00:07:06] I'm sure all the designers and product managers watching the video will recognize the steps. We probably use different naming and organization, but there's nothing really new. It's just our own tailored framework. So I'll tell you about that, then talk a little bit about the positive impact, because it had a very positive impact, and then some tips for success, which is not an obvious thing at the very beginning, and never an obvious thing for a framework.

Autonomy within steps, discipline between them

[00:07:44] Let's start with our framework principles. You remember there was this paradox between discipline and creativity, autonomy and structure, that was required from the team's perspective. How we fixed that with this framework is by creating these steps. You see that there are eight steps with names: Scope, Immerse, Inspire, Shape. That's the name of the step, and it's going to be the mindset of every step.

[00:08:11] The basic rule is that within a step, the team has complete autonomy over how they want to proceed and which methodology or tool they want to use. That's freedom. We can provide a list of tools, of course, but they decide. There's nothing prescriptive in terms of how you need to proceed, and there's also no prescription in terms of how long the steps should last. There are some cases where it's a couple of hours, maybe a couple of days, and sometimes it could be weeks or even months. Nothing is prescriptive about that. That's for the team to decide, probably regarding the level of expectation and maybe how they're staffed and the budget that they have. It's complete autonomy.

[00:09:03] Now, when it comes to moving from one step to the next, there is a discipline, or structure, which is a single deliverable that needs to be delivered, shared with stakeholders and validated. You see under every step name there is the name of the deliverable: success criteria, problem statement, golden nuggets. That's the delivery brief. So that's the overall principle: a mix of freedom, autonomy and structure, with specific deliverables.

[00:09:36] Maybe the last rule, which is very important, is that you cannot skip a step. You can go very fast. You can go back to a previous step; there's absolutely no issue with that. If you realize that maybe you did something wrong, or you want to change the way you approach the project, there's no issue with going back. But you have to go through every step, and you have to provide the deliverable at every stage. That's a very important thing. As I said, it could be just a question of hours. If the team is super clear on the deliverable and the stakeholders are aligned, then that could be very fast, but it's not skippable. Those are the rules of the game.

Scope, Immerse and Inspire

[00:10:13] Now we'll go through the steps, and I'll tell you a little bit about each. We'll start with the step that we call Scope. That's the very beginning. It's defining the limits of the playground. The team can explore what has been done so far, obviously some data, and look at the ambition of the project as well, how much they have on the table. The deliverable is: what is the success criteria for the project?

[00:10:52] I think the success criteria is a very interesting question to ask and to take very seriously. It's not just throwing out a rough number that we're happy with. It's going into the detail of "what do you want?" To take a simple example: do you want 80% adoption of your feature, if you're looking at a feature, or just 10%? Because maybe 10% will be enough, because that feature should fix a specific problem that doesn't necessarily mean a lot of adoption. That's the type of question we really need to ask ourselves. It drives a lot of things, including the design approach and many decisions that you make along the way.

[00:11:28] So what is the success criteria? The team needs to align on it, product and design together, and it should be shared with the stakeholders. I would say the alignment of stakeholders around the success criteria is also a very important thing. As much time as you need, then the deliverable, then we align and we move on to the next step.

[00:11:52] The next step is the Immerse phase. That's something I would say most designers would call discovery, and yes, it's very, very close to discovery. We could have named it discovery. It's going deep, unpacking the issues, trying to figure out what the root cause is, the core problem you need to fix. As I said, nothing prescriptive. You can go for a ride for a week if you want, to talk to people, and just book a car on BlaBlaCar. Or you can go for a calling campaign, or you can go through very specific data. You can open the verbatims in the NPS. There are plenty of ways you can access information.

[00:12:39] The only requirement is that you end up with a very clear problem statement. Problem statement meaning: what is the problem you need to fix, through the eyes of the customer? Just for information, for some time we explored the press release mindset, which is, "You need to write down the press release of the future." That's just another type of deliverable for that step, but it's very clear on what the problem is, with a very member-centric perspective and language. Same thing: we align with the stakeholders.

[00:13:15] Then we move on to the Inspire step. That's a step that's very close to my chest, I would say, because this is somehow the way I see design. Maybe some of you will be disappointed, but I see design as just a way to reassemble things that already exist. We don't want to reinvent the wheel. We are into cars, but we don't reinvent the wheel. What we want is to leverage existing patterns as much as possible.

[00:13:46] I think you should think of the car metaphor. I think it really resonates. By the way, I don't have a car, so I rent. Every time I rent a car, I end up in the same situation. I get the car, and I know how to drive it straight away, no issue. I don't care about the model; I know how to drive a car. But I end up on the next street with a radio that I don't know how to turn on or turn off, because the car builders rely on the pattern for driving, but they find it interesting to recreate the sound system interface for every model, and that's a mess. That's for real. So many times I've gotten that crazy radio station that I hate, and I don't know how to turn it off.

[00:14:27] That's a little bit of it. You realize that getting into a car, the fun part is not re-figuring out how to drive a car. It's just to drive it straight away. That's how we want to look at design: just leverage beautiful, existing patterns and put them into the product. And if there are things that have not been fixed or invented, let's do it. But for the rest, let's reuse.

[00:14:57] So that's the step, that's Inspire. You can call it a benchmark. I think it's fair to call it benchmarking; Inspire is a bit more inspiring, but it's the benchmark. The deliverable we expect is what we call the golden nuggets. We don't expect people to share 500 screenshots to show how many products they have explored. It's the things that you find absolutely interesting, your golden nuggets that you want to reuse as you go through the design process.

[00:15:21] Just a detail, but it's not just UI. We want golden nuggets for content. We want golden nuggets for product marketing. We really want every team that has a creative duty to explore and bring golden nuggets to the team. So that's the Inspire phase.

Shape, Design, Expose, Spec and Follow

[00:15:42] The next step is the Shape step. Shape is what we'd call a workflow, somehow, but it's a little bit more complicated than a workflow, because we ask teams to figure out the entire end-to-end experience. As I mentioned earlier, we have a broad scope that includes CRM, product marketing and some brand activities. So when we talk about the end-to-end chart, we want to see the product experience, obviously, but we also want to see what's happening around it. That's the end-to-end perspective.

[00:16:11] To give you a concrete example: if we were to launch a feature, it's very likely that there's going to be an advertisement or educational campaign. Some users will come through the educational campaign before they get into the product. We want to see what the campaign is about. Then they go through the product, and maybe they drop, and if they drop, we have some emails that we're going to trigger to bring them back into the product. We want to see those emails as well.

[00:16:45] We want to see everything that could happen to a member as he goes through the feature, and that's what we call the end-to-end chart. It's product plus marketing plus email, everything that would happen around this experience. Same thing: share the deliverable [?], realign, and we go through Design.

[00:17:02] I probably won't go into the detail of this one. I'd be happy to, but that's not the point of this presentation. We have some tools and specific tricks, but in general this is design activity: diverge, converge. We do some basic tests, like street tests or guerrilla tests. We like Starbucks tests: we just go to Starbucks and we ask people to use the product in exchange for a coffee, which is very nice. But those are just basic tests.

[00:17:28] We iterate inside this step, and the deliverable here is the prototype. Most of the time we ask for a high-fidelity prototype, because we realized that this is a very interesting mechanism to force the designer to push their thinking rather than just stop at a static level. So most of the time, this is what we expect.

[00:17:53] When they're done with the prototype, we move to Expose, which is user testing, but this one is a proper step. It's very structured. I would say it's traditional user testing, with strict methodology, in a lab. It could be in different countries, because we operate in different countries, but it's very standardized. Here you can imagine that it happens that we go back to Design after the test, if we figure out that things don't work properly. If it works, and user feedback is positive, and we all agree that this is the right time to move on, then we move to the Spec.

[00:18:28] On the specifics of the Spec here: it has to be super polished. We call it Laser Spec, and we put a lot of attention into making sure that motion design, yes, but also all the horrible corner cases and the error messages and all those things are covered. We really want to recognize that it requires time, and we want to stop and go through every single detail, so that our tech partners don't have to figure it out as they develop because we forgot something in the spec, and they have to go back to the team.

[00:19:06] So, Laser Spec. The final step is what we call the Follow step. It's pretty much QA, but QA before launch and QA after launch. I think the value of having such a step is two things. One, it conveys the message to the team that Follow is important. It happens a lot that when teams deliver the project, they move on to something else. Then the tech team is trying to wave and say, "Hey, I have a question," and it's, "Okay, you have a question, but I'm on something else already, so I need to find some time, and maybe I forgot."

[00:19:46] With that process, we really want to recognize that teams need to continue looking at the project until it's perfect, until it's QA'd. The other aspect is for stakeholders as well, because it's also a message to stakeholders that the project is not done, because the team is still working on the Follow step. So it's a recognition on both sides that Follow is an important activity, and we won't move to another project until this step is completed.

[00:20:17] Those are the eight steps. I'm sure you'll recognize most of them. It's just the naming, the arrangement and the rules that make this framework unique and tailored for us.

The impact on collaboration and consistency

[00:20:30] That's something we designed three years ago. We asked the team for the last three years to work exclusively with this framework. Every single project that we've delivered over the last three years went through this process. As you can imagine, it's been a lot of educational work to make sure that this is happening, but it is happening, and it has had the expected impact. To be honest, it really works. I think if you asked anyone in the product organization at BlaBlaCar, they would tell you about the framework.

[00:21:01] I think it really works, and it fixes the issues that I mentioned at the beginning. For the team, the freedom to proceed is obvious. Stakeholders are not into the everyday detail; they let them proceed. The deliverable is a very heavy structure, obviously, but that is well received. We found the right balance between the creative aspect and discipline.

[00:21:30] Talking about the collaboration aspect that we discussed, collaboration between squads: one simple thing is that it creates clear moments for chapter involvement. You see product and design, as I mentioned, hand in hand along the entire process. They have shared deliverables, so they're equally engaged for every deliverable. Sometimes product is leading. If we're talking about Scope, as an example, this is more product driven, with design supporting. Design steps and sometimes Inspire could be design led, with product supporting. But in any case, they work through the entire set of steps.

[00:22:13] Now, all those other teams know when they need to get in. In Immerse, they know that you need research and product marketing. It has to happen: you cannot deliver a problem statement if you didn't have research and product marketing support. The other way around, if a researcher meets a designer and asks, "What are you working on right now?" and they say, "I'm in the Immerse step of a project," they know that they need research. If they don't have a researcher, then something's going wrong.

[00:22:41] Even for leaders, it's super easy. If the research lead needs to figure out what they need to work on, they see the list of projects and the steps, and they know. They can even anticipate: if a team is moving on, they know that they will hit that step and they'll need research to get involved. So it's a simple process for everyone to know when they have something to do, and what they have to do at this stage. That's why collaboration is significantly improved with that.

[00:23:10] The other aspect that I mentioned was consistency. If you look at the steps and just remove the names and look at the concepts, you realize that it's actually a 360 approach to a project. We try to touch every single lens that needs to be used when you look at your project. You start very business centric, with the objective, then you move to the consumer perspective, you look at the competition, and you figure out the entire experience, et cetera. So I would say it's a checklist of good practices for a project, but it's just that.

[00:23:53] The fact that you apply these steps, this mindset, with extreme rigor, so that every project has to go through all those steps, is a guarantee that every project will have a consistent approach and consistent quality. None of our projects should forget about a competitive benchmark or a consumer perspective, not a single project. That's why I insisted on the fact that you cannot skip a step: it's the guarantee that we will at least think about all those elements. If it's easy and fast, fine, but we thought about it. That's where consistency comes from, and it works. We have definitely seen the improvement in the practices and the delivery.

Scaling, onboarding and performance reviews

[00:24:45] And the scaling: that's where the big magic is. If this is your culture and becomes your reference, then it scales, because every newbie, every new person in the team, will have to learn about that toolset. That's our tool for onboarding. For any newbie in the product organization, we give them the product design framework and some training. If they're on board with it, then they know how we work, I would say regardless of the team they will work in. If they know the framework, they will know the vocabulary, they will know the process, they will know the mindset and the culture. So it really scales, because we don't have to teach it one by one. It becomes an onboarding tool.

[00:25:29] It's also an interesting tool for performance review. To be honest, that was unexpected at the very beginning. But you realize that because we tried to have a 360 approach to the project, it touches pretty much all the skills you need to develop if you want to be great at a project from the beginning to the end. So it happened that we'd discuss, "You're performing well on the Scope side, you have a very good business mindset and you know how to do that, but in Immerse maybe there's something you want to improve." So it becomes a grid for performance review discussions.

[00:26:12] Design system and brand guidelines: that's also a hot topic from the design perspective, and it's also secured by the process. I've not gone into every detail, but in both the Design step and the Spec we have a design system check. It means that if you want to have a validated prototype and a validated spec, you had a design system review, and your deliverable should be compliant with the design system. There's a little checkbox in the deliverable that says, "Yes, I'm good with the design system." That's also very useful for scaling. It ensures the quality, and you don't have to think about it and miss it if it's not properly written.

[00:26:58] The last element here is project stakeholder follow-up. As we scale, there are more and more projects that you need to look at and figure out. It's very helpful that you don't have to go into the detail. You don't have to micromanage the team. You just have to look at the deliverables. If the deliverable is great, if you align on the deliverable, that means the team has done a great job, and you don't have to go into every single detail. From a stakeholder perspective, it also makes life easier. It gives autonomy to the team and reassurance to stakeholders that they have the critical touch points to ensure the project's quality and advancement. That's it.

Conditions for success: actionable, repeated, tailored

[00:27:40] To finish the presentation, I'd like to share some conditions for success, because I don't think it's such an easy thing to get people using a framework. There are plenty of frameworks. Which one is better, which one to choose? As I said, I'm not a big fan of creating from scratch, and I like leveraging people's knowledge. I love the "we stand on the shoulders of giants" concept. That's true. They are giants. We need to look at them and recognize their work and their contribution to where we are. So leveraging existing things, of course, but which one?

[00:28:21] I want to quote a fantastic design leader that I met when I worked at PayPal. Uris Dacosta [?] was the VP of Design at PayPal when I worked there, and he used to say, "Worst framework is no framework. Best framework is the one that everybody adopts." I love that, and I think it's very, very true. There's no unique fantastic framework, and that's not what's important. The key is not there. The key is adoption: the fact that we all align on a framework and we all work the same way. The value of a framework is its adoption.

[00:28:54] The bad news is that adoption is not magic. I don't have any magic wand I could share, "Okay, now my entire organization will adopt it." But the good news is that there are plenty of designers here, and I would say it's ART. A-R-T: that's probably a good way to remember the key to adoption.

[00:29:20] The first thing is that it has to be actionable. I rarely see a very high-level, inspiring framework that is adopted by the team. I'm not saying conceptual frameworks are not good; that's not what I mean. They're very good for inspiration and thought. But when it comes to actual use, it becomes more complicated, because some people will just miss it and not find the connection between the framework and the action. So what we try to do is to inject tools and specific deliverables, very concrete things, actionable elements, so the team can use it. Usage is key.

[00:30:01] Second, you have to repeat. That's endless, I would say. Even with the best framework and the best adoption, if you stop repeating it, people stop using it. That's how it is. If someone finds a way of not repeating it, I will welcome it, because it's very tiring, but that's what it is. It has to be repeated. You can repeat it as a leader, but you can also create some elements that will make teams talk about it, which could be creating a specific vocabulary. When I hear people saying, "Okay, now the project moves on, let's go to Immerse," I'm so happy, because I know that this word spreads and people use the word, and so they are into the framework already. It could come through vocabulary, rituals; there are probably plenty of things you want to look at to make sure that the team talks about the framework. That's the second key.

[00:30:55] The last key is tailored. Maybe go back to the previous slide, where you see there are plenty of existing frameworks. I think the key is probably just to pick the one that you're most inspired by, or closest to, and make it tailored: change it a little bit, thinking about your own company culture and your daily reality. If there's a step where you feel, "Hmm, maybe it's not exactly how we proceed," well, just remove it or just change the name. I think it's completely fine. The success criteria should be that the team operates with it, that it's their framework. They own it. That's the last part.

[00:31:38] So I'll leave you now with those three things: an actionable, a repeated and a tailored framework. That's a key tool to turn best practices into culture. I want to share this because this morning I received an email from the data team, very proud to share their product data framework, which they've just finished on their side. I think it's an absolutely fantastic sign that they just leveraged the product design framework. They understand how useful it is, and they made it tailored to their own team. I think that's a fantastic sign of success. Thank you very much for your attention.