I recently sat down with one of my favorite InVision users, Dribbble, to talk about their design and development process. If you’re unfamiliar with Dribbble, they’re an invite-only social platform for designers to “show and tell,” get feedback and support on their work, and just hang out in a community of other designers. And I’m thrilled to announce that as of today, you can share directly to Dribbble from inside InVision.
I spoke with co-founders Dan Cederholm and Rich Thornett about the challenges of working with a small team on a product with a huge, opinionated community, as well as how to maintain trust with that community while meeting business goals.
How’s the design team set up at Dribbble?
Dan: We’re a 6-person company, and Rich and I handle design. It’s tough to separate design from the rest of the product team. There’s a lot of collaboration, likely due the fact that we work together in very close quarters and we’re so small.
We don’t have a ton of structure—it’s more of an agile setup. We’ll scope out a feature, for instance, and collaborate on what that means from a visual and a functional standpoint.
Rich: Design, product construction, and development are all a part of what we do.
My role involves managing all the issues, bugs, ideas we want to think through as possibilities, things we want to build, and things we’re actually going to start working on. I determine where everything fits into our product schedule and vision.
What’s your organizational process like?
Rich: We use GitHub for all our collaboration, whether it’s a feature, an idea that’s going to have a visual representation, or even an interview or conversation we’re going to have with someone. It’s a way for us to define our issues and discussions.
Between GitHub and Slack, we’ve created a knowledge base. It’s a big part of our company culture: it’s how we communicate and where we start all of our designs and projects.
For project management, we use Waffle as a layer on top of GitHub—it gives us a columnar view of GitHub issues and we can move individual tasks around to indicate progress and what needs attention.
Tons of review happens with everything we work on, usually in the form of a pull request in GitHub that’s moved into the “Needs Review” column in Waffle. At that point, we’ll hash out a solution for an issue in the pull request. We’ll go back to the drawing board if needed. Or if we’re happy after making a few changes, we’ll deploy and merge.
“For our small, remote team, InVision’s Liveshare feature has been an extremely useful (and fun) way to visually and verbally talk through a design. It’s like we’re all sitting around the same table with markers and feedback at the ready.”
What’s the design culture like?
Dan: We’re not afraid to try stuff out in private and throw something out if it’s no good. That can be a leap for people who just want a task to finish and ship, but we want to look at designs with critical eyes.
“We’re not afraid to try stuff out in private and throw something out if it’s no good.”
Though we’re a small team of designers working toward the same goal, it’s just me doing the actual visual design.
Rich: Here’s how it usually works: Dan shares visuals for a project with me, and I’ll have opinions and complaints about it even though I don’t have the chops to have made it in the first place.
Dan’s great at taking feedback to heart and coming back with something stronger or something that actually addresses the criticism.
I recognize a problem visually, but I can’t create a solution. Someone who might not have the same visual skills can have a valid critique of a design—it shouldn’t be taken personally.
Dan: Not all programmers can visualize how to improve something
. If you’re constantly getting criticism from someone whose opinion you don’t value, it’s going to be a problem.
I always know that the end product will be better for it.
Rich: Dan and I use a safe word for unwelcome feedback. He’ll say, “I like your energy.”
And I’ll stop talking about it.
When we started, there was a lot of back and forth between us as we sat on a sofa and looked at the same screen. After we discussed a feature, Dan designed it, I coded it, and we noted what we liked and didn’t like and what needed to change.
We come at it from different angles, but we have similar sensibilities. Even when we’ve disagreed, almost everything we’ve come up with is something we both like in the end. We’re lucky to see through similar lenses.
What challenges do you face as a small team?
Dan: Juggling everything. We’re not just coding and designing, we’re managing the business and jumping into lots of tasks as needed.
Lately we’ve started to think about delegating things we don’t like to do.
Rich: That handoff is the biggest challenge—deciding what to hold onto so things come out the way you want, and what to let go of so people feel empowered.
We’re figuring out what that boundary is and how we’ll continue to do good work while communicating effectively and outsourcing as much as possible to the team. After all, people are here to contribute and have their own stamp on the work, too.
“That handoff is the biggest challenge—deciding what to hold onto so things come out the way you want, and what to let go of so people feel empowered.”
What’s your design process for new features?
Rich: Everything starts with a conversation. We always document what’s said—goals of the feature and what it should look like—so there’s never a question as to what was talked about. GitHub issues include that info so the person assigned to it knows the complete history.
Often, our process is dev first, UI later—we don’t usually start with mockups. You always have a visual in your head, but often we just work on the flow and some of the copy first. Once a developer has something in place, they’ll request CSS markup or visuals from Dan.
Dan: I prototype some features on my own first, like when the developers are busy and I’m not, but most of the time it’s just as Rich described.
Rich: Bigger features and features that communicate something new to a user get mocked up first, and those visuals are documentation for driving the effort. It all depends on the nature of the feature: if it’s more of a functional thing, it’ll likely start in development. And if it’s something users will see, it might start with Dan making a prototype.
Bandwidth is another factor when deciding whether something gets mocked up first—Dan may just have the time to do it.
What are the benefits to doing dev before design?
Rich: Sometimes it’s easier to see how to visually construct something after you think through the major use cases, edge cases, workflows, pages, and where you need visual treatment and communication with users.
Dan: When we do development first, we’re working out details and edge cases. So the actual feature may slightly change from the time we talked about it to the time we code it.
The way you think about modeling the data can affect the UI, but you could argue that the reverse is true. You’d come to the same problems if you prototyped first in HTML.
How do you prioritize feature requests from the community?
Dan: Sometimes members put their requests right on Dribbble as mockups—and we’ve actually implemented some of them. Though not all requests are great ideas, it’s still fun to see because it means people are excited. They wouldn’t take the time to do that if they didn’t care.
There’s not a formal way for people to make requests. We’ll get some through our support channel, and we’ll escalate valid ones into GitHub issues so they aren’t lost.
What’s a typical day like for your team as whole?
Rich: Dan, Susanna, and I are in Salem, and the rest of the team works remotely: Patrick’s in Minnesota, Ian’s in California, and Allison’s in Austin, Texas.
Slack’s become our place. It’s not just a communication tool for us—it’s our company culture.
A typical morning involves getting feedback from support and getting caught up on any open questions from developers. These days, we’re getting more emails that require a response. At some point in the late morning or early afternoon, we ideally get to work on what we’d hoped to that day—anything from heads-down coding to having a conversation about a feature, hiring, or an upcoming meetup.
What we do each day really depends on whether we’re focused on product work or responding to our community.
Dan: So maybe there’s no typical day.
What do you think is the most powerful part of your design process?
Rich: Very good, quick feedback.
We have great tools—we’re able to do something, talk about it, and then immediately work in feedback. Being small makes that easy.
Everything’s heavily edited—nothing gets through unseen. There’s an overwhelming amount of stuff to keep track of, but we have a chance to look at and comment on just about everything.
Hopefully that’ll keep things aligned with our vision for the product. How it scales is honestly an unknown, but I love that our current setup allows us a constant awareness of what’s going on and the ability to quickly have dialogues.
What are the values that you try to reflect in your design or your product changes?
Dan: Simplicity.
Dribbble’s UI should be as invisible and as non-designed as possible so that the work takes centerstage. That’s the reason for the monochrome black, gray, and white look with the occasional hot pink thrown in to highlight things.
Designing for Dribbble is both fun and challenging because you have to keep in mind the variety of work being shown. It’s got to look good no matter what it is.
Rich: As a coder, I like to solve problems by avoiding them. Keeping things simple is our aesthetic, and there’s also value in avoiding complexity wherever you can—it lets us focus on what we think is important.
Part of our process involves asking 3 questions:
- Does this need to be here?
- Does this work?
- Does this matter?
If the answer is no, it goes away.
How do you make design decisions internally when you know that you have really opinionated people on the other side?
Dan: We’ve grown a thick skin. We’re also conscious of the community since we’re also members of it. When things like features or UI change quickly, I understand how jarring it might feel for members.
We’re careful about what we ship and the effect it’ll have on everything else. There are a lot of things we could have screwed up but didn’t, all because we’re conservative about change.
The community is design-savvy and opinionated, and there’s a lot of skin-thickening that happens. You start to realize there are some people who just want to say negative things, and you learn to ignore them. There’s also people who give great feedback.
What’s it like to design for yourself? And what’s it like to design for designers?
Dan: It’s fun. It feels like a community I’d be a part of regardless of my job here.
The other side of it is that because there’s so much talent on Dribbble, you can feel like you’re not worthy of being there—the bar is so high.
“Dribbble feels like a community I’d be a part of regardless of my job here.”
Our goal is to be simple and make the site easy to use. Hopefully we achieve that most of the time.
What kind of metrics do you watch?
Rich: It’s not that we don’t believe in data, but we don’t watch a lot of metrics in terms of driving design decisions. We’re building what we want from the site.
Some products just want signups, so they’re designed to influence people to behave in an unnatural way. What we’re trying to do matches up with what our users want. That’s the point of the site.
We watch our sales closely. Because we’re not funded, how we’re doing is a function of the money coming in the door. It also determines whether we can hire. Incoming revenue determines what we’re able to do.
Instead of looking at user behavior, we watch the bottom line. We know people like pro accounts because they’re buying them. And we know the job board’s successful because people use it—and we’re tracking those sales.
We’re not optimizing Dribbble around signups—we just want to make it good. So a lot of our stuff is intuition-driven: we add things to increase value.
Dan: Meetups measure engagement, too. We get feedback by talking face-to-face with members. We know it’d be a bad sign if we ever go to a meetup and suddenly no one talks to us about Dribbble—or if nobody shows up.
Rich: We’re still building our product to meet member needs. We’re interested in doing the right thing for the product and getting more revenue so we have better resources to serve the community.
Do you have a formal review process?
Rich: Nothing about our process feels formal to me. Here’s how it goes:
- Document the problem
- Discuss the problem
- Build a potential solution
- Discuss the solution
When Dan and I like it, it goes out the door. We don’t have to bless the smaller things, but if it’s something that’ll affect user experience, we validate it.
What tools do you use to document collaboration?
Dan: GitHub, mostly. I’ll do mockups in HTML and CSS, and I’ll include screenshots of those in the GitHub issue so they can be commented on. Once something graduates to pull request status, the team knows it’s ready to dissect.
Rich: Just about every product-related discussion gets driven to a GitHub issue. If it turns into something we’re going to build, it’s already there and progresses through our normal flow. We also like GitHub’s ability to support markdown.
For quick feedback, we’ll use Slack.
Do you have any tips for people who work with remote teams?
Rich: Write things down so everyone knows what’s in play and what you’re trying to do. We post conversations, spreadsheets, and documents that explain a feature set’s direction. People don’t wonder what we’re thinking—they know because it’s out there.
We do a weekly check-in meeting that sometimes becomes a storytelling session about people’s personal lives, but I think there’s value in that.
“Write things down so remote workers know what’s in play and what you’re trying to do.”
We try to get together a few times a year to build relationships between team members. They’re short trips, but there’s lasting impact—you feel more connected when you get back in the chatroom.
How do you balance the requirements of your business without being a sleazy organization?
Rich: It’s not a temptation for us. We’re a niche site and not a massive advertising play, so we don’t have to invent stupid ways to tax users.
The job board is advertising, but it’s something designers want. The pro accounts provide useful features, and the team accounts help businesses and their designers gain attention for what they’re doing.
“Dribbble’s a niche site and not a massive advertising play, so we don’t have to invent stupid ways to tax users.”
We have banner advertising, but hopefully it’s not too odious.
We feel that what we’re trying to build has value. When you feel that way, you don’t have to negotiate the sleaze proposition.
Dan: We don’t feel at odds with our “customers”—and not all of them are paying—but we’re trying to stay true to our initial ideas.
For any community-driven site, you’ve got to have integrity. Otherwise it’s just going to be a group of customers.
Can you tell me how important you think design’s been to the success of your product?
Dan: Design is everything.
Rich: Part of our success was being in the right place at the right time—design’s been elevated on the food chain since Dribbble became a thing. We tapped into that phenomenon by giving designers a place to show what they’re doing. So as design became more important, so did the place to show it.
“Design is everything.”
Why is Dribbble still invite-only?
Rich: 2 reasons:
- Opening up the site means our small team would spend a lot more time on scaling support, monitoring behavior, and fighting spam. As much as possible, we’d like to focus on the core product.
- It’s why people come to the site. They appreciate that it’s designed to feel a bit intimate.
As we get bigger, holding onto this sense of community will be challenging and require much thought, development, and design. We’re not at the point where we can open the gates, so for now we’ll continue to throttle it through the invitation system.
How has your user base changed since you launched?
Dan: Because of the invitation process, there are more design fans than designers posting work.
Friends and colleagues received the first invitations, and they immediately shared compelling, high-quality work. That got us off on the right foot.
Rich: People use Dribbble to build a name or a brand for themselves. Some have even gotten jobs at places like Dropbox because of what they’ve shown on the site.
People complain that only popular designers are on Dribbble. Sure, many early users were big designers Dan knew from the conference circuit, but not all of them wound up being consistent users. Some designers from the first wave of invitations who started posting all the time actually became popular from using the site.
Who’s popular changes over time, but I love the idea that popularity comes as a result of getting much-deserved attention for good work. That’s exactly what we’re after.
“I love the idea that popularity comes as a result of getting much-deserved attention for good work. That’s exactly what we’re after.”
How do you keep up with constantly changing web standards and opinions on what good design is?
Dan: For the Dribbble website, we’ve taken an adaptive approach: each piece of the site has evolved over time. That’s been helpful for users to adjust to since there aren’t ever any jarring changes.
We try to fold in new things as they come along. For example, when retina screens came out, we started supporting retina images as shots. That didn’t require a redesign, just lots of refactoring.
Responsive design wasn’t a concept when we first launched, but it’s become important to support different screen resolutions. We’ve had to retrofit that as well, but it’s been more of an evolution.
So what’s good design? It’s been fun to watch that change on the site and see what’s popular. What’s there today isn’t what’s going to be there tomorrow.
Rich: A lot of my ideas and inspiration come from going to sites I respect and looking at what they’re doing and how they handle certain problems. It’s a great way to set yourself down a path of thinking.
What’s up next for you guys?
Dan: Growth is always on the horizon. We’d also like to create better tools for people who are hiring, as well as a better way to discover talent on the site.
Rich: We’ve been considering infinite scroll and have some ideas about how to implement it in a way that won’t break what works now.
Tool integration is another thing. People can post directly from InVision and other design tools they’re using. We’d like to make Dribbble a natural part of someone’s design workflow.
Do you have any insight or advice for new designers?
Dan: Get your work out there.
Publish and write. I wrote and blogged all the time, and that led to me writing books. Writing is sharing knowledge. You have to get yourself out there in any way you can.
“If you’re not working with a client, design something you’d want to work on.”
If you’re not working with a client, design something you’d want to work on. If you want to be a letterer, make something that shows off your skills. That could lead to getting the types of jobs you want to get. Be your own client.
The image size constraint on Dribbble is an advantage—you can just post a snippet rather than a giant project with a write-up.
Rich: Designers, your resume is whatever you want it to be. It doesn’t have to be your work history if you’re not happy with that. If you publish things that show what you can and want to do, you’re ahead of the pack.
Dan: And make T-shirts. The first thing you should do is make a T-shirt.
“Dribbble’s UI should be as invisible as possible so that the work takes centerstage.”
“Design is everything.”
“If you publish things that show what you can and want to do, you’re ahead of the pack.”
Photos by Kim Indresano.
by Clair Byrd
Former Director of Content Marketing at InVision.
