These observations are admittedly a bit on the basic side, but it’s interesting to note that a lot of designers — of all ages — fall down on the basics. Myself included. Sometimes it’s nice to just go back and review. If you’re an early career designer, it’s important to execute and develop case studies around these fundamentals:
Know your users. The simplest mistake I’ve seen problem solvers make starts with the simplest of questions: Who is this actually for? And is this really the problem worth solving for that person? Being clear about those two questions is the biggest mis-step designers are faced with. Solving the wrong problem for the wrong user is not problem solving. Arriving at hasty assumptions, and pouring time and effort into those assumptions, is the partial definition of insanity. Don’t be insane. Talk to people. Hear what they say. Make sure you are solving the right problems before you start solving. If it sounds obvious, ask one of the millions of people who didn’t do it — who assumed too much, or ignored the signs and wasted unnecessary time and money building the wrong thing.
Declare your goals. Include metrics. “We’ll know it when we see it.” Oh God, no. What is success? In the long term, and in the next 30 minutes. Define the criteria for success — for your meeting, your week, your project and your career. Be honest. Be transparent. Be achievable. Set the bar high, and specific. And aim for it. If you think your goals are self-evident, take a minute to write them down and share them. This is another place where assumptions — and expectations — set teams off on the wrong path, measuring the wrong thing (if they measure at all). Mismatched expectations are a time-waster — and a mojo-killer. I’ve watched many projects devolve into chaos because folks never explicitly agreed on success.
Start simple. Try things. Do it soon. Be biased toward action. Eating the whale in manageable bites requires learning 3 million 2oz whale recipes. GO BROAD. Always be trying stuff. Experiment. Build on your successes, find the ahas in your disasters. Capture all of it. And be glad that you didn’t cook the whole whale THAT way!
Don’t validate, learn. Being right is overrated. Instead, be open and curious. Be ready to change course, or to ask for help. Or start over. I’m not going to lie: this is hard and it takes practice and organizational buy-in. Some companies will ask you to fail fast, but they don’t explain why and they may secretly hope you’re just going to luck into the solution on the first try. Other companies will expect you to nail it, on the first try, with a million dollar investment. It’s hard to look a giant pile of money in the face and convince yourself you’re not already probably right. Again, think expectation-setting. If you SAY you know (but you might be wrong), you set a terrible expectation. Instead admit you’re not yet sure, but you’re willing to learn very fast while the stakes are still low.
Manufacture urgency. What can you do now? Or very soon? If we make it narrow enough and important enough — and give it enough priority over everything else you’re working on. How, as a manager, can I make this thing the most important thing for you for the next five days? A week of learning is fast. 3 months spent building a fiery disaster is so very slow.
Celebrate the journey, not just the destination. The road is long. The destination is unclear. People need to feel valued, needed, heard and appreciated on the road, not just during the victory lap (if there is one). Celebrate your experimental mindset. Celebrate what you learned about your ability to learn. Not with huge lavish parties. But with high-fives and shout-outs and surprise trips to Jamba Juice. Your team’s health is your project’s life. Treat it like a marriage — with respect and patience and recognition and unconditional love. Be slow to blame and quick to forgive. Mistakes are just pavers on the road to something great.
Once you know, execute with relentless passion. I mean, once you know, nail that shit. Once you know, the time to learn is over. Once you know, polish that sonofabitch to a high shine and flip it over to make sure it’s good on the bottom too. As my 7th grade woodshop teacher said to me 4 billion times, “Sand that.” Sand that animation, that copy, that color palette. Be picky. Don’t settle unless you have to. Know when to trade things off. Pick your moments and make sure they are magic. Make yourself proud. Make your team proud. Make your mom proud. Don’t leave any doubt that you drove for excellence with every thing you have. Your customers deserve it. Your team deserves it. Your mom deserves it. You deserve it.
Share your insights with everyone. Especially when you’re wrong. Oh God, especially then. Be the Waze of your company: let people know where the cops and the wrecks and the 4 hour traffic delays are. The teammate who shares her experience, experiments, surprises and missteps is 1,000,000 times MORE VALUABLE then the guy who quietly, secretly and inexplicably wins every time. He is a golden goose. and he doesn’t scale. Don’t be a golden goose. But keep in mind that it takes craft and patience to extract the insight from a fiery wreck. Don’t assume others will understand why you failed — or why you succeeded wildly — without a patient, methodical, well-reasoned explanation. Don’t sugar coat or rationalize your mis-steps. Point clearly to the piles of shit you stepped in. Draw us a map and circle that stuff! And even more importantly, if you succeed — relentlessly wonder why. Dig deep. Because it’s not often. So when you strike gold, you study EVERYTHING so you can replicate it again.
And share the credit. With your developers and your product managers and your program managers and your intern and your family. You are part of a complex organism — and it should feel great to be a high functioning organism. And you’ll need them all next time so make them feel appreciated with high-fives and shout-outs and the really big Jamba Juice with an extra shot of wheat grass this time.
What are the design basics you’d add? What are your most common mis-steps? What were your big failure-inspired ahas? And what behaviors have you adopted to execute design at the highest level?