In my day-to-day work I make software. Generally I play the role of designer, sometimes I play the role of the developer, and occasionally I do both. But no matter what role I’m playing on a project, whether it’s my own, a collaboration, or for a client, the end result is always software made with code. And I believe that’s important to remember.
“Design is how it works”
Recently a client paid me to design their iPad app. While working on it, we realized the only way to meet the requirements we set would be to create a lot of custom UI elements for inputting data. “No problem,” I said. I designed most of the app in Sketch, used a few different prototyping tools to animate how I thought the user would move through the flow of the app, and let my clients play with the prototypes and watch videos I made.
I knew from experience that there was no way for me to produce enough work to show someone else how to code the app exactly right. Also, I’ve been there enough times to know the right answer for an interaction, size/placement of a button, speed of an animation, or any other design decision won’t always be apparent until it’s actually built. So I happily said yes when the client asked me to also code my designs for the app. Not only was it more money for me, but it also allowed me to make sure my designs were fully realized the way I had imagined them.
Earlier this week I delivered the final code for the first version of this app, and I felt proud. I tapped away on an iPad to test it, and it came together better than I hoped for when I first began designing it. I posted a tweet about how valuable I believe it is to be able to code your own designs, because “Nobody will care about your designs as much as you.” I still stand by this, even though a few people took offense.
One person took this to mean that I should choose to work with better people. In reality, I’ve only worked with really wonderful people. The other developer for this iPad app is really talented, incredibly nice, and a real pleasure to work with. But he had a lot of stuff to do, and when it came down to it there was no way he’d be able to spend half a day making sure new rows of data animated in correctly. But I did, because I knew it had to work that way.
Another person responded because he felt I was devaluing the work of a lot of graphic designers who don’t code. He also felt I was implying that the developers at his old job, where someone else coded his designs, didn’t care about his design work. But that’s not at all what I was saying.
It’s fine if you don’t code and you’re a designer who works on websites, apps, etc. But if your designs are later turned into code before a user/player/customer interacts with them, then you should have the desire to understand and be apart of the creation of that code as much as possible. You don’t have to code much, but being able to run the code on your computer, understand what’s happening, and make tweaks will dramatically improve the outcome. I guarantee it.
This is why segmenting people into predefined roles like “designer” and “developer” can be hurtful. Designers shouldn’t code! Developers shouldn’t design! You stay over there and I’ll stay over here. But in reality, when you’re working in software, those skill-sets blur so much that it’s nearly impossible to draw lines. And the reality is: none of it matters. The only thing that matters is the code that is produced, because that’s the only thing people will interact with at the end of the day. And I personally want to be as close to the people using what I make as possible, no intermediaries or go-betweens.
(brb… i have to go finish making a prototype of an app I’m designing for a client.)