The One Who Started Dribbble with 50 T-shirts

Dan Cederholm is the cofounder of Dribbble, an online community that allows people to showcase their graphic design, web design, illustrations, and pictures. At the December 2018 edition of dotCSS, Behind the Code talked with him about how he started coding, the challenges he faced at Dribbble as a founder and as a front-end developer, and how writing has been the key to his success and much more.

From music to web design

My dream job as a kid was to be a rock star. I played music from an early age—I think I was around 8 years old when I started playing the drums. That was really the focus up until I was 23 or thereabouts. It wasn’t until the web came along that I realized there was another way to be creative. I had got a really terrible job at a record label in Cambridge, Massachusetts, called Rounder Records. I worked my way up to a desk job that involved working on a Windows 3.1 machine that was hooked up to the Internet, and I was just blown away. Within a few months it had kind of completely shifted my thinking, like, “OK, here is something I can make a living doing but also learn so much from.”

Learning by viewing

So, learning web design back in the 1990s meant viewing the HTML source code, and that’s the beautiful thing about web design. The blueprints for everything that’s out there are available for all to see and dissect. And I just loved that. If I saw something I thought was cool, I would view the source code and figure out how I could recreate that.

The mentors

The place I then began working at was kind of an early dial-up Internet company, and there was a guy there named Paul Yasi, who was the only one who had a Mac in this room of customer-support people using PCs. I really gravitated toward him and I specifically remember him using the command line to FTP something. And I was watching him do it. And I didn’t know anything about the command line at the time. He was typing and he said “Bye” and the Internet left. And I was like, “He’s talking to the computer, that’s incredible.” That blew me away. And I learned a lot from him, not necessarily in terms of how websites are built, but how the Internet works and how the web works. I was fortunate to be taken under his wing.

And then fast-forward several years after that, and I had got swept up in the web standards movement. There were tons of mentors involved in that, such as Jeffrey Zeldman. I am incredibly grateful to him for his caring and all his sharing—and Doug Bowman, Dave Shea, Molly E. Holzschlag, and all those folks from the early days of web standards.

Dribbble as a side project

So Rich Thornett and I were really good friends, living in the same town, in Salem. We were neighbors—I could see his back door from my door. We ended up working together, sharing an office a few days a week. And it just so happened that Rich was a programmer and product designer as well. This was right around the time when I had this idea for Dribbble, spelling it with 3 bs because the domain name was available. Selfishly, I wanted to be able to look over the shoulder of people who I admired and see what they were working on. So Rich and I talked a bit and literally he was like, “OK, let’s start a [Ruby on] Rails project and make it as a side project.” And that’s what we did. We just started it as a side project, just the two of us, part-time. That’s how it began, really.

Using T-shirts to start the community

One of the things that really helped us initially was contacting 50 to 100 friends and colleagues who were great designers. So we ending up sending them each a T-shirt with some handwritten code on that would take you into the site—“Hey, hello friend, please try out our site Dribbble. Here is the URL.” And the T-shirt was great because it kind of guilted them into actually checking the site out—sending out an email saying, “Hey, we’ve got this new product we’re working on” would never have worked as well. So what was great about about it was this group of 50 or so really good designers set the tone of what was being shared and uploaded. And they immediately shared really interesting, visually compelling stuff. That was the foundation for the next wave.

The challenges as a front-end developer

One of the challenges was that this site was for designers, many of whom were front-end people themselves. So you have to grow a thick skin when you’re designing or building something for designers as a designer. We intentionally made the interface generic so that it would sit back and let the work be showcased rather than the UI of Dribbble itself. It was always a challenge to hold yourself back and really focus on the artist and not what I wanted to do interface-wise.

Another challenge was the fact that it was just me doing front-end for so long. I had been a freelance front-end person for years before that. And the nice thing about that is you can kind of reinvent your skill set every project. Whereas if you’re working on one product for years, it becomes difficult to throw out everything and start again. And then you’ve got other team members coming on board who are hungry to use better technology and organize it differently. So now you’ve got this large code base that could work better—and it can always work better. And I think that was something I needed to keep in mind. You’re gonna have to embrace the imperfection of your code if you’ve got to live with it for a long period of time, otherwise you drive yourself crazy.

Growing by watching the community

So we did a lot of just watching the community and reacting to how they were using the product. A lot of the features came from recommendations from the community itself. Its members started using it in a certain way and we sort of adapted the UI to that—“paving the cowpath,” as it’s known. It involved a lot of observation of how they were using it and then reacting to that and building in the features, such as rebounding. That was an early feature we created. It was a way of responding to a shot design with another shot of your own. People were doing it in the comments and we sort of took that and made it into a feature.

Remote as a way of living

Initially, Rich and I rented a much larger office in Salem than we needed, thinking that we wanted to hire locally. It turns out that there aren’t many product-designer folks in Salem. There are now, but there weren’t at the time. And I think the first couple of hires were remote and that kind of just snowballed. We realized that Rich and I would sometimes be in the same room but we’d be working in Slack anyway because it’s just more efficient to communicate that way for a lot of stuff. So using remote hires set the tone and then we realized how that gives you access to a whole pool of talent. I don’t think I could go back to a non-remote job now, because working remotely is much better for life balance and I don’t think I’m employable in an office environment anymore.

People and relationships above all

The biggest joy I get is finding new talent on Dribbble every day. I’ll go on there and find somebody who has a couple of followers and is creating incredible work. That motivates me. I know that’s going to happen every morning. There are new people up there who are sharing their stuff for the first time or just something I hadn’t come across until then. Being able to shine the spotlight on that and help them either get hired, get more visibility, get a job, or whatever, is wonderful, and the relationships I’ve formed through the web-design world feel like an achievement. I feel like, when it comes down to it, being able to find good people who share the same view of the world as you is one of the most important things for us to have.

Writing!

I feel that the success I’ve had up to this point has been because I wasn’t afraid to share as I was learning. That switch of, “Hey I don’t need to be an expert to be talking about how I work and sharing that with the world.” And I feel that approach is really valuable for anybody to adopt—to not wait until you have a complete grasp of the subject before you actually share your thoughts on it and how you are using it in your current work. Whether that’s via a blog or Twitter, it doesn’t matter. Because that’s gonna be crucial. Writing skills are crucial anyway—communication with the team, copy on the websites… All of that forms the foundations of interfaces, too.

More abstraction in the future

In the future, I see more abstraction from what’s going on. I think the design tools that are happening are really interesting right now. I don’t mean let’s go back to FrontPage or anything like that, but there is a level of abstraction that could probably happen. Something like Webflow, for instance, is really interesting to me, because they’re taking that sort of visual approach while still providing base code with solid standards. I feel like it should be easier to do some of the things we do. Some things could be automated. Design systems are growing. I feel like a combination of design systems and tools and the browser technologies is leading to a place where, hopefully, we can spend more time worrying about the experience and the content rather than how to get things to work.

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustration by WTTJ