Insights:
What we do, essentially, is make it easy to start selling flights right away. Duffel has built a platform that allows any developer to integrate flights into their offering through our API, with no set-up fees and you don’t need any third-party activation or any accreditation either. Basically, our platform can be used to build a superior travel experience for your customers. With our documentation and testing environment you can search and book flights, you can offer seat selection, you can offer paid extras for your customer. We have amazing travel support as well, so we essentially take care of A to Z in terms of integrating flights into your offering and being able to offer an amazing customer experience with a very low barrier to entry.
Thank you!
It’s a funny question, because often when I talk to people about Duffel and say I’m a designer, they say, “well it’s an API so why is there a design team if your product is invisible, in theory?”.
I think it’d probably help to explain the structure of “Design” at Duffel to begin with. It’s split into two—Product Design and Brand Design, and we come together as one overall Design team. Product Design is embedded within the product teams, and Brand within Marketing, but we also both collaborate with a whole host of different teams within the org. So, while perhaps we plan our OKRs and our quarters as a Design team, we also plan together with our embedded teams, and then of course all the different projects that happen in collaboration with everyone else as well—because we stay as one overall Design team, it just means that we have that overall view, vision and drive for design that is maintained across teams. We then also have that influence within those external teams as well, to create an overview of what Design is and should be at Duffel.
I must add, as well, that in terms of Product Design, as part of our product offering we also do have a dashboard that is beautifully designed by the product team!
When it comes to working together, we have weekly design critiques, so we have, on the Brand side, a large overview of what is happening on Product and vice versa—so although we may be separate teams that then come together as one, and thanks to that we’re collaborative and have an overall vision. For example, in our design system, we share a lot: we have our foundations and asset libraries that we share, and then afterwards we split up usage where we deem necessary.
Really, at the core of why Duffel cares about design though, is that Duffel was co-founded by a designer, Tom Bates, and so really from day one design has been at the forefront of Duffel. Although our CEO, Steve Domin, is not a designer, he is incredibly interested in design and if he had the time he would be present at all of our design critiques (and even during doing our stand-ups, probably), so you just really see that manifested in the way that the company works with us. But as I said, it’s been there from day one.
I think the main one is just the setup of how teams work with us—although perhaps this isn’t necessarily directly trickling down from him, the leadership team supports and influences the way in which we all work together. Basically, the Design team is not an enabler in Duffel—we’re not seen as this agency that you come to with a brief and then, “please get this done, see you when you hand it off”—we’re instead brought in very early in projects to directly influence and contribute to them. Many of these projects actually involve our CEO as well, particularly on the Marketing side, because he is super involved in anything that is website related and brand related, so we actually work with him very closely. Product design does too, but of course I’m on the Brand side so I’m going to be speaking to that a little more.
Within our project processes, he is often a stakeholder in for example a webpage that we’ll work on, and he will be there doing the brainstorm process with us, we’ll be bouncing ideas off each other, and I think that’s quite rare for a CEO to get involved like that, and really care about close collaboration with a design team. This is manifested also outside of website projects. For example, in sales enablement projects, we will also have close collaboration there, and he will really respect our influence and our take on things as well.
Mainly, brand awareness, consistency and credibility—but of course, conversion is the ultimate goal! Simply put, you cannot have just a well-designed website without implementing all of the different aspects that come into a site that is beautiful, works well, and uses best practices throughout, which will often organically turn into a website that converts well.
At the end of the day, in our case, we want you to sign up—so we want you to be not only interested and drawn in by our brand and our website, but we want that interest to convert into you signing up and actually using our product. So, ideally, we’ve drawn you in by telling you our story and showing you who we are in an honest way through our brand and applications. I think that if that shines through then we have done our job, and that’s all very nice, but at the end of the day it’s the numbers that really show you, “okay this is speaking to our target market, and this is working and we are presenting ourselves in the way that we should”.
Yes. I think obviously most companies are, as are we, trying to find that balance of quality versus speed; which is very much easier said than done.
But I think, as I was saying earlier, because Duffel cares about design, it’s all about compromises and coming together to figure out, “we care about X so we’re going to do X”. I think it all boils down to time essentially—we want to dedicate enough time for research, wireframing, exploration, and then especially refinement at the end, which is the hardest bit to find time for, in my experience.
We’ve essentially embedded the fact that we’re going to need that much time into our planning as much as possible, especially as the team grew, we just understood that we needed to get in there much earlier in terms of planning and understanding “realistically, this is going to take X amount of time”. We also need to understand that we’re going to need to be flexible because if we want to get to that certain level of quality, then we absolutely will have to take more time.
Time is the biggest trade-off here—obviously as a startup you want to be agile, and you want to move fast, but you’re consistently trying to make the smartest possible trade-off, and understanding where to cap it is super important too. Understanding that a certain product is good enough to go and we can iterate on it, but that “good enough” is actually very good. This is very cheesy, but it is really reflected in one of our company values as well: “Build with pride”. We don’t want to stop at ‘good enough’, we want to keep going beyond that—we absolutely use that in the way that we work in design. When we collaborate with the marketing team, they often have had to make a lot of compromises with us where they go,”How about this deadline?” And we go, “No, not that deadline, could we work this other deadline because we’re not going to have a good output if we’re going to meet the original deadline.” It’s being realistic, being communicative and making those trade-offs together.
Yes, although the pressure isn’t to lower the standard per se—it’s to deliver quickly, which in turn would lower the standard.
We’ve overhauled our process recently to avoid this.
Ahead of the incoming quarter, we will have a planning week in which we scope out the priorities and planned work for the team. Afterwards we’ll sit down, and when it comes to website work, we will have basically these task forces for each page that needs conceptualising, designing and building. We know who is going to work on which aspect, and then we sit down and do a bunch of explorations and research, plus anything necessary to really be able to just have a much better estimate of the scope and timeframes that are going to be necessary for the project.
Previously, we had run into trying to make those estimations with less information at hand and less exploration ahead of time which meant that we would go “Okay, we can get this done in a week and a half”,—then we would get to halfway point of that week and a half, and we would understand the scope is actually not what we initially thought it was, and we’d have to delay the project delivery by X amount of days. That’s the moment in which the design team gets that pushback from Marketing or from whichever other stakeholder that perhaps needs that page to be done within the initial timeframes.
We basically got into that situation a couple of times and we understood, that we needed to back to the base, back to when we estimate, and we need to really be sure of our estimations.This is allowing, of course, for a flexibility of a couple of days, but ultimately we wanted to feel so much more confident in our estimations and in our quarterly planning, because the team was large enough that if one thing slipped, everything else started slipping, so we wanted to just be able to create a plan in which everyone is comfortable, in which everyone is working in a healthy way and also achieving what they want to achieve. We wanted to have the certainty at the beginning of the quarter that for the rest of the quarter what we had estimated was as correct as it possibly could be with the information at hand.
It truly is essentially bringing the initial brainstorming sessions at the beginning of the quarter.
We usually start off with a brief with all the key information, such as problem, solution and key metrics that we may want to hit, or why are we doing this and then this is roughly what we think we want to do. Based on that, the designer that is working on that page will then take that page and start a working file on Figma, start doing research, grabbing wireframing, executing on all that exploration process. We then come together and have a brainstorming session with relevant stakeholders to discuss those proposed structures and play around on the file together, until we reach a place in which we’ve defined a skeleton or a ‘story’ for the page and modules that allows us to understand scope and timeframes much more realistically. By that point, you’ve already essentially started on the project and you can already imagine the level of interaction or visuals for it, in order to add more accuracy to our estimates. Afterwards, all you really need to do is the remaining three-quarters of the project, if you will, with a lot more confidence.
Gosh, a long time, is all I can say. It’s weird, because this website has gone from our API documentation and a landing page to a full-fledged site since the time I’ve been at Duffel, which is two and a half years, and we’ve gone from that to what we have now through so many fluctuations. If we were to do it from scratch, of course it wouldn’t take two and a half years—we’d be doing something wrong if that were the case!
I guess we’d have to get a brainstorming session in and figure that out. I cannot tell you with confidence right now, but that’s exactly why we do the brainstorming sessions. A long time, for sure, and a lot of people involved.
The Duffel site as you see it was built by a lovely team: myself and two other brand designers (Jack and Medeea), two front end developers (Igor and Sevda), and three marketers (Krista, Ellen and Jonny), all entirely in-house.
Basically, per page we usually have one designer, one front end developer, and one key marketer that will own that page, so it’s a bit of a task force, if you will, so that it’s a lot more concentrated and there’s closer collaboration. But our process to work on the website has changed so much over the years because with a growing and changing organisation, our teams as well have been largely fluctuating (as they are in most start-ups). So the latest process that we have is one that has come from plenty of retros, plenty of, “What are we doing right? What are we doing wrong? What could we be doing better? This was kind of janky when we did X project, how can we improve it?”.
Recently, we have just completed a migration to a CMS, which is going to significantly change the way in which we work, so we’re currently crafting a new process to work with the CMS and ensure that we can also find a way that really works and that keeps all the different aspects that we were using before. We’ve worked really closely with the front end team to ensure that this migration still allows us the same freedom that we had before when everything was custom built, and of course we’ll continue working with them and marketing to create this new process.
Yes. As I said, now we’re reassessing everything, but the most recent process is for each new page that needed to be built we designated a squad of a designer, a developer and a marketer that owned it, to work on it and get it over the line.
The first thing is that we basically, as a brand team, collaborate together a huge amount, so no one is working in silos and just going off and doing something and then suddenly the page is live and everyone is like, what’s going on? There is a large amount of collaboration between us, there is a large amount of sharing work, not only within the brand team but also within the overall product team as well. We’ll do critiques very often, we’ll do syncs, and then, as one of the designers that’s working on the website but also overseeing the work of the team super closely, keeping an eye on how everyone is working and just making sure that we’re all coming together often. We also have a full-fledged design system that we really make an effort of upkeeping, and that really serves its purpose when it comes to cross-collaboration—bridging that gap and ensuring that if you’re linking to the right components and syncing with the team enough, then you will keep that consistency throughout.
Oh absolutely. No, I’ve worked in teams where that has happened. They’re like, do you like this? And I’m like, what’s going on?
I think it’s a shared responsibility amongst the team, I don’t think it necessarily falls on just one person specifically. We all have the responsibility of ensuring that not only our own personal work is of the quality that we want it to be and that it’s also the consistency that we want it at, but we also have the responsibility to speak up during design critiques and really make sure that we are a valuable team member in that way, giving honest and constructive feedback and during these critiques—that’s exactly why we hold them and why we think they’re so important.
If you think about it from a more team structure perspective, on the Brand side I am the one that is responsible, to keep that consistency amongst all of our work. This essentially means that I spend a lot of time with the team collaborating—and rather than just saying “Don’t do this, don’t do that”, I approach it more from a perspective of “How about this?”, from which we work together.
That’s the way that we found, over time, that was the best way for us to work—to just spend more time together on projects and reaching conclusions together, because that not only just makes the work a lot more fun, but also makes you reach conclusions that are so much better as well.
I think that there are ways to touch on quality without necessarily being so blatant about it. You can definitely steer a critique in a certain way and make it constructive without spelling out “this doesn’t meet quality standards”. more so going, “What about this option, or have you thought about this other option?”
There is definitely a very empathetic way that one can help the team reach a higher level of quality without it having to get to that tense moment. I think that perhaps more from manager to designer perspective this very much applies as well. Sometimes, of course, there will be a time when you say, I actually think we need to spend more time on this because it’s not at the level where we need it to be, but it doesn’t have to be said in a way in which the designer feels that their work is not high quality, but more so is empowered to say, “Okay, I know that I can get it to a better place, so what can we do to get there?”
Exactly, exactly.
Well, it’s never really done. You can reach a certain ‘style’, and then apply it across.
Oftentimes with websites in particular, it’s common to try one ‘thing’ out, love it, realise that it really fits the brand vision and direction, and decide to apply it across the rest of the brand applications. I think to ensure guaranteed freshness, it’s more about applying incremental changes as you go along to ensure guaranteed ‘freshness’, rather than necessarily doing a whole refresh every six months.
I think usually, an overall look of a website, it should be reviewed at least every 6 to 10 months. That’s the longest estimate, and it is assuming that you are applying incremental changes throughout—if you’re not, then it’s much sooner, as you get to a staleness much earlier. You could apply tweaks here and there according to, perhaps, any changes in the brand that you may need to implement based on a target market that is changing, or better accessibility practices, or perhaps you are changing your mock-up styles to really reflect the product better.
So, if you are applying all of those incremental changes as you go along, then do a big sit down with the team and carry out an audit of the status of the brand and website, then your freshness could remain for 6 to 10 months—but I can’t say with absolute certainty because it is so dependent on the company itself and what the company needs.
There are some trends that you can’t help but be curious about and perhaps try to implement, but I personally think you have to be wary of them, as it’s safer to have a long-lasting design that maybe errs on the side of classic. You definitely want to have a mixture of both though, and I don’t think there’s anything wrong from time to time attempting something that may be more temporary, as long as it doesn’t directly influence a huge part of your brand and therefore website without some serious thought process behind it.
I think with these types of current, or more passing trends you can definitely try them out in smaller scale projects or pages, say a campaign for example. When you try it out on a smaller scale elsewhere you can assess, “If we were to play around with the idea of implementing this on a large scale, what would be the longevity of it?”. You have to think about what the implications are of applying a certain style and then potentially six months down the line suddenly, for example, pill-shaped buttons look incredibly dated, or suddenly a new study comes out that they’re just actually very inaccessible or something like that. You really have to just take into account how it could snowball into a decision that you have to backtrack, really.
Exactly, but it’s always good and fun to experiment, and not be scared of doing so.