Alignment Through Design

Everyone. So, I'm Tristan Charvillat and I'm based in Paris and I work at BlaBlaCar.

BlaBlaCar is a carpool company operating has been 10 years. We basically offer the possibility for drivers to publish their empty seats on the app. So, passenger can book it and it's a cost-sharing. So, it's not professional driver. It's a marketplace for a person that wants to travel and share the cost of the ride together. Now, the platform is evolving a bit that we are not having -- now we have bus tickets that you can book and probably train and will come. So, it's a ground transportation app but still a marketplace where you have drivers, passenger and professional now.

So, the company has grown pretty fast and now we 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.

My role at BlaBlaCar is a VP of Design and Customer Experience. So, it's a pretty broad scope, I started leading the design team. So, pretty classic product design and research and content design and then the scope has expanded along the way now we include the CRM, product marketing team, the brand team and the creative assets. So, everything that we would create for a brand campaigns or advertisement campaign in general. So, that's a team that tries to cover most of the customer touch points, basically. And that makes sense from BlaBlaCar perspective, we're a very design-driven company. We care about user experience a lot. I mean, that's the case for us and I report on the product. So, I mean, you can imagine that the product organization has a very large scope. So, from the brand through the marketing the design and of course the project management and the data team. So, that's what we do, that's how we organise them.

A couple of years ago, I think three years ago I mean, we sit a little bit with the management there, the product stakeholders and figure out, "okay, how can we improve the way we work with the company is growing so fast and I'm sure for most of you guys, you experiencing that?" I mean, the team's growing by two every year or sometimes by three. In a working model, they are challenged with newbies and a new product line that we want to develop. I mean, it's a constant change. And so, three years ago we just said that they're like, "okay, maybe there's something we can do. So, what can we do to help our team work better together?" And that's what I want to talk today.

So, a little bit of context. So, I mean, I just said that we are a customer experience centric team. So, first thing to do, we send a survey across the company, even beyond the project organisation and ask, "Okay, what's your perspective on that? How can we improve the way we work together as a human being?" And so, as always, when you ask people, you start with crafty precise question, at least you hope and you end up with paradoxes. That's how humans are and so that's what we got. So, it mix of, we want more rigor, but we also want more autonomy and we want new methodology and we want high level vision. We want quality, that's what they want. Very interesting insight. And I mean, we try to reorganise that to be better and to go out, they need some creative room then when they need autonomy and at the same time, they need structure and discipline and that's something we need to figure out for the group. So, that was the team insights. And of course, from a stakeholder perspective, we also have some expectation and some challenges, and that's a little bit how I would summarise or challenges.

So, we are an organisation where they are chapters. I guess most of you guys know what chapter is about product chapter, product design, chapter CRM chapter, so the different teams let's say and those chapter are organised through squad and working on projects. So, this is the classic mature organisation.

So, our challenges are first, how can we make our chapter working together? How can we improve the collaboration between the chapters? At the same time, we also want to ensure that we have sort of a consistency in the way we approach projects and in the way we deliver projects so consistent in terms of practices and consistency for our member. At the end of the day, member won't care, if this is a marketing project, or this is a squad search project or whatever. I mean, just, just looking at one single experience, which is BlaBlaCar.

So, chapter collaboration. Execution consistency and that should work in a company that is skilled at scaling and growing super-fast. So, it has to be a scalable approach. It should not be a one-shot for now and that we need to reconsider in a couple of weeks. We know that we have to reconsider in a couple of years, but we won't still have something like pretty resilient to the current company goals. That's the challenge is we had. So, we all have that, we decided to move away, go next to the sea, where we can find the fresh ideas. So, we use BlaBlaCar of course, to go to the sea for some days. And figure out, "Okay, what can we do to fix all those expectation and challenges?" Once we got out of it was let's build a framework for the team.

So, the product design framework is a framework for a project and for design, it's not like a framework for project designer. It's a framework for the team. As I said, we're very design driven, the way we look at design and product is it's just one team working together. So, we have one project manager for one designer. That's the ratio that we have, and we're very proud of it and they work together all the time. So, project design framework needs to be understood through the design of a project experience in general. All right. So, that's what we ended up with saying, okay, let's build that.

Let's create a backbone for the way we work and then let's try to plug other teams around that backbone and that backbone is our product design framework. So, I will tell you a little bit about, I mean, the framework principle, the detail how it works. You will see that this is not a unique framework that you never heard about before. It's just a composition of pieces that we find interesting. So, I'm sure all the designer, the product manager watching the video will recognise the step. Probably we use different naming and organisation, but there's nothing really new. It's just our own tailored framework. So i'll tell you about that then talking a little bit about the positive impact because it had very positive impact and then some probably tips for success, which is not an obvious thing at the very beginning and never an obvious thing for framework.

So, let's start with our framework principles. You remember there's this paradox between discipline and creativity, autonomy and structure that was required from the team perspective. So, how do we fix that with this framework is by creating those steps. So, you see that there are eight steps with names, scope, emerge, inspires, shape, that's the name of the step. And it's going to be the mindset of every step. So, the basic rule is within a step, it's completely autonomy for the team, for how they want to proceed which type of methodology or tool they want to use that's freedom. We can provide list of tools, of course, but they decide there's nothing prescriptive in terms of how you need to proceed, but there's also no prescription in terms of how long the steps should last. So, there are some cases were essentially. A couple of hours, maybe a couple of days, and sometimes it could be weeks or even months. There's nothing that is prescriptive about that. That's the team to decide regarding their probably the level of expectation and maybe how their staffed and the budget that they have.

I mean, this complete autonomy. Now, when it comes to moving from a step to the next one, there is a sort of a discipline or structure which is a single delivery that needs to be delivered, shared with stakeholders and validated. So, you see under every step name, there is the name of the delivery. So, success criteria or problem statement, golden nuggets. That's the daily brief. So, that's the overall principle, but mix of freedom, autonomy and structure and specific deliveries. Maybe last rule that is very important is you cannot skip a step, so you can go very fast. You can go back to a previous step has absolutely no issue with that. If you realise that maybe you did something wrong or you want to change the way you approach the project, no issue with going back, but you have to go through every step and so you have to provide the delivery 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 delivery and the stakeholder are aligned, then that could be very fast, but not skippable. That's the rules of the game. So, now we'll go through the steps and tell you a little bit about each. So, we'll start with the step that we call Scope.

That's the very beginning, that's a little bit defining the limits of the playground. The team could explore what has been done so far, obviously a couple of data and look at the ambition of the project as well, how much they have on the table and the delivery is basically what is the success criteria for the project. And I think it's a very interesting question to ask is the success criteria and take it very seriously. It's not like just throwing a rough number that we're happy with it. It's going to the detail, "what do you want?" I take just a simple example. Do you want a 80% adoption of your feature if you're looking at a feature or just 10%? Because that will be enough because that feature should fix a specific problem that don't necessarily mean a lot of adoption. That type of question really need to ask ourselves. A lot of things, including the design approach and many decisions that you can make along the way. So, what is the success criteria? The team needs to align again, it's project and designed together, and that should be shared with the stakeholders. And I would say the alignment of stakeholders around the success criteria is also a very important thing. As much time as you need then delivery, then we align and we move on to the next step.

The next step is there the Immerse phase. That's something I would say most of the designer would call discovery and yes, it's very, very close to discovery. We could have named it discovery. It's basically going deep, unpacking the issues like trying to figure out what is the root cause, why the core problem you need to fix. As I said nothing prescriptive, I mean, 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 variants in the NPS. There are plenty, plenty of ways you can access information. The only requirement is you end up with having a very clear problem statement. Problem statement meaning, "okay, what is the problem you need to fix through the eyes of the customer." Just for information for sometime we explored the press release mindset, which is "Okay, you need to write down the press reads of the future," which is, I mean, just another type of delivery for that for that step, but very clear on what the problem and having a very member centric perspective and language, same thing we aligned with the stakeholders.

And we move on to the Inspire step, that's a step that have very close to chest. This one, I would say, because this is somehow the way I see design and maybe some of you will be disappointed but I see design, it's just a way to reassemble things that already exist and we don't want to reinvent wheels - we are into cars - but we don't reinvent. Well, what we want is to leverage existing patterns as much as possible. And I think you should think of the car metaphor. I think it really resonates by the way; I don't have cars so I rent. And every time I rent a car, I ended up in the same situation. I get the car, I know how to drive it straight, no issue. I don't care about the model. I know how to drive a car, but I end up next street with a radio that I don't know how to turn on or how to turn off because the car builder, they're relying on the pattern for driving, but they find interesting to recreate the sound system interface for every model and that's a mess. I mean, that's for real. So, many times I got that crazy radio station that I hate and I don't know how to turn it off. And that's a little bit of that. I mean, you realise that going to a car, the funny part is not refiguring out how to drive a car. It's just to drive it straight. And that's going to be how we want to look at design. Just leverage beautiful, existing pattern and put that into the product. And if we should get our things that have not been fixed or invented, let's do it. But for the rest let's reuse. So, that's the step. That's the inspired. You can call it a benchmark. I think it's fair to call it benchmarking, inspire is a bit more inspiring, but that's the benchmark and the delivery we expect is what we call the golden nuggets. So, we don't expect people to share 500 screenshots to show how many products they have explored. The thing that you find absolutely interesting, your golden nuggets that you want to reuse as you go through the design process. Just a detail, but it's not just UI. I mean, we want golden nuggets for contents. We want golden nuggets for product marketing. So, we really want every team that has a creative duty that explore and bring golden nuggets to the team. So, that's the Inspire phase.

Next step is the Shape step. Shape is basically we call it like workflow somehow, but it's a little bit more complicated than workflow because we asked team to figure out the entire end-to-end experience. As I mentioned earlier, we have a broad scope that includes CRM, project 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. So, that's the end-to-end perspective, just giving you a concrete example. We were to launch a feature. It's very likely that there's going to be a advertisement or educational campaign. So, some user will come through the educational campaign before they get into the product. We want to see what's the campaign is about, then they go through the product and maybe they drop and either they drop, we have some email that we going to trigger to bring them back in the product. We want to see those emails as well. So, 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. So, it's product plus marketing plus email, everything that would happen around this experience. Same thing, HR, paid delivery, realign and we go through design.

So, I won't probably go into detail of this one. I'd be happy to, but that's not the point for this presentation. We have some tools and specific trick, but in general, this is design activity, diverge, converge. We do some basic tests like street test or guerilla test. We like Starbucks tests. So, we just go to Starbucks and we ask people to use the product against the offering a coffee is very nice, but that's just basic tests. So, we iterate inside these steps and the delivery here is the prototype. So, most of the time we asked for high-fidelity prototype because we realise that this is a very interesting mechanism to force the designer to put of thinking and I'll just stop at a static level.

So, most of the time, this is what we expect and when they're done with the prototype, then we move to the Expose which is like user testing but this one is a proper step. It's very structured and I would say it's traditional user testing, like strict methodology in lab. It could be in different countries because we operate different countries, but it's very standardised. Here you can imagine that it happened, that we go back to design after the test is if we figure out that things are don't work properly. If it works, and user feedback is at positive and we all agree that this is the right time to move on.

Then we moved to the Spec. Maybe on the specific thing I'll spec here, it has to be super polished. We call it Laser Spec and we put a lot of attention to make sure that, I mean a motion design, yes, but also all the horrible corner cases and the error messages and all those things are covered. So, we really want to recognise that it requires time and we want to stop and go through every single detail so that our tech partner don't have to figure it out as they develop that we just forget something in the spec and they have to find or go back to the team.

So, Laser Spec and final step is the Follow one, what we call Follow step. So, it's a QA pretty much but QA before launch and QA after launch, I think the value of having such a step is two things. One, it conveyed the message to the team follow is important and it happens a lot that when teams just delivers the project, they move on to something else. And then the tech team is trying to wave and say, "Hey, I have a question and oh, okay. I have a question, but I'm on something else already. So, I need to figure out sometime and maybe I forgot." And I mean, with that process, we really want to recognise that teams need to continue looking at the project until it's perfect or it's QA-ed. The other aspect is for stakeholders as well, because it's also a message to stakeholder that the project is not done because the team is still working on the Follow step. So, it's a boosts side recognition that Follow is an important activity and we won't move to another project until this step is completed.

That's the eight steps. So, I'm sure you'll recognise most of them. This is just like naming and the arrangement and rules that make this framework unique and tailored for us. So, that's something that we designed three years ago. We asked the team for the last three years to work like exclusively with this framework. Every single project that we delivered over the last three years went through this process. As you can imagine has been a lot of educational work to make sure that this is happening, but it is happening and it has the expected impact to be honest, it really works. And I think that if you asked anyone in the project organisation at BlaBlaCar, they will tell you about the framework.

So, I think it really works and it fixes the issue that I mentioned at the beginning for the team, the freedom to proceed is kind of obvious. Now, stakeholders are not into everyday detail, they let them proceed. The delivery is a very heavy structure, obviously, but that is well received like we find the right balance between creative aspect and discipline. Talking to the about the collaboration aspect that we discussed collaboration with between squad. Actually, there's one, I mean, simple thing is that it creates the clear moment for chapters involvement. So, you see product and design, as I mentioned, hand-in-hand along the entire process. So, they have shared deliveries. So, they're as much engaged for every delivery. Sometimes product is leading, if we're talking about scope as an example, this is more product driven to design support, project leads and obviously design step and sometimes inspire all those could be design led and product support but, in any case, they worked through the entire steps. Now, all those teams, they know when they need to get in. So in Emerge, they know that you need research and product marketing. It has to happen you cannot deliver problem statement, if you didn't have like the research and product marketing support. On the other way, if a researcher meets the designer. "Oh, what are you working on right now and I said, okay, I'm in the Emerge step of a process." They know that they need research. If they don't have researcher, then something's going wrong and even for leader, it's super easy. If the research leads need to figure out, "okay, what do we 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 need research to get involved. So, it's a simple process for everyone to know when they have something to do and what do they have to do at this stage. But that's why collaboration is significantly improved with that. The other aspect that I mentioned was consistency and if you look at the step and you just remove the name and just look at the concept, you realise that it's actually a 360 approach to project. We try to touch every single lens that needs to be used when you look at your project. So, you start with very business centric and objective, and that then you move to consumer perspective and you look at competition and you figure out the entire experience, et cetera, et cetera.

So, I would say it's a checklist of good practices for a project, but it's just that. The fact that you apply these steps, this mindset with an extreme rigor so, every project has to go through all those steps then it's kind of a guarantee that every project will have a sort of a consistent approach to it and consistent quality. None of our projects should forget about a competitive benchmark or a consumer perspective every single project. That's why I insisted on the fact that you cannot skip a step, this is because this is the guarantee that we will at least think about all those elements and if it's easy and fast - fine but we thought about it. That's what consistency comes from and it works. I mean, I said for both, but yes, we have seen the improvement definitely in the practices and the delivery and the scaling thing, I mean, that's where it's a big magic is if this is your culture and becomes your referential. Then it scales because every newbie, every new person in the team will have to learn about that trust set. And that's our tool for onboarding basically. So, any newbie in a project organisation, 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 do one by one teach it's it becomes an onboarding tool. It's also an interesting tool for performance review.

To be honest, that was an unexpected thing at the very beginning but you realise that because we tried to have a 360 approach to project, then it touches pretty much all the skill that you need to develop if you want to be a great that project from the beginning to the end. So, it happened that we discussed, "okay, you are like all the performing on the scope side, you have very good business mindset and you know how to do that," but you in Immerse, maybe there's something you want to improve here. So, it becomes a grid for performance reviews discussion. 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 both the design step and the specs that we have a design system check. So, it means that if you want to have a validated prototype and validate spec, it means that you had a design system review and your delivery should be compliant with the design system. There's a little checkbox in the daily with that said, "yeah, I'm good with design system." So, that's also very useful for the it scales. It ensures the quality and you don't have to think about it and miss it, if it's not like properly written and last element here is the project stakeholder follow-up. As we scale, there's more and more and more projects that you need to look at and figure out then. And 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 deliveries basically. And if the delivery is great, I mean, if you align on the delivery 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 is autonomy to the team and the reinsurance for stakeholder that they have the critical touch point to ensure that the project quality and advancement. That's it.

So, I mean, to finish the presentation, just like to share some condition for success because I don't think that's such an easy thing to make people using a framework. There are plenty of framework, I mean, which one is the better, which wants to choose. As I said, I'm not like a big fan of creating from scratch and I like leveraging people's knowledge. And I mean, I love that we stand on giant shoulders concept. That's true. I mean, they are. They are giant standards. We need to look at them and recognise their work and their contribution to where we are. So, leveraging existing things, of course, but which one? And I just want to quote a fantastic leader, design leader that I met as I worked at PayPal. Uris Dacosta was the VP of Design of PayPal when I worked there and he used to say, "Worst framework is no framework. Best framework is the one that everybody adopts." And I love that and I think it's very, very true.

There's no unique fantastic framework and is already that important. The key is not there. The keys adoption is the fact that we all align on a framework and we all work the same way. This is the value of a framework it's adoption. So, one bad news is that adoption is not magic. I don't have any magic wand I could share," okay, now my entire organisation will have adopt it." But the good news is where there are plenty of designer here and I would say it's art.

So, it's A-R-T that's probably a good way to remember what's the key for adoption. The first thing it has to be actionable, I really see a very high-level inspiring framework that is adopted by the team and I'm not saying like conceptual framework are not good. That's not what I mean, but it's 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 don't find the connection between the framework and the action. So, what we try to do is to inject tools and specific deliverable, very concrete thing, actionable elements. So, the team can use it. Usage is key.

Second is you have to repeat, I mean, that's endless, I would say. And even with the best framework and the best adoption is you stop repeating it. People stop using it. That's how it is, if someone finds a way not repeating it, I will welcome it because it's very tiring but that's what it is. It has to be repeated. So, you can repeat it as a leader, but you can also create some elements that will make team talk about, which could be create a specific vocabulary. So, when I hear people saying, "okay, now the project we move on, let's go to Emerge. I'm so happy." Because I know that this word it spreads and people use the word. And so, they are into the framework already, so it could come through vocabulary, rituals, there are probably plenty of things that you want to look at to make sure that the team talk about the framework. That's the second key.

And the last key is tailored and maybe go back to the previous slide where you see there are plenty of existing framework. I think yes, probably the key is just pick up the one that you're more inspired or closer to and just make it tailored. I mean changing a little bit and thinking about your own company culture and your daily reality, if there's a step that you feel like, "Hmm. Maybe it's not exactly how we proceed." Well, just remove it or just change the name. I think it's completely fine. I mean, the success criteria should be the team operates, it's their framework. They own it and that's the last part.

So I'll leave you guys now with those aspects of three things, just an actionable, a repeated and a tailored framework, that's a key tool to turn best practices into culture and this morning, I just want to share that. Because this morning, I just received an email from the data team that is very proud to share that their project data framework and it's just done from their side and I think it's absolutely fantastic sign that just leverage the product design framework. They understand how useful it is and they make it tailored to their own team and I think that the fantastic sign of success.

Thank you very much for your attention.