How can companies build great design teams and what do those teams look like? I talk with DigitalOcean’s Joel Califa about the challenges of teaching web design, living with our own design work and how Joel is building a design team at DigitalOcean. Please note that this interview originally took place in March.
Tell us a bit about yourself. Who is Joel Califa?
I am an Israeli Product Designer. I’ve been designing for over a decade now, though most of the stuff I’ve made during that period is total crap. I can still look at some of it now, but in a few years I won’t be able to look at that stuff either.
Even with my personal blog and Signal Tower, I launched the design a year ago and I already want to redo it. There just aren’t enough hours in the day.
When I first put it out I was happy with it. Since then my memory of it keeps souring and I think “this is such total shit, I need to redo it.” Every time I give it another look, though, it’s better than I remember and I concede it’s not that bad.
Why do we have that urge to constantly improve our work?
I can’t always put my finger on it, which makes it all the more frustrating. As a designer, you look at it, and intuitively know that it isn’t right—it can be better.
A lot of designers can relate to this, right? It’s that Ira Glass quote—we have the taste to know when something is complete shit, but we don’t have the skill to make it better.
Right, it’s the gap between your awareness and your ability.
Right, but I think designers tend to have that for their own work more than for other people’s work.
We look at other designers and say “Holy shit, this thing you’ve made is incredible.”
Joel Califa is sad unless he’s doing good work—The header to his portfolio.
We have the burden of living with what we create. That’s why our creations are bearable right after we create them. But, over time, we become more exposed to it and become more critical.
I think it’s just that we get bored and start to nitpick.
It’s like a relationship. When it starts, you’re in a honeymoon phase. As you spend more time together you get to that point—you know, we’ve been around each other for a while now… I know what I don’t like about you.
Well, for what it’s worth I do think you have a brilliant portfolio. It’s text-heavy, and you show a bunch of your sketch work.
With that said, I’m curious what type of work you like, and the type of designers you look up to?
Hmm. I think I like designers who think.
Over the years, I’ve become less of a visual person. There are a lot of designers and illustrators who put out gorgeous visual work that blows me away, but I have a difficult time looking up to them, because that is not the type of work I’m trying to do.
I’m not trying to create the most beautiful work anymore. I was doing that about four years ago, but I lost interest along the way.
Don’t get me wrong. I want my work to look nice, but now I care more about creating things that work well. It’s UX vs UI. I don’t love that line or distinction but it’s the best I’ve got.
I look at the brilliant pieces some of these designers create. That’s a level I can never reach. Don’t get me wrong. I respect them tremendously, but I don’t look up to them.
On the other hand you’ve got designers like Cap Watkins, Khoi Vinh, or Frank Chimero who write these succinct, thoughtful articles about design. They write about design processes and about all these other little details.
That’s amazing to me.
It’s difficult for me to name them right now—Sacha Grief has a done a ton of great writing.
And it’s not always about design. Sometimes it’s about running a business—or about applying design thinking to other disciplines. Look at a lot of Sacha’s writing. He writes about how to run a business, but he’s actually taking how we learn and think about design and applying it to business—He’s designing a business.
Similarly, there’s a line between visual design and product design. There is crossover, but it is pretty different to work on a single layout than figure out how all these layouts fit together.
In this industry there are all these different titles, subcategories are thrown around. What do you think about that?
First of all, I don’t believe that I have anywhere near the kind of authority someone needs to draw or tell others where the line is.
Second, I don’t know what that line is. I have no idea.
“Product Designer” as a title is so vague. I’m a Product designer and I work on strategy, write code—I spend half of my day on front-end—I do visual design and user experience work.
We actually stole Product Designer! That’s not even us. We stole that term from Industrial Designers.
I think people choose the stuff they are most interested in, and that changes with time. People that start out focusing on visuals often transition to systems, and vice versa.
My first role in the industry, before school, was as a Visual Designer. We had a UX team and we would work in a waterfall process.
When I started school, I realized that I could get so much better at making things look great. It’s a really valuable skill. The people I know who have made careers out of making really beautiful things are incredibly happy.
Design is about creative problem solving and trying to figure out an elegant way to do something.
But I became more and more interested in the underlying systems. Somewhere along the line I decided that UX was more interesting and satisfying for me.
Taking a step back. Graphic Designers are doing the same thing. They’re applying design thinking to how a layout is presented. Color theory, visual hierarchy—all these things are just tools for communicating.
In my mind, programming is design too. Design is about creative problem solving and trying to figure out an elegant way to do something.
Tagging along with that—how does someone become a good creative problem solver?
Practice.
The more you practice any type of design—coding with design patterns, making a poster, or building information architecture—you’re being creative. Yeah, you’re teaching yourself how to solve a specific problem, but you’re also making yourself better at creative problem solving in general.
You co-founded Design and Code, which evolved into Design and Hack. Tell us about those organizations and their relationship.
Design and Code was something I started with a bunch of friends at Parsons. I went to Parsons for program called Design & Technology.
We were expecting a program that was half design and half technology. As it turned out, it leaned much farther to the design side. The program was missing a whole lot of programming.
In hindsight this was great, but coding was something that we really wanted to learn. We just didn’t have the resources at school. So we started this organization called the Parsons Code Club. It started out as a pretty humble idea—meet every Friday, have pizzas, and teach people how to code. We’d teach people HTML, CSS and JavaScript. We’d show them how to make Twitter bots with PHP and how to create generative art with Processing.
At first it was just friends. It started out with about 30 people and slowly dwindled to 10 or 15 people each week. Sometimes there were less. We were all just learning how to do this. Every week it would either be me or one of the other founders teaching a different workshop. One week I’d make a color search engine, another week it would be something else.
The second or third semester that we ran the club, it finally started gaining traction, and went up to 40, 50 and 60 people each week. We were filling rooms and then some.
At some point, we realized that this could be a great place for designers and developers to come together. We had all these really great designers that wanted to code and make stuff, but probably weren’t good enough to actually build their own iPhone apps.
On the other hand I was talking to a bunch of organizations at Columbia and NYU that were focused mainly on tech, with people from their CS programs. They said that they were looking for designers. They were making cool things that were functional, but the UX wasn’t there, and the visual design definitely wasn’t there.
Design and Hack was an idea for a hackathon with the goal of bringing these two groups together and having them collaborate. It took a long time to get off the ground. I think it must have been third or so attempt that actually worked.
It was hard. Events are hard.
A design series of polygon animals (polyanimals?). The entire series is available on Dribbble.
Well, you’re currently teaching beginners front-end development at General Assembly. You transitioned from teaching people at your workshop in college. How has that been going?
I’m getting paid now, so that’s a plus.
[Laughter]
I discovered a real passion for teaching while I was at Parsons. I really enjoy it, and think I’m pretty good at it.
One of my co-workers was working as a backend instructor at General Assembly and suggested that I give it a shot. So I reached out, and within about a month I was teaching.
I’ve been building a curriculum and making my own slides, which was definitely a mistake. I’m a crazy perfectionist and I want my slides to tell a story. So for each class I have somewhere between 100 and 300 slides.
I should steal your slides and start teaching at General Assembly here.
I’m going on class 16 now, so I’m afraid to do the math. It’s a ton of slides.
If you ever need slides, you know who to ask. I’ve got a guy for slides. It’s me.
So this front-end class is catered towards beginners. Where do you begin?
General Assembly has an intensive web development course, where students come in everyday. The goal of that course is that after three or four months you’re close to a junior level developer and can find a position in the industry.
My course is more of a part-time, introductory course. The idea is you come in and get a better understanding around front-end development. By the end you should be able to build a basic website, but you’ll have to learn more and work more if you want to become a web developer professionally.
There are a lot of little things you and I understand and take for granted, but are surprisingly hard to teach.
There are a few types of people that take my class. Some are designers who want to transform their designs into websites. Others are people that run businesses and want to understand what’s being done on their websites, and learn enough to do some of that themselves. Many are people that are unhappy with their current careers and are trying to see if web development is for them.
Everyone’s at a different level. Everyone comes from different fields. There are a lot of gotchas. Some people don’t know what a file system is, much less how they work.
There are a lot of little things you and I understand and take for granted, but are surprisingly hard to teach.
People don’t understand that websites are just documents hosted on a server somewhere?
Even less than that.
Some people don’t understand how the file system works on their Mac or PC. You know, I’ve been a nerd all my life. Directories are in my blood. I see everything as a directory. For many people, there’s never been a reason to learn how certain things work, and that makes total sense.
Lots of the stuff that I teach is like that, which is fine because I actually enjoy it. I like finding things others don’t understand. I like working to try and get that lightbulb to go off.
Right now we’re seven weeks in. They know HTML, CSS, and some basic JavaScript. They just created a temperature converter.
They can’t sit on a computer and build these things the way you and I can—we’ve been doing this for 10 years—but they can hack together something that actually works, something they wouldn’t have been able to do 10 weeks ago.
You talked about not quite understanding file systems, but what are some of the common speed bumps you see front-end beginners come across?
There are a lot of places where their mental models aren’t quite right.
For example, I was teaching an intro to jQuery. I provided a demo for them to work on—it was a file with a bunch of commented lines telling them what to try. One of the lines said to change the color of all the paragraphs to red.
All of a sudden they see that jQuery has changed the colors of all the paragraphs, so one of the students goes “Hey, so does this mean we don’t need CSS anymore?”
That was amazing to me, because we take the roles of things for granted. It never occurred to me that someone else wouldn’t. I don’t have a ton of examples off the top of my head, but things like that always come up, and they teach you to stop making assumptions.
It’s like someone using your designs in a way you never thought they would. It’s an interesting feeling.
For me the two plateaus are targeting elements and then positioning. Once you’re beyond those two styling becomes much easier.
Let’s talk a bit about DigitalOcean. I’m a huge fan and happy customer. I’m curious when you got there what was the state of their designs.
DigitalOcean is an incredibly fast growing startup. When I joined 9 months ago we were the sixth largest cloud host. Now we’re number two.
Before I joined, our codebase was just built very quickly and our design was largely put together by our chief marketing officer. The UI wasn’t great, though it was still good in relation to the cloud-hosting space.
DigitalOcean’s loading animation is a detail that makes company stand out.
That was one of my other questions. Cloud hosting companies have a pretty serious engineering focus. Why invest in design? It seems like the number one concern would be making the servers faster and more reliable.
I think DigitalOcean as a company understands the importance of providing a good experience to our customers. This doesn’t just translate into the Design team’s work, but also an amazing support staff, reliable servers, sensible pricing, etc. Design is definitely one of our big differentiators in the market, though.
When I joined, none of us were proud of the design. It wasn’t the type of thing we’d want to show other designers. Definitely not something we wouldn’t post on dribbble. But things were already on their way up. Another designer here was midway through normalization.
What is normalization? Is that going through and updating the application based on a style guide?
Not exactly. It was a piece by piece thing to make our app more consistent and aesthetically pleasing. It’s funny that you say that, though, because right now we’re in the middle of integrating our new style guide.
Since I joined, design has been getting better and better here. We’ve always had great illustrators and designers, but we’ve since hired a few more talented people and have more bandwidth to create intuitive systems and beautiful, delightful interfaces. We’ve been slowly growing the team and have been very carful about who we hire.
Designers at DO have a lot of autonomy to make product decisions. For instance, I just redid our navigation. Our old side navigation wasn’t really working and would have blocked us from building out some of the stuff we have planned, such as sub-navigation for individual sections. I transitioned our app to a top navigation and change up some of the information architecture. We moved a few sections around and it’s way more intuitive now.
Our design process has been very iterative. It wasn’t in a great place when we started, but as we start implementing our new style guide we’ll have to rip out all of the previous styles. It’ll take a month or two (or three), but we’ll have a product that we, as a design team, can be super proud of.
I think the people that use DigitalOcean will really feel the love. We’ll have really clear focus states, better forms, and a more transparent billing page.
Going back to some of the things you said earlier. How many designers are on the team?
I’d say there are about seven or eight of us.
And how many engineers does DigitalOcean have?
We have about 30.
That ratio is interesting for a cloud hosting company. Also it seems like your design team has a lot of illustrators.
We do.
I’d say that since its inception, DigitalOcean has gone the extra mile.
Absolutely. There’s a ton of helpful articles every time I break something on my server.
Yes. That’s actually how I found out about the company.
I had some credit with DigitalOcean and decided I was going to be a sysadmin for a week.
As a designer, I wasn’t exactly trained on setting up Unix servers. I’ve never done this stuff. The only time I’m in my terminal is to move through folders or use git. All of a sudden I had to use it in order to install Nginx and set up server blocks.
Don’t get me wrong, this sysadmin stuff is really interesting, but it took me three attempts to get it right.
While I was doing this, the DigitalOcean Community was there and helped me navigate through a lot of this stuff. There’s so much knowledge there—stuff about Ubuntu and other Linux distributions, Nginx, Apache, setting up email servers, etc.
I don’t want to say unicorn, because I hate that term.
If you search for any of these things you’re more than likely to find a DigitalOcean Community article as the first search result. It’s not due to some magic SEO, either. It’s because the content is really good and others are linking to it.
We actually have a very large team of technical writers and community managers—much larger than our design team.
Where were we? You were asking about Illustrators.
We have so many illustrators, because almost all of the community articles have these gorgeous illustrations. Developers love them. They aren’t the type of thing you’d expect from a company that does cloud infrastructure.
As you guys are building out the design team, what do you specifically look for in designers?
We are searching for an extremely rare type of designer. I don’t want to say unicorn, because I hate that term. But we aren’t just looking for a designer who codes. We’re looking for someone who cares about and can execute systems, user flows, and aesthetics. They need to solve high-level problems and be flexible, but also stress the details.
We’re still a startup, in some ways, so we’re not looking for someone that is a seasoned UX designer who submits low fidelity prototypes and site maps. We need someone autonomous, who can really own their work. The designers we’ve hired in the past can write really graceful JavaScript, for instance. Not that this is a must, but it gives you an idea for who we’re looking for.
It makes hiring incredibly difficult for us. When you get to that level of pickiness, there are only a handful of people who can live up to those standards. We’re still figuring it out.
I know you guys are in a hotbed for talent. Do you guys have designers that work remotely, or is that an option?
We do have people that work remotely. Our support team is almost entirely remote. A ton of our software engineers are remote.
The Design team isn’t as much. Kasia, one of our illustrators lives in Poland. Alex is in Utah. They’re both planning on joining us in New York at some point. It’s harder for us to collaborate when we’re not in the same space. When they visit, you can really feel the difference.
What tools do you guys use to keep in touch?
Everyone is on Slack. It’s the best.
We’re almost out of time. Do you have any nuggets of wisdom for all the product designers out there?
Just keep at it.
I’m trying to come up with something really deep to say right now, but I don’t have anything.
[Laughter]
If you’re interested in something, just start doing it.
I started writing lately, and I think that’s helped me tremendously.
As you write, your initial idea evolves, because you re-read it and realize that it’s not really that convincing.
Actually Joel, I’ve got another question for you then. How has writing helped you become a better designer?
As I said before, solving any problem creatively makes you more creative. Writing is inherently creative. It’s not just the content. It’s how can I frame this? How do I tell this story? Do I have the right tone? Am I organizing things the right way?
It also makes you articulate your thoughts. As you write and rewrite, your initial ideas evolve, because you re-read the article and realize that it’s not really that convincing. If it doesn’t convince you, how could it possibly convince others? So you don’t just rewrite it—you rethink it.
I recently wrote an article about visited link styles. My opinions when I started writing this, compared to when I published the article, were so raw. Writing it forced me to distill them and really understand them.
Writing also pushes you to learn a lot more about your content. When you publish, you’re really putting yourself out there, and you don’t want to be wrong.
Writing forces you to backup the position you’ve established in your mind, right? It forces you to find logical reasons for that position.
Exactly.
It’s a lot like teaching. When I need to teach a class, and I have to explain things like how positioning works or why these weird things happen in JavaScript. I want to be a hundred percent sure that I know what I’m talking about, and I also need to come at it from a different angle, so I can better explain it to beginners. Teaching has made me so much better at what I do.
Writing’s done the same.
Joel, appreciate you joining me today. Where can people find you?
You can find me on Twitter @notdetails, which comes from the overused Eames quote, “the details are not the details, they make the design.” I love it when new people get in touch, so please don’t hesitate to hit me up.
This interview was originally published on Signal Tower.
Comment