Early in my career, I worked for a software company in product design. This particular company was working on revamping their ancient tools for the modern user. I was assigned an especially difficult project, but nevertheless I was excited to reimagine tools that people hate.
After months of drawing, wireframing, user testing, drawing again, client testing, starting over, testing some more, redesigning, and drinking my fair share of margaritas with a co-worker. I was confident in what I had made. It met all the criteria–it had the right information structure and hierarchy, it looked clean and modern, and most importantly user testing validated my choices.
But, I missed one very important detail…
I was so confident in the design that I forgot a crucial part–the art of explaining and validating my choices to my team and stakeholders. While I continued to iterate on my design and narrow in on the right solution. I presented my work several times to various people of importance and did what I now call “the design dump method”. I walked through the presentation talking about what button needed to go where, color choices, etc. But I didn’t talk about the whys behind the design. While the work was becoming stronger and more detailed I just assumed that the design spoke for itself.
It never does. The work is only as good as your ability to sell it.
I want to first say that, great salesmanship never trumps having the right design. Good design is obvious. And good salesmanship is just a confident expression of an obvious design.
So how did this play out? Well, I was removed from the project, my design was bastardized by someone that had no understanding of the project’s challenges or the users it represented, and 9 months of my brutally hard work evaporated in a instant.
Soon after, during an impromptu lunch with a co-worker (and now a very close friend), I got the most difficult feedback I’ve ever received. It started out as most motivational friend chats go when one of you takes a hard hit. He empathized with the unfairness of me being removed from the project, he validated that I made the right design (and that user testing agreed), he reminded me of the difficulties of working for a company that doesn’t always put its users first. Then he stopped, looked at me, and said, “With all that being said — I don’t feel bad for you. Your design was right but you didn’t sell it and you deserved to fail.”
In this moment, the channel in my brain that holds all my most venomous phrases to scream at another individual was so overwhelmed that I was left speechless.
After the dust settled, I gave myself some time to reflect on the experience. And while this particular company didn’t prioritize the user experience, I couldn’t ignore the feedback that my friend gave me. I realized that maybe my project would have been actualized if I had spent more time explaining the whys and focusing on how I could best present my work.
Designing a presentation is a lot like designing a product. You need to know who it’s for, what they need to know, and present it in a way that’s understandable and ultimately positions your solution as so obvious that it seems crazy to do anything else.
Here are my lessons born out of failure:
Tell the story.
Talk about where the project started, what’s working well, what could use some improvement, and what you’re going to do next. Use client stories to support your work. Real humans using your product tells a compelling story.
Know what you want to get out of it.
Throwing your work down on a desk and talking without a point will mostly result in frustration. Answer this for yourself–what feedback allows me to take this project to the next step and how can I position my solution with that in mind.
Know what your audience is afraid of.
Every stakeholder has their own concerns. Taking time to think about the project from their perspective will help you have a more productive conversation.
Have an opinion about the big picture.
It’s easy to get blocked in by your project and think “all these other things aren’t my responsibility,” but that’s a flawed way of looking at it. Project size and complexity vary but every design should ladder up to the larger vision. Stakeholders know this and will veto your work quickly if you’re not thinking about the whole product ecosystem. This is a big one.
Plain and simple. This shouldn’t be confused with blind ego. Again, confidence is just the expression of a good, clean, and obvious design. Confidence isn’t about knowing the outcome. It’s about knowing how to deal with the obstacles and feeling certain that you can figure it out.
Thanks for reading— I’m Mary, a Product Designer in NYC. If you enjoyed this: like it, share it, tell mom about it. Follow me on Twitter.