Rubber Duck Design

As some of you know, I’ve been working with software developers for the longest time. No, literally. I always was more interested in designing than coding, but it never stopped me from finishing master’s degree in computer science and working as a C#, JavaScript and Ruby developer at various stages of my career. Yes, you read that right, I don’t have formal design education — and I never needed to.

Possibly the most important thing I learned while working as a software developer or side by side with software developers (I just love cross-functional teams, there’s so much learning potential in those) is the thought process behind how you build applications. Yes, learning to actually code is obviously also fun, but once you go past that, there’s a lot of huge things that are common and obvious in software development and designers should learn from.

Enter the rubber duck

First concept coming from the software development world that I believe a lot of designers could benefit from is called “rubber duck debugging”. The idea is simple: when you write code or design, you make a lot of unconscious decisions based on your experience, previous projects, that blog post on best practices you read during your commute and so on. Once those unconscious decisions kick in, you might end up with a solution that doesn’t quite work and you’re not sure why. In software development this might end up with your code being quirky. In design, this usually ends up with your client asking you why you chose this direction during a presentation, to which you go “Ummmm…”. You end up looking silly and slightly unprofessional, your clients are not convinced and you might end up killing a good idea because you could not articulate it well.

Enter the rubber duck. In rubber duck programming, once you encounter a problem that seems hard to solve and you keep looking at your code unable to find a solution, you grab a rubber duck and start leading it through your code line by line. The idea is that once you start explaining your code to someone else (or a duck), you will eventually end up figuring out why this doesn’t work. The whole idea of rubber ducking is why pair programming is wildly successful: having to explain your decisions to someone else makes you verbalize and think through your unconscious choices, making them obvious and visible.

Rubber duck designing

As you probably see by now, rubber ducking could work really good for designers too, especially freelancer, sitting comfortably in their shorts on the beach somewhere in Bali, sipping fancy drinks and designing (because we all know that freelance digital nomads live exactly this kind of dream, right?). Having a rubber duck looking over your shoulder and forcing you to talk through your ideas is a great preparation for actual pitch, where you’ll have to do the same thing in front of your clients or product owners. It helps unearth unconscious decisions and forces you to think them through again, making your design better and more thoughtful. Of course, a lot of this can be also handled by more structured process, like a design critique or design pairing, but not every team has those and if you’re a single designer working from your basement in your pyjamas, you might not have a lot of people to talk to outside your clients. And talking with clients can be great if you have right clients, but can also end up in terrible mess if you don’t. We’ve all been there.
So next time you find yourself unable to understand your own design and you don’t have anyone to bounce your ideas off, go grab a rubber duck. Or a teddy bear. Or a giant Martian octopus from space you bought at that thrift store because “s&#t, it was 99 cents” and has been gathering dust since. Grab it, befriend it and guide it through your thought process. It will be good.