Designers will design, developers will develop, and why you must stop them — The Startup — Medium
Designers will design, developers will develop, and why you must stop them
In February 2014, I made a recommendation to my co-founders at Ballistiq that I wanted to cancel development of ArtStation. The project was in development hell. It wasn’t going anywhere. I was unhappy with it and just couldn’t see a path for it to be a successful product. Two months later we managed to launch it, and two years later it is the leading network for professional games, film, media & entertainment artists with over 2 million users per month, leading studios recruiting on the site, an official Star Wars competition running and great opportunities.
What happened? Why did I want to kill the product before it even made it to market? Unfortunately, I had allowed development to spiral out of control. We were far behind schedule with a product I had allowed to become too complex. Whenever I needed a change that should have taken 5 minutes, it took days or even weeks. Over budget, burned out and frustrated with everything and everyone, I just wanted to kill it and move on.
Getting excited
As an entrepreneur of a startup, you have to sell people a dream. The product doesn’t exist yet, so you’re selling an idea that it will somehow transform something/someone/some industry, bring fame and fortune (hopefully).
The first few people we recruit are important. We hype them up and sell them on the dream. Everyone is excited and wants to give it everything they’ve got.
When we started the ArtStation project, everyone was super excited about it. We were going to transform the art industry with our awesome portfolio builder + social network. We held validation waves and got tons of feedback. The designers and developers I had brought on the project went full throttle creating the product.
Designers will design
Designers are always going to design. We love to create things. We love to innovate.
The problem with designing for something that doesn’t exist yet is that the constraints aren’t real. You’re coming up with stuff that make people go “WOW that’s awesome!”
The first version of ArtStation that we ended up creating was a marvel of design. Every single icon was custom designed and crafted. Inputs had no labels on them. The UI was “cutting edge” and “innovative”. The mockups looked sexy as hell.
However, this combination of talent, obsessive nature, excitement about the project and going the extra mile also created a complete nightmare to work with. Because icons were custom designed, every time we needed a new icon, we had to ask the designer to create a new one. Because he’s obsessive about his work and wants to give it 120%, he spends hours on a single icon. At this point, ArtStation is also regarded a side project and our agency business is the priority, so he has to do this in his spare time. Getting a new icon would take days if lucky, usually weeks. If we had used a pre-made icon kit like FontAwesome, we would have just chosen an icon and that was it. 30 seconds of work — not days.
The “innovative” designs that were “boundary pushing” were also practically unusable in real life. Because many of the components were completely new, our developers had to implement them. The problem is that anything you develop will generally suck in its first version. Things won’t work correctly. And there are always nasty edge cases that you didn’t think about.
That’s exactly what happened. The interface just didn’t work properly — inputs were practically impossible to use because there were no labels, many components failed when the screen wasn’t the size that the designer intended. Everything looks good and works perfectly on a Photoshop mockup and InVision prototype, but in real HTML it looks and works terribly.
After spending months and tens of thousands of dollars, the UI was a disaster. If we had just stuck to tried-and-true UI components and workflows (like the ones in Bootstrap) the product would have actually shipped. Instead we had a hunk of sexy, unusable turd.
Was it the designers fault? No. It was my own stupid fault.
I didn’t want to be the buzzkiller. I had sold the dream. I couldn’t bear to tell him — “Dude this won’t work” or “Dude this design is going to take 10x longer to make than just using Bootstrap components and FontAwesome icons. We’re not doing this.” I wanted to be the cool boss that allowed for innovation. I wanted to be the cool boss that allowed the team to try something and fail. The problem was that I couldn’t afford to fail. I’d blown tens of thousands of dollars and was nowhere closer to shipping a product.
Developers will develop
It’s not just designers. Developers will go the extra mile and drive off a cliff as well. Developers are creative. We’ll do our best to come up with solutions for problems that don’t exist yet (but they might!). We’ll engineer things so that if your product scales, you won’t have to worry about it. And we’ll custom build you things as well because the off the shelf stuff doesn’t exactly work the way that your product does.
The developers on ArtStation are all highly talented and motivated. But again, I didn’t provide enough constraints and it spiralled out of control.
Our front-end developer wrote the entire front-end CSS from scratch. He had decided that using a framework like Bootstrap was excessive because we wouldn’t be using 90% of the components in it. The problem is that when you develop something new, it hasn’t been production-proven. The CSS was problematic. It didn’t work well responsively. There were weird edge cases. And whenever we needed to add new things, like a table or another kind of input or button, we’d find ourselves with no styles for that component, so we’d have to go back to him and it would take days to get the component styled, but then it wouldn’t work properly the first time or we’d find weird edge cases, and have to iterate again.
Our backend developers had fallen off the rails as well. They wrote a services layer on ArtStation, citing best practices. Yes, I accept that a services layer (or service objects) is good. But we’re trying to ship a freaking product here and the architecture they created was excessive. It had deviated from standard Ruby on Rails far enough that the project had very high technical debt. When I put other Ballistiq devs on the project, they’d freak out, kick and scream at why this was so far off “the Rails way”. And the architecture was buggy as hell. Again, when you create something from scratch, it generally always sucks at first.
Was it the developers fault? Again, no. It was my own stupid fault again. I had allowed the developers to dictate to me the “best practices” and I had allowed them to go their merry way, which meant many sprints iterating on perfecting the architecture but not actually shipping the product. I failed to communicate the real business and time constraints and acquiesced to their push back, wanting to create beautiful code. I didn’t want to be the boss that said, “Dude — you’re writing stuff that we can just solve using standard Ruby on Rails and gems —please don’t rewrite the freaking wheel”.
Crawling out of that hole
In February 2014, I was burned out. The project was going nowhere. Behance had been acquired by Adobe. DeviantART got $10m from Autodesk. Other startups were getting funded building similar things to ArtStation. I knew that ArtStation would likely just get squashed by these bigger players. I wanted to just cut our losses and move on. I made a recommendation to my co-founders that I wanted to shut down ArtStation. My partners looked at me stunned and asked me to take a break for a few weeks. I took everyone off the project, telling them we were going to take a break for a few weeks.
Then, being the obsessive workaholic that I am and unable to sleep at night knowing that I’m a quitter, I decided to give it one last shot. I rolled up my sleeves and dove in.**
Because our designer was busy working on agency projects, I no longer had a designer to fix all the issues we were having. I redesigned the entire interface using standard, tried and true (non-innovative) components. I designed with technical constraints in mind. I spent very little time in Photoshop just to get the overall design direction.
Then I moved quickly into HTML, scaffolding the entire application in Bootstrap and making design decisions with real HTML. I had to throw out all the CSS the previous freelance front-end developer had created. I simplified the design significantly. Icons were from FontAwesome. Literally months of painstaking work by a team of people were thrown out in favour of simpler, less sexy things that would get the product shipped.
A week later, I had a working prototype of the new ArtStation.
I had to confront the front-end developer. He got pissy and complained that my front-end was bloated. We exchanged words. Ok. Bad fit for the project.
I had to explain to my designer about why his designs were changed. He understood. He appreciated the business reasons and was happy with the new progress.
I had to confront the backend developers about complexity. We wrestled with it. Compromises had to be made between creating beautiful architecture and meeting business objectives.
It was a very challenging time, but we got through it. In March, I flew to Los Angeles with my co-founder. We showed ArtStation to many artists and studios and universally got positive feedback. In April, a competitor went out of business. We launched, we kicked ass and have been ever since.
Context, transparency and being a hardass
The biggest lesson that I learned was that you have to provide context and be transparent. When talking to my team, I should have given a lot more context about the constraints of the project. We really couldn’t afford the time and cost overruns. We needed things to be as “off-the-shelf” as possible so that we could ship the product.
I also needed to be a hardass and confront issues early. I had to not be afraid of confronting a team member. I had to be more comfortable with being a buzzkill on the team, even if it meant driving away talented devs and designers that just weren’t a good fit to begin with.
It’s still a gut wrenching experience. Whenever I see a new design and I have to tell my designer, “Dude I love your design but we can’t make this.” and he pleads with me, “Please can we just try it out?”, and I respond, “No man, this will take weeks to prototype and by the time we’ve invested that we won’t want to throw it out and want to spend more time iterating on it.” I can see the disappointment in his eyes. I can feel the excitement rushing out of him. I have visions that he’ll want to leave for some stupid startup with millions in funding where they can afford to iterate on nothing.
Being boss isn’t easy. There are no easy answers.
Today, I couldn’t be happier with what we’ve achieved with ArtStation. The team has grown together. We bicker and banter sometimes, but we get it.
Ship the freaking product.
Addendum added Thursday 26th May 2016:
Thanks to everyone for recommending the article. I was truly not expecting this article to become such a big hit and that so many people had experienced the same pains.
I’ve had to edit some parts of the article and a footnote to clarify some things.
** This section was not about heroics. The necessary people on the team were kept in the loop. The designer had already been re-assigned to other agency projects and wasn’t available to continue working on the project. One freelance developer with NIH syndrome was intentionally sidelined so that we could unblock the rest of the team. Just wanted to clarify. Also do read Robert Monfera’s response as it has some great points.