Principle: Effective designers are great at follow through, throughout the design process. This means adopting an “ownership mindset” – being responsible for successes and failures. This includes:
- Taking on additional responsibilities to get the project on track.
- Getting their design implemented as intended.
- Avoiding blaming others for stalled or failed projects.
- Navigating difficult personalities to get work done.
- Bringing together the right people to get the project done.
Real Life Story
“What the heck was that?!” I thought. I had some difficulty with getting my designs implemented by the developer and my manager gave me hell. In short, he got angry and told me the work sucked.
After the meeting, I continued thinking angrily, “How dare he! He didn’t even know what I put into the project. I worked long hours to get this done. Why is it my responsibility to code it properly? This is unfair!”
Come performance review time, I was shocked by the lower rating. I had performed at peak levels for years.
I was pissed.
Failure will happen on a project. There is no escaping failure.
There’s lot of articles on failure these days. People LOVE talking about how “failure is so great” and embrace failure and “fail often!” and yada yada yada.
Failure is a great teacher, but it still sucks. And it hurts. And truly, no one wants to talk about how they failed (until much much later when they get over it).
One of the key soft skills that effective designers cultivate, when failures happen is to adopt a ownership mindset.
Ownership in design means to own the design – from beginning to end. Ownership doesn’t just mean “creation rights.” In my definition, it means having accountability for what is built per your design.
“Failure” Will Happen
Failure will happen. There are a variety of problem scenarios that can happen, centered around your design:
- Deadlines keep slipping
- The quality of the design that is launched is poor
- The project is blocked for some reason (not enough resources, not enough stakeholder buy-in)
- Your design gets torn apart during design review (and in front of your manager and peers!)
- Your developers ship something without telling you
- And more…
Get rid of excuses and blame
When problems happen, people expect justice for others and mercy for themselves. – Anonymous
In the real life story I shared above, I was angry that I got blamed for a developer’s poor work. When the product launched, it was due to the developer not planning their time and fixing all the css per my design.
Or was it?
At least, that was the perspective when I was getting the heat from my manager. When I calmed down I realized that in order for me to be successful, I had to adopt the mindset that I was responsible for everything related to my design.
To do that, I had to push aside the blame and excuses I was telling myself when the project “failed”.
Here are some of these excuses for you to avoid:
Excuse #1: My manager should’ve known, it’s THEIR job
My manager’s lack of understanding was annoying to me.
But in hindsight, he was right.
I had status checks with him early on and showed him progress, but his job isn’t to be there checking on the quality all the time. That’s my job.
Later in my design career I realized that most manager are swamped and don’t have the bandwidth to babysit you and your project to completion.
The babysitting is reserved for junior designers, who are expected to not yet be able to fully manage a project on their own due to their lack of experience and/or skills.
If you are a junior designer reading this, ownership helps you stand apart.
If you’re more senior, it’s expected of you. Inform your manager of what is going on – but don’t use that as a crutch for designs that don’t meet expectations (yours or others).
Excuse #2: The Developer screwed up
Developers don’t screw up. If your developers code things that don’t match your design, it’s your job to check with them and see where they are at.
If their progress is slow and you’re seeing the deadline approaching soon, HAIL THE RED FLAGS. That’s the best time to let your manager know.
For me, there was no point being angry at my developers (my teammates). They were swamped. Truth was, they had hustled and worked long hours to build out a lot of the functionality I designed.
And they were fairly OK to work with – attitude wise.
Excuse #3: The Product Manager or Project Manager is Responsible
Everyone knows the product manager is responsible for the success of a project. While that may be true, it’s not a helpful attitude to adopt, for 3 reasons:
- You can mentally check out and silo yourself as a “designer” and that’s product manager stuff – which hurts a team mindset.
- You may not be responsible for the success of the product itself, but you are responsible for the design and the impact of the design. If the design is horrible and many people think thats the reason for the failure of the product, people may start to point their finger to you for the project failure, not the product manager.
- Nowadays, the designer is being looked to help validate the business ideas as well. The idea of designing an MPV for experimenting and testing in the marketplace is becoming prominent as more and more designers are learning “lean” thinking which focuses on designing and launching small experiments to test your ideas.
Tactics for Ownership
The idea of being only responsible for your part of the work is an old one from the industrial age. At one point in America, lots of farmers gave up their craft to become “specialists” (factory workers). They were just tasked to focus on one thing. By doing so, we didn’t have to worry about all parts of a business – JUST the part we were hired for.
In other words, we gave up ownership.
Seth Godin mentions this in his book Linchpin. Godin writes about factory life:
“The job is what you do when you are told what to do. The job is showing up at the factory, following instructions, meeting spec, and being managed.”
Great designers may be managed, but they don’t give up ownership all together. They are also self-reliant, proactive, and take on the responsibility of being aware of the project’s status irregardless if they are the product/project manager or not.
Below are some practical tactics to adopt an “ownership mindset”:
Ask for help
- Troubleshooting early. Raise the red flags when development doesn’t seem on track. Discuss with the team your concerns.
- If you still aren’t on track, go to the development manager to express your concerns and tell your manager as well.
Bring the Right People Together
- Bringing together the right people to get the project done. This may include visual designers, copywriters, or others.
- If you don’t know who else needs to be involved, its a good idea to ask your manager or someone else, “who else should we invite to our meetings to ensure project success?”
Create a Design Bug Log
When my design was implemented poorly (and after I got scolded), I did the following to get the project back on track:
- Talked to my manager again (when I was calm) and asked him how to improve the situation. He suggested I create a log of all the “design bugs.”
- Talked to the developers managers and told them the problem. Had their buy-in for meeting with the team weekly to go over the design bug log I created.
- Met with the developers weekly to fix the existing problems and prioritize future work.
Use a Project Management Tool to keep track of items
- After that meeting, I started using Tom’s Planner, a super simple project management tool for organizing the project. If your team already has a project manager, great! You don’t need to do that. My team was not organized enough – so I took on the additional responsibility to get the project on track.
Are designers responsible? What’s your experience?
Have you ever had to deal with project gone bad and been blamed? What’s your general attitude? I would love to hear what your thoughts are about this topic. Leave your comments below!