Obeying your thirst on making an impact
Recently, I’ve joined Workable as a Product Designer — and therefore I became a member of Workable’s design team. I found it fascinating to join a group of people designing an “easy to use” product, a main selling point according to our customers. People are choosing Workable over other solutions only for that particular reason. Pretty cool, right?
From my experience — and a fair amount of discussions I’ve had with other designers, in your first months people (for the sake of the post, designers) want to make an impact. That’s my understanding. You want to add this great animation to your prototype, you want to introduce a shiny new component. You want your result, your outcome, your idea to hit the shelf as soon as possible. And I understand this, since I had the same urge of doing big things from day one. The thing is, I gave this thought extra time to process.
It works, so why change it?
First of all, in my case I’ve entered a functional and established environment. The product was developed long before I joined. The process was defined and iterated long before I joined. How design worked inside the company was well defined long before I joined. I realised that I joined a team where things were working, and most of the time they worked well. So, why try and change them? I took a step back and reflected: I wanted to learn and become better, and sometimes in order to do that, you must simply listen and follow.
Users are already familiar with the product
I had to deep dive from day one; I loved it. I was told that I’ll work on a project that was an advanced one for a new-come designer. Fast-forward some weeks, I was in front of my monitor choosing the set of pixels (components) I’d drag and drop into Sketch to generate my prototypes. There were certain parts I thought could be or look better on certain components. I tried to resist my urge of re-creating them, and instead I tried to embrace the gut feeling to use them as they are. I thought, if we really need to refine those components, we should allocate time later.
It makes the team happy
I was happy producing and making progress on my first assigned project, and I noticed that my team was happy too. Engineers were happy because they could reuse components. The product manager was happy since the sprints were — more or less — accurately estimated. In general, everyone was happy with the progress. And thinking back to this, I get why. It’s frustrating and demotivating to plan the X and end up working on Y. Especially when Y requires additional effort — which is not seen until you start working on it.
You ship faster — you iterate faster
It was no secret that releasing on time and as planned, without extra delays would make everyone happy. In addition, releasing on schedule would let us see the actual feature’s adoption and usage, in order to iterate on it, if necessary. As a huge plus, when not pushing big vaccine things inside sprints, you create no technical/design debt. Everything works as it should.
Plan a huge redesign if its needed
Having said all these, don’t get me wrong — I’m all in when it comes to suggesting personal views on how to improve the process, the product, everything. I am not saying you should be the quiet person in the room. I’m saying that when something is bigger than you, it involves other people and it affects many moving parts, plan it first. You don’t want to make a big impact at all costs — you want to get the job done. Potentially, you’ll make a big impact. You can plan that.
But first, get the job done.
