A few weeks ago I worked my last day at Disqus, the number one commenting system on the internet. My time with the company was the most exciting and educational two years of my career. I never thought it was possible to learn so much about something so seemingly simple as comments. Disqus is now used on millions of websites and is served to billions (with a "b") of unique users every month. Here are some of the lessons I learned while helping design the "web's community of communities."
1. You will never fully understand or appreciate how to build a social network until you try building one yourself.
I have a new found respect for Twitter, Facebook, and the other big social networks. Never again will I be so quick criticize a product for "changing things up" on the users. It's not an easy thing to grow a product like Disqus. I'm thankful that I had a network such a big network to use as my design playground. (And even Twitter and Facebook don't give you as big of a network to experiment on without jumping through hoops.)
2. Every designer should try designing and building modular components that create bigger products.
This is something that can usually only be fully learned while working on a big social product like Twitter, Facebook, Linkedin etc... and I learned it at Disqus, with at a team of less than 80 people and a network of millions of sites and billions of unique users. I don't think most people could say the same about the companies they've worked for.
3. It’s near impossible to have a product that is completely consistent at any one time.
Unless your team is extremely abundant in resources, it will be hard to keep everything consistent at all times. Unless inconsistency is breaking the usability of the product, strive for perfection within components but accept that you may never fully achieve a universal utopia. Continually evolve your design language and as you re-visit old components, update them to the new language. (A rare exception may be when the product is undergoing a major redesign.)
4. The more a designer is engineering, the less they are designing.
It’s useful for designers to understand how to build, but that doesn’t mean you have to be building all of the time. Designers should have a strong technical understanding, but they also need to be thought leaders within their teams. (Pushing polish code should be expected though!)
5. Designers must stay 2 steps ahead.
Similar to #4, designers are the source of the waterfall from which the team is replenished. They need to explore the paths before the team decides which to take. Over time, a designer will realize there is almost always another path to explore. That's what makes design so challenging.
6. "Unicorns" who aren't "T" shaped don't scale.
Often designers who can code are considered "unicorns" because of their rarity. It's great to start a company with designers possessing a wide skill-set. However, as companies mature, designers must also learn to specialize in one thing they can do really well. In the end, I've changed my personal definition of what I consider a "unicorn" to someone who is rare, whether it be an illustrators or systems designer, a "unicorn" is just someone who is rare and exceptional, not necessarily multi purposeful.
7. Don’t worry about hiring people who are better than you at everything. Find the “one thing” they can bring to the table and do better than you.
Again, in an early-stage company you might need people who can do everything. Hire specialists when you're beyond that point. I want to work with a team of trained snipers and assassins, not polymath handymen. I'm proud of where the Disqus design team is today. Each person brings something unique to the table. Keep looking for that "one thing" in future candidates.
8. Your intuition will eventually fail. Realize you can't always be right.
There's a lot of cocky designers in the industry. I was one (and can still occasionally have my moments). When you have a playground as big as Disqus, you can test out your intuition. Designers won't always be right, and should have methods to test their ideas.
9. Engineers should teach engineers Git, designers should teach designers Git.
If you're left-brained, learn from someone who thinks like you. The same can be said for us lowly right-brainers. Some people learn best verbally, others learn best visually.
10. Make friends outside of your role. Learn from each other.
Designers are generally right brained and engineers are usually left brained. When you pair the two, you get something special, you harmonize. And you might also end up with a really great friend, like I did.
11. Start with user stories and goals.
When I first joined, I was shooting from the hip. I'd take a guess at what the problem might be and I'd fix it for myself, not the user. It's important to find the core problem and then approach it from the perspective of your user.
Get to the why before the how.
12. The details matter, and if you ignore them, they will build up.
Like many products, we went a long time without fixing the "little" things. Over time, the outcries of frustration from thousands of users started to pour in. This happens with most big products. I think it's best to fix the little things whenever possible, and we've learned that the hard way. Props to the team for taking initiative to polish Disqus, even when it was a chore.
13. Work with support more.
Find the little sparks and extinguish them before they start a fire. Do this by listening to support more. Build an analytics dashboard, which normal people can understand… At the primary metric, include support tickets!
14. Enjoy the free lunches, fully-stocked fridges, and the parties. You never know what you have until it’s gone.
While other industries are suffering and collapsing, we are thriving. We are spoiled. Take a deep breath, soak it in, and appreciate it. That Github ticket you've been avoiding doesn't seem so bad now, does it?