How Craig Fitzgerald built a two-person design function with unusually broad ownership, and what he wants to protect as the team doubles in size.

The Capability Study goes inside one company’s design function and asks a simple question:
What makes this team effective?

For this first issue in the series, we’re taking a look inside the FinTech scale-up Yonder.

Yonder is a rewards card built around a simple idea: make spending feel more rewarding. Rather than competing with the likes of Monzo or Revolut to become someone’s main bank, it focuses on rewards people actually want to use, from restaurants and travel to independent brands, theatre and experiences.

The company has around seventy people, and its design team currently has just two. That is about to become four, but the size of the team is part of what makes it interesting. Design has played a role in the company's journey from the very beginning, shaping the proposition, has meaningful ownership of the product experience and increasingly looks for ways to improve how the wider business works.

I sat down with Craig Fitzgerald, Yonder’s Head of Design and its first design hire, to understand how the function has developed, why it has stayed deliberately lean and what he wants to preserve as the team grows.

Small on purpose

Craig’s route into design leadership wasn’t especially planned. It grew out of a career spent in small teams, often as the only designer in the room.

Q: How did you go from graphic design into product, and eventually into design leadership?

A: I’ve been drawing since I was about four. I used to spend whole weekends doing it. I studied art through school, and when it came time to leave I had a slight panic because I didn’t want to be an artist. There’s no obvious pathway to it, and I’ve never had that kind of risk appetite.

Graphic Design became a way of applying those creative instincts to business. I freelanced through university, then joined a small studio in Essex where I got to do a bit of everything. I still think that kind of breadth is incredibly valuable early in your career. You get to work out what you actually enjoy, what you’re good at and the kind of environment you want to work in.

What I realised quite quickly was that I loved building things with people. I found it much more satisfying to make something that people would use over time rather than to design a poster that ends up in the bin a few weeks later. That’s what took me towards UX and Product Design.

One of my first real breaks was a startup called YourTour, where a founder I’d worked with before wanted to turn audio tours into a marketplace. He trusted me to take full ownership and design the product from scratch. That taught me a lot very quickly, from going out into the field and speaking to people, to working closely with engineers and understanding the relationship between design intent and what is actually buildable.

It’s also where I realised I really like early-stage companies. I like the breadth, the scrappiness and having to muck in across lots of areas.

Q: And the leadership part came later?

A: Yes, it happened pretty organically. In a lot of my roles I was either the only designer or the first designer, and when that’s the case you naturally start taking responsibility for things.

At SilkFred, before Yonder, there wasn’t really any user research and there wasn’t a design system. I knew both were important, so I started advocating for them and trying to make them part of the culture.

I remember the CEO after our first research session saying, “I can’t believe we’ve never done this before. Why don’t we do more of these?”

That’s one of the things I’ve learned and really believe about leadership. You don’t have to be given a title to start leading. You start doing the things you believe need to happen.

Yonder was similar. My wife was at ClearScore and three people were leaving to start a credit card company. They needed a designer, I joined as the first hire, and I was basically the person everybody came to for anything design-related. The function and the way we work have grown from there.

Q: Yonder is now a seventy-person company with a small design team. How intentional is that?

A: Very. One of our philosophies at Yonder is to build really lean teams that are still incredibly powerful, so I have to build the design function within that context.

I can’t come in and say I want a huge research team, a brand design team, a content team or lots of other specialist disciplines. That might make complete sense somewhere else, but it isn’t necessarily right for the company we’re building.

That means our designers need to be more T-shaped and more generalist. I intentionally didn’t hire dedicated researchers at the beginning because one of our advantages is speed. The more people you have, the more communication channels and hand-offs you introduce.

Sometimes it is simply much faster for the designer to go and speak to the customer themselves, understand the context and then immediately go and create something.

If I was at a much bigger company, I might make completely different decisions. I might split research out or have more specialist functions. It largely depends on the context.

For the way Yonder works today, lean teams with broad skill sets make the most sense.

Earning the room

That lean model only works if designers have room to influence decisions. At Yonder, that trust was not assumed. Craig had to earn it, and one of the earliest opportunities came before the company had even settled on what it was going to build.

Q: Yonder nearly became a very different business. What changed?

A: When I first joined, the idea was about giving people who were new to the UK better access to credit using open banking.

Tim, our CEO, had experienced the problem himself. He moved here from Melbourne with a strong career, had worked at Accenture and had a mortgage, but when he arrived in the UK he basically had to start his credit history from zero. He couldn’t even get a phone contract. So the thinking was: can we use open banking to solve that problem?

I started talking to the people we thought had this problem. What we found was that in your first twelve to eighteen months in a new country, getting a credit card isn’t actually one of the main things you’re worrying about. You’re trying to find somewhere to live, get settled and build a life here. Credit becomes important later, when you start thinking, “Actually, I might stay. Maybe I want a mortgage. I need to build a credit score.”

So we kept talking to people. We’d ask what credit card they had and a lot of them would say Amex. We’d ask why and they’d say, “Well, if I’m going to spend money, I might as well get something back from it.” Then we’d ask what they had last used their points for, and quite often the answer was basically nothing.

That’s when we realised the more interesting problem wasn’t just access to credit. It was building a rewards card where the rewards were actually things people wanted to use. That became the opportunity we went after.

Without a designer coming in, talking to those people and challenging the assumptions we had, I genuinely don’t know whether we would have ended up here at all.

Q: How much trust did design have at that point?

A: The founders already believed in design, which definitely helped. Tim has always had strong opinions about design and customer experience. When I joined, we didn’t even have our FCA licence yet, so his attitude was basically, “You’re going to spend the next nine months talking to people and figuring out what we should build.” If I wasn’t speaking to customers enough, he’d be asking why.

But his philosophy was also, “I’m not just going to trust you because you’re the designer. You need to earn that trust.” I think that’s fair.

A lot of it was about showing value early. If I ran a workshop, I’d explain why we were doing it and what we were trying to get from it. Then we’d use the output and test the ideas. People could see what happened because of the work. You can’t just tell people design is valuable.

You also have to build relationships across the business. Regulation is obviously incredibly important for us, so there are often grey areas where design has to work closely with other teams to make a call. If you’ve built trust with those people already, those conversations become much easier.

Q: Was there a particular moment when you felt people started to understand what design could bring?

A: One of the funniest ones was our Chief Risk Officer. He’d never worked with a designer before and genuinely asked, “What does a designer even do?”

I remember showing him one of the first concepts for how our rewards partners could look in the product. It was a really nice image with elegant typography and a little bit of motion. He looked at it and said, “This is the most beautiful thing I’ve ever seen.”

It makes me laugh because, from a design perspective, it wasn’t anything particularly groundbreaking. But it was the first time he’d really seen someone take an idea the team had been talking about and bring it to life. Suddenly, it was tangible.

Ownership without consensus

That trust shows up most clearly in the way Yonder structures decisions. Designers work closely with PMs and engineers, but the company is deliberate about who owns what.

Q: How does design actually work day to day? What do designers own?

A: We work primarily in product squads. Designers sit with the PM, engineers and whoever else is relevant to that area. If you’re working on rewards, you might be close to partnerships. If you’re in growth, you might be working more closely with marketing.

We believe in single-threaded ownership at Yonder. Every function has things it is responsible for, and while we take feedback seriously, we don’t want to make decisions by consensus.

With product, PMs are ultimately responsible for what we build and why. We work very closely with them on understanding the problem, but design is responsible for how that gets realised in the product.

People will have opinions, including the CEO, PMs and engineers, and we should listen to them. But ultimately, the design decisions are ours.

There isn’t a senior design sign-off where you sit in a critique and somebody says, “This is rubbish, go away and do it again.” You get feedback, you make the decision and then you take responsibility for what happens next.

Then we measure the outcome. If we were wrong, we learn from it - but hopefully we’re right more often than we’re wrong!

Q: What’s a piece of work that best represents that way of operating?

A: One I’m still really proud of is the rewards redemption experience.

For most of our rewards, you don’t have to show someone a code or remember to enter a discount somewhere. You just go to the partner and spend normally. Then you open Yonder, we recognise that you’ve spent at one of our partners and ask whether you want to pay with pounds or use your points.

It feels incredibly simple, but there was a huge amount of work making it feel that way.

From the design side, there were loads of animations and interactions, and it was a nightmare for the front-end team to build. But, this was one of those situations that I talk about later, where we pushed to spend extra time getting into the details because it was such a high-emotion moment in the product. It’s where the promise of the product really comes to life, so we decided it was worth spending more time on.

There was a lot of complexity behind the scenes too. The engineering team had to work out how to reliably match transactions with the right rewards partners and deal with all the edge cases that came with that.

The customer doesn’t need to know any of it. They just spend, open the app and use their points. We built it years ago and it’s still one of those core moments in the product. We still get people saying, “I can’t believe how easy that was.”

Q: You care a lot about craft, but Yonder also moves quickly. How do you decide when to push for that extra level of quality?

A: That’s one of the biggest skills we’ve had to develop.

There are times where we’ll design a really nice solution and an engineer will tell us it’s going to take two weeks to build. We don’t always have two weeks, so you have to ask what the three-day version looks like, or even what we can realistically do in a day.

For that to happen, you need designers who can work with engineers to find that version rather than getting frustrated that they can’t build the perfect thing. But you also need to know when to push. The rewards experience is a good example of that. Sometimes the detail is worth the extra work because the moment calls for it.

For me, that’s part of the craft. A good designer should be able to understand the context they are working in and make the right decision for that context. What good looks like at Amazon might be completely different from what good looks like at Yonder. That doesn’t make one better designed than the other.

Beyond the product

The team’s remit doesn’t stop with the product itself. Craig is interested in where design can remove friction elsewhere in the business, particularly when the answer is not simply to give the design team more work.

Q: You’ve said before that you don’t want designers to be treated simply as an input into product. What does that mean in practice?

A: It’s something that has frustrated me for years. I think the best design functions look for opportunities to add value to the whole business, not just plug into product.

A good example is our partnerships team. When they’re speaking to a potential partner, they want to show what that company could look like inside Yonder. Historically they’d come to us and say, “Can you mock this up in the app?” Then I’d go away, find the imagery, build the screens and send them back. It might only take an hour each time, but it still uses design time.

So we started asking whether a designer actually needed to be involved every time.

Bryony Szekeres, who at the time made up the other half of the design team, led on this. We built a tool where the partnerships team can add a company website or some imagery and generate the product mockups themselves.

Then we looked at what happened after the call. They would normally create a proposal deck, which again involved templates and design time, so we built another workflow where they can take the Granola notes from the conversation, combine them with the mockups and generate the basis of the proposal.

The time saving is useful, but the business value is more important. If partnerships can move faster, they can close more deals. More partners improve the proposition for our customers and support the growth of the business.

There are loads of opportunities like that, and I think designers should be asking where they can add value to the business rather than only asking what product work they can do.

Q: Is AI changing what you think designers should be capable of?

A: We’re very AI-forward as a company. We push everyone to experiment with it because I think we’re still working out what it actually changes.

I recently shipped an A/B test myself. I built it, opened the pull request and used Claude to help fix a few bugs because the engineer in our squad was out. I obviously still had another engineer review the PR before we pushed it live, but the surprising thing was that it wasn’t actually that complicated.

That doesn’t mean every designer needs to become an engineer. But the boundaries around what we can do are changing. There are things that previously would have needed another team or another person that you can now make yourself.

I think designers should be curious about that, rather than protective of what the role used to be.

From two to four

Yonder is now growing the design team from two people to four. More capacity matters, but the bigger question is what kind of designer fits the environment Craig has described.

Q: Who are you looking for?

A: The phrase I tend to use is a scrappy operator.

Someone who isn’t waiting around for the perfect product spec from a PM. You need to be able to start pulling ideas together, get people around them and move forward without having every piece of information you might ideally want.

That breadth matters here too. You need to be comfortable moving across different kinds of work, whether that is something for marketing, a research project or a polished product prototype.

The spike we look for is visual and product craft. We work closely with PMs on figuring out what to build, but design has to bring that thing to life and carry the quality of the Yonder brand through the product experience.

You also need to work well with engineers. Sometimes the solution you want is going to take two weeks and you need to find the three-day version together. Other times you need to make the case that the extra work is worth it.

And increasingly, we want people who are curious about AI and willing to experiment with what it changes.

Q: I challenged you to describe that person in three words. What did you land on?

A: Someone who cares.

That’s three words, right?

The designers I’ve seen be really successful here care deeply about the quality of what they put out. Sometimes that means spending an extra hour on something because it still feels a bit bland. Other times it means recognising that you’re not as strong at research as you want to be and doing something about it.

It’s that level of conscientiousness. Genuinely giving a shit about the quality of what you make.

The Capability Read

What I find most interesting about Yonder is that the impact of the design team is not really a story about doing more with less. It is a story about creating the conditions for a small team to matter.

The team is lean, but it is not narrow. Designers are expected to understand the customer, work closely with engineers, make decisions and take responsibility for what happens next. That breadth gives them more influence, but it also asks more of them. There is less separation between understanding the problem, making the decision and living with the outcome.

There is a common thread running through almost everything Craig describes: very little responsibility is pushed somewhere else. The designer who helps understand the problem stays close to the solution, close to the engineer building it and close to the outcome afterwards. In a larger organisation those responsibilities can easily become separate jobs, teams or stages in a process. At Yonder, keeping them close together appears to be a meaningful part of the model.

That only works because the wider company supports it. Craig talks a lot about trust, but the important point is that trust has substance here. Designers are not simply invited into conversations. They own decisions, and they are expected to explain their thinking, make trade-offs and learn when they get something wrong.

There is also a useful tension in the way Craig talks about craft. Yonder clearly cares about quality, but not every problem deserves the same amount of time. The judgement is in knowing which moments are worth pushing for and where speed matters more. The rewards redemption experience is a good example of that. The team chose to spend more time on it because it was a moment where the value of the product became tangible for the customer.

The same thinking shows up outside the product team. The partnerships tooling is interesting because the goal was not to make the design team faster at producing mockups. It was to remove the need for the request in the first place. That is a different way of thinking about design capability. Influence does not always mean more involvement. Sometimes it means creating a system that lets other people move without you.

There is a tension in that, though. Some of the things that make this model effective are easier to maintain when the team is small. Breadth works when people can stay close to the problem and to each other. As the company grows, more products, customers and complexity may eventually make some specialisation unavoidable. The challenge is not keeping the organisation small for the sake of it, but knowing which parts of the current model are actually responsible for its effectiveness.

As Yonder grows from two designers to four, that is probably the real challenge. More people will create more capacity, but the value of the current model comes from the ownership, judgement and breadth that sit behind it.

Craig is not trying to build a bigger version of the team for the sake of it. He is trying to add capability without losing the things that made a very small team effective in the first place. And that is not only about structure, ownership or process. It is also about the kind of environment those things create.

One part of our conversation that stayed with me was Craig talking about the culture around the team. He gave me one answer that felt like the right place to finish:

“Someone once asked me in an interview how I feel on a Sunday. I told them the truth is, I can’t wait to get in and see the team. Which probably tells you most of what you need to know.”

Having spent some time with the team myself, I can see why.

What I take from Yonder is that capability is not really a headcount question. It is about the conditions around the team: how much they are trusted to own, how close they stay to the work and whether the people in it care enough to keep pushing when the easy answer would do.

Yonder has created those conditions with just two designers. The interesting part now is whether they can preserve them as the team grows.

Think Yonder sounds like the kind of place you’d thrive?

Gale & Co. is currently helping Craig grow the team. We are hiring:

1 x Senior Product Designer (Spend Squad)

1 x Mid Product Designer (Growth Squad)

If you think Yonder sounds like the kind of place you’d love to work, we’d love to hear from you!