At 37signals, our designers write code. Not just HTML and CSS — Ruby and JavaScript too. We can all get reasonably far implementing an idea before calling in a programmer for help.
I was lucky to get a crash course in Rails when production for the new Basecamp was kicking into high gear. But even after a year in the trenches, I wasn’t confident I was Doing It Right™. So last fall I took the Rails for Designers class at The Starter League. Obviously, the class helped me get better at programming. I wasn’t expecting it to transform my design process — yet that’s exactly what happened.
Before you can walk, you have to stand on your own feet.
An interface isn’t just a series of static screens pasted together. It’s a flow, with inputs and outputs. You can’t truly evaluate an interface until you can use it, and you can’t use it until you build it. Anything less than the real thing is a fuzzy approximation.
It’s fine to bring in a programmer when you’re confident that your idea is worth building, but what if you’re not so sure? Now you’ve used someone else’s time and mental energy to make something that might hit the dumpster. That stinks.
This hit home recently when we started working on a new app. Before, we’d make a static mockup or build a few working pieces and then call in a programmer assist. This time, we’ve been able to stay in the prototype phase much longer – almost 2 months – without having to use up a programmer’s time to test concepts and explore ideas. Basic programming knowledge lets us dance without a partner.
You don’t have to be a code master. I am most definitely not. If you can just make things functional, that’s enough to evaluate and a huge head start for a real programmer to make it great.
Are you a designer who learned to program? How did it change your process? Let’s hear it in the comments.
Alasdair Monk
on 22 Feb 13Definitely agree. I’m no programmer but learning PHP and then HTML, CSS, Ruby, Rails, iOS development etc has definitely made me a better designer. Even just because I know how hard or easy something I design will be to implement.
Scott
on 22 Feb 13Man, you work with the best Rails programmers in the world (not to mention the creator), and you went out of house to learn it. I’m just jealous :)
Jonas
on 22 Feb 13@Scott: the class was held in our office, and several of our designers took it. Plus The Starter League is in house. :)
Scott M.
on 22 Feb 13Learning to program (Ruby) has helped me visualize user flows through an entire application rather than one disconnected view at a time. I know what goes into building an app and I know the limitations and opportunities. I’ve found myself building simpler interfaces, chucking “clever” interactions and opting for straight-forward, obvious ones.
Jonny
on 22 Feb 13@almonk (hello!) why should it matter to a designer how hard or easy something you design is to implement? To me, that encourages conservative design. Freeing designers up of those constraints is how we move interface design forward.
Joe
on 22 Feb 13What’s the new app? Come on – you can whisper it to me. I won’t tell.
Jon Gold
on 22 Feb 13Totally agree — thinking about how things will actually work (rather than just hoping an engineer can figure it out) makes you a better designer.
For me the key thing is adopting an attitude of constant learning. I might not be paid to write an iOS app anytime soon, but learning how things actually work after years of convincing myself it was too difficult was a great thing just for my self-confidence.
I see lots of my designer-friends who refuse to learn Ruby or JS as stubborn – not because they don’t want to write it, not because they’re not intelligent enough to learn that way, just because they’ve convinced themselves it’s something they can’t do.
No one should go through life thinking they can’t do things :)
Joshua Blankenship
on 22 Feb 13I started learning to build basic sites around 6 years ago, primarily because I didn’t have any programmers in my immediate circle. I still consider myself a hack programmer (just enough knowledge to make trouble for the professionals), but I can get 75–85% of the way into a full site without relying on someone else’s time and expertise.
It makes me faster, forces me to prove my design ideas are good interface ideas, and helps me bridge the gap with my more-than-capable coworkers, in addition to making our team work better because we’re collaborating on a whole thing, not handing off disparate pieces and trying to make something whole out of them.
Every site I’ve built in the last four years started in a text editor, not a graphics program. And my sites are better for it. Coding, at least frontend stuff, has just become an extension of sketching.
Joe
on 22 Feb 13@ Jonny – it’s not just difficulty to implement, but also difficulty to maintain, change, troubleshoot, and enhance over the years of the product’s life. The clever but arcane solution to problems may seem great at first, but the shine wears off and the product takes hits when the future you or future programmers are less productive later (requiring larger programming staff and slower product updates) due to it.
Ben
on 22 Feb 13Absolutely agree! I started out in print design 10 years ago, got into web design a little bit more; built my own portfolio in html/css, did some small front-end coding for friends & family, then small businesses, then larger businesses. Played around lightly in everyone elses systems, hurling scraps of shoddy php code around as I went. Did the wordpress thing, magento thing. Then realized its time to pick a stronger backend language. Played with Ruby/Rails & Python Django, went the RoR route. 5 years later, I spend 70% of most my time in my text editor, 30% in Adobe products: PS, AI (and only about 2% in InDesign, can’t even remember the last time I opened Quark). All said and done, without learning to code, I would not understand UX like I do today. And likewise, had I not had the design background, I would be a pretty boring programmer.
Dave
on 22 Feb 13I can definitely see the value in learning presentation-layer coding, the nuts and bolts that render the design will veer you towards solutions that can be win-win for designer/developer.
I worry though the cross-noise between UX and backend programming. The UX/design should accommodate the user and without revealing the underpinnings / implementation model. Programming is virtually always about using the most efficient method to reach your goal. The problem would be if concessions made by UX/design to implement a backend more efficiently could otherwise bring about a better design.
Of course expanding our frame of reference and skills is invaluable, as long as we careful not to expose the implementation model to our users.
Jason James
on 22 Feb 13I’m curious about what happens to your code. Is it useful to the developers? Or do they end up scrapping it and rebuilding? I’ll do some front-end dev, but lots of devs I know prefer to do the whole thing themselves because then they know every little thing about the code they’re implementing.
Just wondering, is the goal to work out your ideas for yourself? Or to do that and get a head start on production-ready dev? Makes a big difference is how much you need to care about Doing It Right™.
Leonardo
on 22 Feb 13Excellent post! A few months ago I thought I was going in the wrong direction, since the time I was investing in programming could be used for studying other design skills. But this post inspired me to continue learning Ruby and Javascript.
Thanks
Jonas
on 22 Feb 13@Jason: I’m not sure yet how much will get used in the production version (if we get there.) I’m curious to find that out too.
For now, the main purpose is to work out the ideas, and if that gives us any sort of leap on going to production, great.
Geof Harries
on 22 Feb 13What you wrote “You can’t truly evaluate an interface until you can use it, and you can’t use it until you build it.”...is very true.
I can go deep into the visuals and make what I think are sound decisions based on years of designing and being part of teams building software, but most often, that “at a distance” position is simply not enough. Sometimes I really need to see and use the product, as well as observe other people fumbling through it, before the right choices are made and implemented. And this is never a one-time thing. I find myself going back and forth, over and over again, to make tweaks and changes until the software is right.
That’s where knowing how to handle the basics in the platform you’re building on (typically this is .NET, IIS and MSSQL for me) is really, really beneficial and empowering. Not only can I help to create the software, but I can make small updates and roll stuff out for testing without having to bug the developers who are working on the more complex stuff. Being dead weight – and by that I mean only being able to push pixels around in Fireworks or Photoshop – sucks.
Aubrey
on 22 Feb 13Learning to program has helped me make more realistic designs and work in symphony with advanced engineers. Great post and you’re 100% right. :)
Mike
on 22 Feb 13“Anything less than the real thing is a fuzzy approximation.”
Personally, I’ve found a lot of success with rapid prototyping and iteration, and if I had to do that with the “real” thing, it would slow my process down to a crawl. I’m able to go through more ideas faster and in parallel with using “fuzzy approximation” of low fidelity prototypes. It’s common in other design disciplines sacrifice to sacrifice 100% realism for speed and iteration – film makers use storyboards, architects make models. It’s a proven technique if you know how to use it. You have to throw things out that don’t work to get things better—that’s a good thing.
For more interactive prototyping, I’ve used Axure and jQuery successfully. If I need live data, then I prototype in HTML5 and use jQuery to consume APIs.
I like to keep things simple. Even when I’m writing full apps, I often find Rails to be overkill and stick with lighter-weight frameworks like Sinatra.
Alex Tokarev
on 22 Feb 13I’m a programmer, and now I’m studying design. My situation is quite opposite, but it shows that understanding design principles is very useful for programmers too. Thanks for the post!
Ryan Keairns
on 22 Feb 13We follow a very similar process. In fact, we are experimenting with prototype controllers in our nascent rails apps. This allows the design team to get rolling on real code and take advantage of rails helpers. Furthering that we exploring ways to provide some ‘dynamic’ content that we can style up.
So instead of copy/pasting rows in a table (as really bad example!), we can have some basic data and classes available to mock up some real content (without having to fiddle quite yet with setting up database tables).
In our situation we often get a lead out prior to dev resources being available as we jump between projects… this has helped us lay a better foundation of code that is actually usable.
Greg Funtusov
on 22 Feb 13Before, I always thought that you should specialize, and if you want to make something good, concentrate on it.
The past years I was mostly a rails developer, taking care of the server side. However, I was also intrested in visuals and ergonomics, I wanted to be an architect, worked a bit as an interior designer and as a photographer.
I find my passion in both creating some smart machine learning back-end, and crafting a beautiful and easy to use interface for it, and now wonder whether it’s really possible to create something innovatively good without quite a deep understanding of the whole picture.
Peter Sylwester
on 22 Feb 13I’m a designer who came to coding, but what is more, I’ve worked as the coder among a team of designers AND as the designer among a team of coders. From all that experience, one thing is certain to me: truly creative design requires a certain detachment from the logistics of the code. Call it abandon, if you will, but I’ve found that design needs it, and unfortunately, abandon seems to be inhibited by knowing the complexities of implementation. To the same effect, I think a coder can be lulled into designing in ways that are sometimes more conducive to the code than the user.
Don’t get me wrong, I appreciate that coding and designing are not mutually exclusive, but I just think that the best code is sometimes written when unfettered from the design, just as the best design can be made when unfettered from the code.
As I’ve considered these things, I read the book, “Thinking, Fast and Slow” (Kahneman), which discusses how recent brain research suggests that we have two levels of thinking, (1) quick or (2) contemplative. This is actually a much more accurate assessment of how our brain works than the (now debunked) left- and right-brained theory of old. I have come to believe that our “quick” brain (Kahneman labels, “System 1”) is more design oriented, appealing to our immediate senses, emotions, and intuition. This is what the user of the product may rely on as well. On the contrary, the “contemplative” brain (“System 2”) is what is required when things are build, especially complex things that require deep thought. As the book discusses, it is actually these two systems in our brain that are mutually exclusive, leading me to believe that there might be something to why design and code are sometimes like oil and water.
Stewart McCoy
on 22 Feb 13Hi Jonas, thanks for sharing your thoughts. Do you have perspective about how this applies across different company settings? i.e. agencies, small-to-mid-size startups, in-house teams, and enterprise SaaS companies?
I work as a UX designer for a mid-to-large SaaS startup. Our process currently has UX coordinating closely with PMs on product requirements through UI design, handing over specs to engineering or a contract team to build out the front-end.
I’d love to use Ruby/Ruby on Rails to start prototyping once MVP requirements are set, but I’ve had a difficult time making the argument that it’s worthwhile. I think that in the long-term it makes sense for complicated internal tools to be built and maintained by our design team. Not only will it be easier to get initial feedback from end-users and other stakeholders before engineering starts building out backend functionality, likely reducing the amount of miscommunication and the amount of time required for repeated knowledge transfer, but it would make it easier for design to make updates (rather than submit tickets to engineering) and to iterate on new versions.
The counter argument is that UX resources are precious and they need to be focused on pushing forward on UX initiatives, that it’s a lot of overhead for designers to sufficiently learn frameworks like Rails to be effective at rapid prototyping, and that the code likely wouldn’t be up to engineering standards and would have to be re-written. All of these are valid arguments, but I still believe the former approach is more sustainable in efforts to avoid both design and technical debt.
Eric
on 22 Feb 13I was a print & web designer before learning Ruby and Rails. Beyond what others have said, learning programing concepts has improved the way I think about building anything. Principles like abstraction, encapsulation, modularity, etc. change the way the brain looks at a lot of problems.
Jonas
on 22 Feb 13@Stewart: If you’re interested in using Rails for prototyping, you should just dig in and try it. Maybe on a small-stakes project so there is less pressure. Don’t worry about how it integrates into the rest of your process or your production apps. See if it’s helpful, and if so, press on.
Obviously it will help if your company is supportive of the endeavor, but sometimes you have to get the ball rolling before people understand the advantages.
JZ
on 22 Feb 13Great post. For me there are a few extra dimensions to this idea…
1. Having some programming tools in my belt lets me do more. Certainly this is true in the sense that I can take a design deeper into the implementation, but what I really mean is I can take on more projects and do more work. Part of my motivation to get better at programming was, like yours, about not wanting to waste someone else’s time. I often felt guilty that I was asking programmers to do work that was beneath them. But the other motivation was more selfish: I just wanted to do more. Rather than waiting for a programmer to free-up I started taking-on projects that were a little beyond me but that I thought I might be able to figure out. The result was freedom. Freedom to work on the most important things rather than just the projects that were design only or the ones that aligned with a programmer’s availability.
2. Another big thing for me was not so much about learning to program, but learning from programmers. As Scott noted above, we work with some of the best programmers in the world so I regularly read their code commits – especially the ones that come after mine. What did they change? Why? This simple practice has taught me so much. From the very start I noticed how careful, methodical and purposeful every patch was. This helped me become more thoughtful and intentional in my designs.
3. Learning to program has made me a better co-worker, too. Working with programmers, it seems only natural to speak their language. Learning to program means I can communicate more effectively when working with a programmer (I hope).
Shawn Borsky
on 22 Feb 13As a fellow designer who learned to code ( more by necessity than desire) , I totally advocate this approach. In general, it changed my process from “how will this look” to “how would I build this” and “how will this feel”. My previous design process feels like cheating because I was off-loading too much of my job onto the engineer implementing the design.
Jonas is 100% on point, that all it takes is a making your code work to communicate and test. Giving the engineer a good starting point does so much. Much of the design, user experience, flow and interaction decisions have been made and the engineer can focus on making the implementation solid and scalable which is usually what most engineers want to work on and care about.
It amounts to smoother development, better products, more shared responsibility, and better communication.
Franklin
on 22 Feb 13Me gusto el post, tienes razón al decir que no es necesario ser un experto para explorar una idea, aunque yo no programo con Ruby pienso que es una opción muy buena para desarrollar sistemas web escalables.
Mu-An Chiou
on 22 Feb 13I’m a designer and I started learning Rails about a year ago. I cannot imagine ever not knowing the things that I do know now. It is just incredibly valuable to be able to build things on your own.
It’s incomprehensible how a lot of designers are fighting off the idea of learning how to program. It is just simple fact that knowing how to do backend gears you up with 10 times more strength. When programming(particularly Rails) isn’t all that difficult, it makes almost no sense to try not to learn. (Well, being able to build basic stuff isn’t difficult, to become those guys you work with, however, is difficult.)
The whole thing about designer learning how to code has very little to do about work load and distribution, but a million to do with having a truly clear vision on the app you’re designing for and being able to build things on your own.
So, awesome post, learning Rails was the best decision for me in 2012.
Eric Dobson
on 23 Feb 13I agree with most of this post and most of the comments. Lots and lots of benefits to learning outside your field. The one thing I disagree with is the idea of wasting a developer’s time on something that will get scrapped.
It’s no different than ‘wasting’ your own time on a scrapped design. It’s iteration, not a waste, so there’s no reason to feel bad about both doing what you do, moving on, and trying again. You think they never throw away their own code? You’re a team. Ship a finished product to the customer. Don’t worry about failed attempts explored together.
pathmaker marketing
on 23 Feb 13I agree with Eric Dobson.There is a lot of benefits to learn not just with your field but also beyond your own knowledge.
http://www.pathmakermarketing.com/
Pete R.
on 23 Feb 13I am also a designer/rails developer. The great thing of knowing how to code backend, frontend and design is that you can bring a product to life without no one involve except you. This allows me to test my idea faster and to learn from the experience of being both designers and developers. It also give me all sort of perspective that allows me to design more efficient because I now know what’s possible and what’s not.
You can see my latest solo rails work here: Bucketlistly
Mike Ballan
on 23 Feb 13I totally agree with you man, I started as just a plain designer but was always intereasted in how things where made so one day i thought hay lets learn HTML & CSS and later PHP, and ive never looked backed.
With just the simple knowledge of how a website is built in HTML & CSS you can create a much better website not only in user journey but also the time it takes to build as you will be building the site in your head when designing it..!
Igor Asselbergs
on 24 Feb 13I fully agree with Peter Sylwester: “one thing is certain to me: truly creative design requires a certain detachment from the logistics of the code.” And I’d like to add to that a simple question: What if the lifecycle of your product requires porting from say Java to Flash and then to iOS? I experienced exactly that as a designer in the course of 5 years or so. I think I would have been really screwed if I had invested in Java coding early on….
Your argument only makes sense if you expect to stick with a single platform.
Berserk
on 24 Feb 13@Igor:
Only if you expect to not learn anything new.
Most (web) programmers need several languages. Virtually every day I use Perl, Javascript and C#, and related languages like SQL (and ORMs like NHibernate (for C#) and DBIx::Class (for Perl)), CSS and HTML. If we decied tomorrow to use e.g. Rails tomorrow, then I’d learn that.
If you had learned Java five years ago, do you think you would have had zero benefit from that?
Anonymous Coward
on 25 Feb 13@Berserk “If you had learned Java five years ago, do you think you would have had zero benefit from that?” I’m pretty sure that I missed out on a lot of valuable knowledge by not learning Java. It would probably have made my life a lot easier. I’m not sure though if the effort of learning Java would have weighed against the benefit. And I’m pretty certain that it wouldn’t have improved my designs in any significant way. Perhaps even the other way round: it might have attached me to some of the intricacies of the Java platform.
stuart
on 25 Feb 13great post @jonas . Have you heard of any programs similar to The Starter League in San Francisco?
Tim
on 26 Feb 13I’m not sure how this whole designer / coder split got started. I remember programming RPGs in BASIC back when I was a kid and also designing EGA background graphics for game companies back in the early 90s. I’m still desinging and coding, and find it odd to have conversations where people try to do the awful ‘so are you a designer or a coder? pick a side!’ conversation.
It blows me away in meetings with startup founders and other tech veterans that they think of designers and coders as separate disciplines. I gravitate to people who naturally can do both (or at least have an interest in both), and are true futurist visionaries rather than tech dinosaurs with their ‘pick a side’ mentalities. Knowing how to design and code makes you dangerous, and that’s sexy as hell.
Ayyash
on 01 Mar 13As much as knowing the limitation technology can present (and thus time things better), also knowing what technology provides would open up the design… I’ve seen designers who just “know” Ajax and go on and do great designs, but the minute I dig into the HTML,CSS,JS part of it, I realize I could do a bit more… I’m always surprised! I think designers should present their ideas not only in HTML format, but in a server-side fed format to show case the effect they want. The other plus is: developers cannot screw with you with “this cannot be done!” Just tell them, here, let me show you!
This discussion is closed.