Meet Brian Lovin, Product Designer at GitHub and Co-host of Design Details Podcast

Hi Brian. Thanks for taking the time. Let's start with who you are and what you do.

Hey, thanks for the invitation! I'm a designer, developer, podcaster, wannabe writer, and internet tinkerer. I'm currently building things at GitHub, specifically working on the new iOS and Android mobile apps that shipped in March.

I've been bouncing between San Francisco and New York recently, but I'm currently living in San Francisco. I've lived here for most of my post-college life, so it feels like home. But I'm originally from Colorado and went to school in Texas.

On a regular day I'm focused on designing GitHub's mobile apps. I also have a small internal side project that's trying to help our design team share work in progress more transparently. Both of these projects are intensely fun to think about, so it's a really exciting time to be at GitHub.

Outside of work, I co-host the Design Details Podcast with Marshall Bock. The podcast has been a 5-½ year side project at this point, originally started with my friend Bryn Jackson. I've been recording weekly for a long time, so it's become a weird staple in my routine, but it's somehow still fun and interesting. Right now we're trying to figure out how to make the show entirely listener-supported through Patreon, which is an entirely new challenge to keep me busy.

I'm also constantly tinkering with building applications (primarily web, and recently started playing with SwiftUI), launching miniature websites, and making my own personal site into a digital garden.

What's your design journey? Please walk us through it.

Like a lot of people my age, I was really influenced by products like Neopets, Myspace, and WordPress. The mid-2000s were a totally different time on the web: it seemed like companies put a lot of work into making things fun. The fact that you could override your Neopets profile with crazy marquee tags and glittery backgrounds seems entirely impossible in today's product landscape. But it worked back then, and it got me interested in CSS, HTML, and then eventually into PHP and JavaScript.

I always liked making websites. It's still pretty magical to me, all this time later. Type some words, watch a page refresh with your changes. It's fast and flexible, it's creative but constrained, it requires thinking in new ways and staying on top of new technologies. It scratches a lot of my itches.

Through high school and into college I was building websites constantly. My first "big" one was called Elite by Design. I wrote Photoshop tutorials and listicles about "Top 50 Free Photoshop Brush Packs" and that kind of junk. Some of those posts hit the first page of Digg, if anyone remembers that kind of excitement. That period of time was special, though. Blogging felt way more communal, and I remember being able to meet all sorts of interesting people through comments and blogrolls. Simpler times!

Anyways, Elite by Design exposed me to design tools like Photoshop, and helped me go deeper on CSS and HTML. When I headed to Waco for college, I started a music website called The Kollection. The website shared music from independent artists, largely targeted at college students. We built some really neat relationships with small artists who have since gone on to big things. At its peak, we were doing a million visits per month, had 50 "staff" writers (a random, but intensely cool, group of college kids spread around the world), and we were being invited to concerts and festivals all over the place.

A few years into running The Kollection, I found myself becoming more interested in the application more than the music. Thinking about how to clearly organize a massive and quickly-growing library of songs, thinking about the playback experience, saving and sharing songs, helping artists expand their reach, and eventually, how to make money, all became way more interesting problems.

Luckily for me, during that transition I managed to get in contact with Buffer, a small startup at the time. On February 12, 2013, I tweeted out that I was a fan of Buffer (the tweet still exists) and for whatever reason, Joel (Buffer's CEO) saw it and reached out.

I feel really lucky about that period of time. I had no clue what I was doing, but Joel and the small crew at Buffer took a chance on me. For my third year of college I worked part time, starting with smaller projects like redesigning the About page, or designing a job listing. Eventually I graduated into working on the core product. By my senior year, I'd managed to organize my class schedule so that I could work full time on Buffer.

Do you have any tips how would you go about getting a first design job today?

It's so hard to answer this – I feel insanely lucky with how things worked out for me in the past decade. Part of the luck was "pure luck" – right time, right place. I think part of my luck was just stirring shit up, everywhere I could, and seeing where sparks collided. With that in mind, here are a few things that might be worth trying for someone starting out:

• Make things. Solve your own problems. It's okay if the early versions suck.
• Make more things. See if you can solve someone else's problem. It's still okay if things suck. If you know they suck, even better: you're self aware, and can recognize that you have room to grow.
• Confirm that you made things better by talking to people and sharing your ideas with anyone who will listen.
• Write about the things you made and what you learned by making them.
• Try to work on something for at least a year, making regular incremental improvements. Learn to use your limited time to prioritize changes and maximize the impact of your effort.
• Talk openly about what you're learning day to day. Write in public. Tweet more.
• Reach out to people with specific questions. If they give you advice, follow up – even if you decided not to take the advice.
• Be respectful of a mentor’s time.
• Don't call yourself a junior designer. Just say designer. It's cleaner that way.
• Follow people and join conversations in other industry circles: user research, copywriting, illustration, brand design, marketing design, venture capital, frontend programming, design tools, creative coding, and startup founders might be useful places to start.
• People want to work with curious, motivated, and energetic people. Don't worry about "knowing it all" yet - the fact that you're willing to learn things and absorb advice is enough.

You worked for Buffer, Spectrum, and Facebook. Could you share some highlights/lessons learned from each of these experiences?

Buffer was really where I cut my teeth as a product designer. When I first started as a part-timer in college, I worked on a lot of external pages, like redesigning the About page and cobbling together job listings. They allowed me to dive into the front-end, pick up a little PHP, and generally have a lot of creative freedom. But eventually I started gravitating towards the core product – at the time Buffer was primarily a tool for scheduling posts on Twitter, Facebook, and LinkedIn.

Through this transition to product, I was suddenly exposed to a lot of new ideas to me at the time: what SaaS was, and all the underlying metrics and financial mechanics that made it work. CCA, LTV, churn, and burn – these were all new terms and acronyms and I remember just soaking up as much as I could.

I felt incredibly lucky to have so much freedom to make decisions and touch all the different parts of Buffer’s product. But as a young designer, I became increasingly worried that I was missing out on some other kinds of learning, specifically things closer to the craft. I wanted a design manager, and I wanted peers to help me grow.

After a little over two years at Buffer, I made way for Facebook and joined the Payments team. I had a fantastic manager, Amir Mesguich, who really provided the feedback and guidance I needed to grow. He pushed me a lot, opened doors for me to present to org leaders, helped me to lead projects on my own, and in general was a very thoughtful mentor.

I find a lot of younger designers wondering whether they should go to a startup or a big company. There's no right answer, as far as I can tell. There are good parts and bad parts to both, and you'll pick up good habits and bad habits at both. Looking at my own experience, I like to push back a bit and say: why not give both a try?

It seems easier to go from a startup to a big company, only because the compensation and risk profiles move in a more favorable direction. I can see a young designer starting out at a place like Facebook getting very comfortable, very fast. Those free lunches become a regular part of life after a while, and it's easy to forget how little the campus represents the average experience of a designer.

At Facebook I had a significant pay raise, and each review cycle I kept getting bumped higher and higher. These are great moments to have, and were a huge confidence boost. But I do remember towards the end of my time at Facebook recognizing my own dwindling appetite for risk. I was getting comfortable. And that's not inherently bad, but it freaked me out.

So I left to start a company with Bryn Jackson and Max Stoiber called Spectrum.

You also co-founded the community platform Spectrum. What was the idea behind it?

In 2015, I co-founded a podcast network with Bryn Jackson and Jonathan Cutrell called Spec.fm. This podcast network quickly grew to host a few shows related to design and development, and my own show Design Details started to build an audience. Through podcasting and building the network, a small community of people in tech and design began to form. We went through the usual cycle: spin up a Slack team, get overwhelmed by the Slack team, look for alternatives, realize no good ones exist, and give up, frustrated.

We wanted a better home for our community, but nothing out there could do the job. We liked the real-time element of Slack, and having "presence" made it feel more alive. But threading in Slack is not great – information retention is nearly non-existent, and on the free plan messages get deleted on a rolling 10,000 message limit. Commonly-asked questions, fun banter, and good writing was constantly getting lost.

So we decided to build an alternative. That was when Spectrum started, and we really wanted to solve the problems that large-scale public communities face. Max Stoiber joined us at this point, too. He was building massive open source communities for his tools like styled-components, and felt the same need as us to build better community tools.

We made every mistake in the book at Spectrum. But we put in the work and did our best to ship, ship, ship. We talked to customers all the time, tried a dozen pricing strategies, a dozen business models, new onboarding flows, and constantly built new features.

Reflecting back, I think one of the most important things we did early on was ship often and tell people. It's not enough to just build a feature. You have to bring your users along. So we tweeted, wrote release notes, and talked about the changes on podcasts. This kind of momentum is contagious - not only for the three of us building the tool, but also for our users who get excited when their experience is getting visibly better each day.

One of the biggest mistakes we made was building too wide, too quickly. We went a bit feature-wild and tried to solve too many problems at once without enough deep attention to any given element. This led to a lot of half-baked UI, and a buggy core product. We should have said "no" way more, and focused our effort as much as possible on the chat experience. Easier said than done, in hindsight, but it's a good lesson I can take forward.

After about 18 months at Spectrum, we began talking with GitHub. They are intensely focused on building great tools for developers, and community tools are an area where there's a ton of room for them to grow. We decided to join the team in November, 2018, to work on this.

What projects are you currently working on at GitHub?

Today I'm working on the GitHub mobile apps for iOS and Android. I started working on the team last April. Back then, GitHub was in the middle of acquiring a wonderful open source GitHub app called GitHawk, and the acquisition didn't include any design assignment. After bugging my manager endlessly about who would get to design a mobile app, I got fed up and put together some mocks and a deck and pitched my ideas. Somehow that worked, and I was able to start working on the team.

It's been a little over a year since then, and the team is growing really fast. Until a couple weeks ago, we were just 6 people. We recently tripled in size, and we now are breezing through 20 people who will be contributing to the apps.

My main focus now is on iterating. We shipped a fairly focused first version, but the GitHub website has 10+ years of history that we can bring into the mobile context. So right now we're working through flows like code review, and merging pull requests, to make them feel great on a phone.

This part in particular has been a really fun challenge to work on with the team. GitHub is big, and there are hundreds upon hundreds of features that have been built over the years. Our job is to figure out which of those features make the most sense on mobile. When we find features that do make sense for a phone, we have the chance to revisit them in a new light and make slightly different design decisions. For example, GitHub's core navigation is very complex. We worked hard to distill it into three tabs: Home, Notifications, and Search. Within those tabs, we worked even harder to try and bring the most useful functionality as close to the surface as possible.

Ultimately we’re trying to decouple the software development process from the laptop. Unblocking your team with a quick comment while you're on the go, or merging a pull request while waiting in line, are like superpowers for developers who previously had to always be near their computers. This makes it possible for teams to ship faster, iterate and learn more frequently, and we hope it will ultimately result in more (and better) software being created in the world.

In the next few months we'll putting in the work to make our existing experiences better. We need to make it easier to triage hundreds of notifications to make the lives of open source maintainers easier. We also need to support all the security and privacy needs of our enterprise customers. But we're also going to branch out and try new things on mobile (and on tablets) like helping people to discover and learn how to code on the go. What if when you were bored in line at your coffee shop, you opted to dip into the GitHub app for a minute to learn something new, or find the next cool library to play with, rather than just mindlessly scrolling a social feed?

What is it like to be a part of the GitHub design team?

This team is fantastic. Everyone brings something unique to the group, and I constantly feel like an imposter when I see how deep the design work goes across every product. I feel very lucky to work with everyone here.

We're also a remote team, which means we rely on written asynchronous communication for almost everything. We talk in issues, pull requests, gists, and Slack most of the time. One thing I really appreciate about the culture is that there's not a rush to reply right away on every issue. Things can simmer for a while, which usually results in deeper more thoughtful replies.

One of my favorite parts of the team is that everyone seems to have some unique side project, or outside hobby that they share back with the rest of us. Knitting, blogging, making music, streaming video games, designing icons, making hot sauce, and on and on - it's a very intellectually diverse group of people, and it's sorely tempting to try and follow every conversation to try and absorb it all.

What should young designers know when they want to work at GitHub?

There are a few mantras that get passed around at GitHub that I like a lot:

• Strong opinions, weakly held. Can you have a point of view or opinion and back it up? Can you change your mind when presented with new evidence? Is learning more important for you than being right?
• Incrementally correct. If it's better today than it was yesterday, it should ship. Constantly re-evaluate, constantly refactor, constantly talk to customers and gain new perspectives. The job is never done.
• Ship to learn. You don't need to have all the answers, but you have to be curious enough to find them. Shipping is the best way to learn.

How do you educate yourself?

As much as we like to joke that Twitter is an internet dumpster fire, there's a lot of gold in there. I try to follow smart people, read what they write, jump into conversations when I can, and build relationships with people who I can learn from. I'm always looking out for well-written stories and information-dense podcasts.

But also: I think it's important to think of ongoing education in waves. There's a time to learn and a time to earn, as they say. It's not enough to just read and consume, I have to get out there and build stuff. So I've found that I'll frequently go through multi-month periods of heads-down work, followed by a few months of reflection, writing, side-projects, and recovery.

Side projects are also my main outlet to do things besides design. I like learning about frontend tools, like GraphQL and React, and it's fun to try and make my personal website really, really fast. It's just small stuff, but it keeps me interested.

You’re busy as a bee. I just found out you're also a co-host of Design Details Podcast. How do you find time for all of those projects?

I like switching between projects a lot. For Design Details, it's become part of a routine that takes a few hours each week, but is a really rewarding part of my life.

If I find myself procrastinating on a project too long, it's better to just drop the project and move onto something more inherently motivating. Most importantly, I try to work on things that are fun. A lot of people get stuck building things they are no longer interested in, and that leads to burnout and procrastination. I know this because I've done it too many times to count.

What would be your advice to someone who wants to launch their podcast?

Set expectations with yourself first. Do you want to make money? Want to be a celebrity? Just have fun? These motivations change your strategy. Making money in podcasts is hard. Growing podcast listenership is harder.

When we first started Design Details, I'd heard somewhere that most podcasts never make it past eight episodes. So I set a goal for us to record eight episodes before we even released the first one. This way we'd have a backlog and would have a long buffer period before we needed to record again. We made it to 5 pre-recorded episodes before releasing, but the effect was the same.

So I'd say this: you should try it if it sounds fun. If you're doing it to get rich or famous, prepare to put in the work. Spend $500 or so on getting great audio equipment – it's not hard to have better audio quality than 99% of podcasts. That should be your bar. Bryn wrote a guide for this.

What makes your podcast stand out?

We've always tried to keep the show casual – conversational, free form, and not heavily produced. This helped us stand out against a lot of design podcasts out there. I think we hit the right tone early on: mixing personal storytelling with tactical design advice. There seems to be something in each episode that different kinds of listeners appreciate.

Also: right time, right place. This was 2014, and we hadn’t hit Peak Podcast, so I think we were early enough that we were able to ride some of the wave of growing interest in podcasts.

How did you get your first audience?

Before the podcast I ran a small blog called Design Details where I took videos of neat UI interactions and wrote notes about how they worked, or what I liked about them. Those early posts got a lot of views, and I added a newsletter signup form to each post. That helped seed an initial mailing list of about 1,000 emails. After that we tweeted, got great early guests, submitted content to places like ProductHunt, and worked on SEO. The most important piece was creating something that provided value as early as possible. People found the blog posts useful, and wanted more.

How do you manage your time to deliver new episodes regularly?

These days we have the production down like clockwork. We record at about the same time on the weekend. We operate off a templated episode outline to guide our conversation. Marshall and I split the work in such a way that editing is done just in time for show notes, and show notes are done just in time for bed the night before each show. We've slowly started layering in new components to each episode release, like posting on Instagram and YouTube, but those steps only take a few minutes and I have calendar reminders every Monday, Tuesday, and Wednesday to keep on schedule.

There’s no way I would have made it this far as a solo podcaster. I think having a co-host who is equally excited and interested in design has been a necessary part of Design Details. We push each other on weeks where one person isn’t feeling energized, and two people means we can riff more often, bring new ideas for episodes, and bring in different networks of potential guests.

How do you get your guests?

When Bryn and I first started the podcast we made a spreadsheet of 100-ish designers we wanted to talk to. Working our way down the list, we cold-emailed, tweeted, and found warm intros for everyone we could. Ultimately, we found that people in the design community are overwhelmingly generous and eager to share what they know.

I'd also admit that we were lucky to have some higher profile designers agree to come on the show in the early days. Those early guests gave the show credibility, and made for an easier cold email pitch to future guests.

What was your biggest failure, and what have you learned from it?

Here’s a more personal story that changed my life:

When I was sixteen, I was doing some freelance design work for people in my hometown. It was the usual projects: a hundred bucks for a brochure design, a couple hundred bucks for a WordPress theme. Small potatoes, but I was having fun.

One morning in December, I met with a new client who had a $5,000 budget for a new website. To high school me, $5k was functionally equivalent to a billion dollars. After that meeting I went to school and ended up closing out the semester with good grades. It was an intensely rewarding and exciting day, so I felt on top of the world.

In my excitement, I forgot to look left when pulling out into a major highway. I heard honking and looked left to see a car hurtling towards me. I had a split second to slam on the gas, and managed to pull far enough ahead so that the car hit the passenger door behind me. That was my first car wreck, and thankfully I was okay.

But that day put a lot of things into perspective, and changed the way I’ve lived ever since. I’m a much more cautious driver these days, as a start. But I’ve also built up a deep discomfort when things are going too well. It’s like that nagging feeling that you’ve left the stove on when you leave home: what have I forgotten? What is about to go wrong?

Where is the best place for people to connect with you online?

Twitter!

What would be the one thing you've learned over your long career that stuck with you up to this point?

There aren't shortcuts. You have to put in the work, every day, for years, to be good. I always wanted to skip ahead and land "somewhere in the future" where I'd have it all figured out. But it's the daily movement that shapes us, and it's worth the effort.

Bonus Question: What's your favorite avocado recipe?

Basically this: https://tasty.co/recipe/baked-avocado-eggs, except I was first introduced to this recipe by Bryn Jackson who is the master chef. So good!