Specialists and Generalists

A while ago, I joined a Branch about the good and bad sides of specialism and generalism in design. It was interesting to read through the views of other designers and developers and, as Branch tends to do, allowed me to see that this topic was one which I would have to return to in the future. Today is the future.

Back then, I decided upon quite an open and balanced answer, concluding that:

The only questions is, "Do you have the skills to code and design your product, and do you have the time to do both?"

I can see now that this was me setting out what I wanted to do in the future. I wanted to be able to not just envision a product, design it and brand it, but also build it and get it out to users. We've all seen the work of Drew Wilson, Visual Idiot, and other "Do It Yourself, Do It All" (DIA) Designers, and its clear through their work that being responsible for every part of a product's development, from start to finish, can produce incredible results.

This said, we can also look at small-scale startups. Joel and Leo's team at Buffer are doing some awesome things, too: their new designer, Brian, pushed out considerable improvements in the first few weeks he was there. They understand what makes a team work. They can see that, as they grow, they will need to have specialists, such as Brian.

If Buffer is an example of effective specialism in design and DIAs are examples of effective generalism, what's Twitter? They have forty-eight staff on their design team. Is Twitter's design as good as smaller companies? I personally don't think so. They have a great team - definitely. Their team have, separately, done some amazing things in the past. But in this ultra-specialist structure, the individual worth of each team member seems to be drowned out by the others. The fact of being a massive company, rather than a comfortably large one or a single person with no blindingly overweighted financial incentive, seems to throw the results of their design as a whole off course.

So, if the results of being a specialist or generalist are relatively comparable, now that we've thrown the ultra-specialists out the window, what is it that differentiates them? It seems that the important factor, and the one which was secretly at the heart of the prior example is scale. For a small product, only a small team can be afforded, so logically each member of the team has to be able to contribute to a wider variety of areas of the product. For larger products, a larger team can be supported and each team member can focus on one specific area of the product. I stand by my previous conclusion to an extent: if you have a small product and you are able to make it yourself, do that; don't involve anyone else because it either costs you money, trust or their time if your product isn't good enough. If you have a proven product - if you know it can support a team and be its own business - then you can consider expanding.

It all falls down to one single piece of advice (as many of my favourites are, from Buffer's Joel): do what you can alone. Build what you can, even if it's nothing more than the front-end. Prove user interest. Then, and only then, continue to make those users the product they want to see you make.v

As for me and my humble work just now, freelancing is quite unique in that it doesn't require you to choose an area you want to specialise in. I've been playing with front-end development for some time now, but it's not something I enjoy. "I like designing, not building," I tell myself. But I think what I actually don't like is not being able to see what I begin building through to the end. I want to be able to say that I've done more than just create static sites, because while that's all good, it's not a product. It's not the very thing that I have been talking about for the last eight paragraphs. It's not what inspires me. I can't do what I want to do. Not yet.

Reading time: 04:02 Written by Graham Macphee