November 25, 2014
For a while now, I’ve been one of Monterail’s product designers.
I used to have some startup ambitions in the past, an experience and mindset that turned out to be very useful, but the transition from a developer to a product designer was not that easy. I had to learn. I still have to.
Here are the most important lessons I’ve learned over the last few months:
If you’re interested in building web products—software, applications, startups—let me share these lessons with you so you won’t have to learn them on your own.
In the product field, caring about the business is as important—or even more important—as caring about the design.
If you personally want to design beautiful interfaces, be a UI designer. A product designer should be an idea guy.
Keep in mind, however, that any idea failing to generate value for the clients is worthless. That’s why early in the stage of building a web app or a feature, the product designer’s job is to analyze the organization’s business model and then, later in the process, use it for strategic planning.
Sometimes, generating value means you have to look for tradeoffs.
In order to build a successful product, you have to be able to get your hands dirty. Ask yourself a question: would you intentionally release an imperfect feature? If you’re a perfectionist, you’re probably crying out in rage right now. That was my initial reaction as well. I can feel you. I really do.
But what if this feature is able to generate enough revenue to sustain a business that’s been running slow lately?
The lesson here is: don’t worry. You can always flesh it out later.
Just be patient.
And that’s how we get to the topic of patience.
Have you ever thought why programming becomes so addictive once you get a hold of it?
My friend has a theory. According to him, programming is all about instant gratification: most of the time, only one line of code will suffice to see “hello world” on your screen. With Rails, you can build a working app in 5 minutes.
It’s so easy to make something that feels real.
With product design, that’s not the case. Design process takes time. Your ideas have to be understood and accepted by the client; prevalidated against production reality; reworked into mockups and designs; implemented by the developers. Even in Agile companies like ours, the shortest time between the initial idea and production roll out is still measured in weeks.
As a former developer, this was the biggest drawback for me. Sometimes I was really frustrated. Where are the results? Does anything I do matter at all? It all made sense over the long term; the short term, however, is always blurry.
Even after your work becomes public, there’s no way to immediately validate it. Even if a feature is a boom right after its release, good results need to last a while to confirm the trend.
As hard as it seems, you may have to wait a few months before you’re sure you did a good job.
That’s why being right in product design is so much more rewarding. Your first feature being deployed to the end users feels like early Christmas.
A few times before, I’ve written about “your ideas,” and that “product designer is the idea guy.” Sometimes, that’s true—but not always. The job of a product designer—a good product designer—is mainly about listening; probably even more than about being the idea guy.
Mainly, it’s about listening to the clients. After all, it’s their product, and you’re there just to help them bring it to life. This job is not about you having great ideas they can’t understand or sell to their customers.
Secondly, it’s about listening to your team’s input. (Not always easy when you can’t see the initial idea in the mockups anymore.)
Not listening was my mistake when I started. I tried to persuade people to my way of thinking as the best solution. The concept was alright; it just wasn’t what anybody else wanted.
Note to self: you’re not a salesman.
You’re the igniter.
The everyday reality of working in a web software agency like Monterail is that you probably have to work on a few projects at once—at least that’s how we do it currently.
If you haven’t done it before, let me tell you: switching between projects is hard. Business reality of one product may not be adequate at all when compared to another. And getting a hold of both short and long priorities of each project is not easy as well—if you want to do it the best you can.
How to manage it all?
I make notes and checklists, because they’re easy to write, check and catalog. They’re cheap. I can make as many of them as I want, and I can ditch them easily; on the other hand, they’re very helpful reminders. And the short form forces you to save only the most essential information. There’s a plethora of mobile software for both notes and todo lists, so everybody can choose what they like.
But perhaps the software is not that important at all. My feeling is that the single most important thing is having a routine and being thorough.
Building a habit of writing everything down ensures that you won’t start from scratch when the idea the client rejected a few months ago suddenly becomes plausible in new business circumstances.
…but I’m sure more will come up later. (Think long term!)
I’ll try to share the most interesting conclusions on Codetunes regularly, so if you’re keen on product design, stay tuned and let me know what you think. I’ll be more than happy to discuss.