Interview: Bernat Fortet on design and engineering collaboration

Cyrus Roshan, a Software Engineer here at Jam, talked to Bernat Fortet, who is the designer behind Tandem. Cyrus had a wonderful experience working closely with Bernat during his time at Tandem. Bernat is a highly technical designer, with a background in game design, and cares intensely about building the best work environment. "I’m grateful and appreciative for the time we’ve spent learning from each other." – Cyrus.

In this interview, we covered Bernat's relationship with engineering as a designer, early career challenges, the importance of being technical, and much more. Let's dive right in!

On early career challenges

Cyrus:
When you were early in your career, what were some of the things that you struggled with when working with engineers?

Bernat:
Let’s say there’re three phases of my career: teenage amateur web design, then video games, then startups. During the web design stage, it was like, “I don't know what the heck all of this is, I don’t understand anything.” When working on video games the hardest challenge that allowed me to learn was someone saying “that's super hard” or “that will not work”.

Cyrus:
So engineers would think that something was too hard and you couldn’t prove that it's not too hard as a designer, but you think that there should be some way to get it done?

Bernat:
Yes. And in specific engineering teams, people are more like “anything's possible, it’s just a matter of priority”. I was the youngest on the team. So I always thought that I had to win my respect by building it and showing it. And then I built some trust in that.

Relationship with engineering

Cyrus:
As a designer what has been your relationship with engineering throughout your career?

Bernat:
It started with side-project websites when I was 15 and my best friend assumed the role of an engineer to me. Then I did my own thing and I coded as opposed to just designing. Following that, I became a game designer and directed three games.
We had maybe a maximum of three engineers for a few months. I was not managing them, but we had to talk about it if anything went into the game. And there I had ideas that were hard to explain. And if an engineer doesn't see it clearly either I do a better job explaining it, or I just go and create a crappy version of it that proved the point. So pretty much every lunch hour I would ask a question about programming. I’d learn something new and, like, whoa, superpower unlocked! Now I get this. And then at the end of the whole project, I was implementing whole mechanics myself that went into production. So that's how it evolved because it is fun and it gives you power. It's a great way to explain very complex things.

Cyrus:
During your time at startups, was that relationship with engineering different?

Bernat:
As a designer at a startup, the process is more tightly coupled with a lot more back and forth with one designer and one engineer as you're implementing one feature. You spec the whole idea, talk about it, narrow it down, get feedback. It's been different flavors in different companies, but it always had the same thing. And I haven't done one feature with more than two engineers.

Being technical as a designer

Cyrus:
Do you think that knowing how to code has been useful as a designer?

Bernat:
As a designer, I generally know how to do it. I might not do it in a way that's perfect or maybe there are better ways to structure it, but I know it's possible. And I feel that even when I don't know if it's possible, I know that I could figure it out with enough time.

Cyrus:
And figuring out if it's possible, does that mean looking at the APIs or digging into the code directly, or asking people?

Bernat:
A bit of everything. I like asking the request in pointing out the right pieces of code. It feels like it's such a second nature for me now that I don’t even pay attention to that type of behavior or interaction.

Handoff process

Cyrus:
When it comes to the handoff process specifically, how do you go about it? What’s the best way to work with an individual engineer?

Bernat:
It boils down to clarity. When there's no clarity, bad things will happen. Bad means there's back and forth, there are delays, feature creep, doubts, and no clarity on the context or the reasons.
When there is clarity, things go smoother. So my process is that every cycle there’s an opportunity to see what was unclear and make it clear next time. And I think that any person can aim to have that mindset. Getting to a level of clarity either requires a lot of experience and ease of achieving that or just time.

Cyrus:
Is it kind of like a trade-off between the experience you have working with somebody and the time that you have spent on the actual handoff and revisions? So, if you have less experience working with somebody, then you're probably going to need either more time during the handoff or more time with revisions. Basically, you can swap out those three variables.

Bernat:
I could see it working. But I think that there's more to that. These kinds of processes are just one of many processes. Is that a process where you have an engineer taking product initiatives and a designer just going A to Z to get it done? Do you have other teams where there's imperative to solve a problem? And then there's almost like a think tank between an engineer, a PM, and a designer. And it's kind of a huddle that lasts for a week.

Cyrus:
I like that model. It seems like you're also doing some product work there too. As it goes from product to you, who's product and design, to an engineer. The engineer gets to have some input in that whole process. It's not like product immediately stops when it hits you and it doesn't go on to the engineer.

Design feedback culture

Cyrus:
One question I have specifically about creating the kind of culture that was at Tandem, where it felt like I could talk about designs to you and change existing designs, change the spec that was currently being drafted, even whiteboard, and just try out new things. How do you go about creating that culture of design feedback?

Bernat:
A designer can only get feedback when their artifacts are exposed. Pre-Figma that only happened when you upload something to Dropbox, which added friction and delays. With Figma it’s more open. And it turns out I'm a pretty open designer. If you want to go through them, please be my guest.
The other part is that it's hard to get feedback from users. If you're working in the kind of company where you use your product on a daily basis, which is not common, then your teammates are users. So they're the most immediate source of information. If you can, see the bias and take it into consideration. So you can get quick feedback from someone that uses this.
Going back to the exposure, I've done it more on and off, but I've pushed myself to be maximum exposed by doing live streaming. So anyone sees how it is designed so that lets go up some anxiety. Maybe it's some confidence that you can design good stuff. I think that it's this mantra, which is “you're as good as the feedback you can get.” So I did design showcases, I put things in Slack and I shared user interviews. Those are the exposure points apart from open access to the files.

Cyrus:
That's really cool! I like the whole model of designing in public. And I really like how you mentioned the user interviews and the steps that go before the design, even before the prototype of the spec. Thank you for doing this interview!

Bernat:
Totally, this was great!

Thanks for reading, we hope you enjoyed the interview. You can follow Bernat on Twitter and check out his website bernatfortet.com