Advice for Young Designers (Of Software anyway…)

Not too long ago, some high school students visited the company I work for, TechSmith, to learn about how our mobile teams work. Naturally, this sent my brain spinning, thinking about what tidbits of wisdom I might have to offer a young, developing designer. (If there’s any specks of wisdom to be found in me at all.)

So far, I’ve come up with a few things and thought I’d write ‘em down. I may think of more, but don’t hold me to that. And I may end up disagreeing with all of this in a few years. In fact, I probably will.

Not Being as Good as XYZ Designer

So, you’re browsing around on Dribbble and finding that there are many people out there who are just WAYYY better than you. Some of them might even be your age. Some may even be younger. It may baffle you, but one thing is for sure – you’re not as good as they are.

Well, count yourself lucky! Hold on to that feeling. As long as you can spot someone better than you, it means you can grow. As long as you are seeking out things to aspire to, you’re going to have somewhere to go. Don’t fall into the trap of thinking you’ll never be as good as XYZ. You will be that good if you keep working at it.

Besides, atleast you can tell you aren’t as good as some other designer. Some people are clueless. Those poor souls are doomed. But even worse than being clueless are those who rationalize why being good isn’t actually important. “Oh, impressive graphics aren’t all that they are cracked up to be.” Sometimes that’s actually true. But sometimes that’s just a rationalization from an insecure person who’s given up. Never be that person. If you become that person, you might as well quit.

Get Used to Negative Feedback

Learn to harvest valuable feedback from those around you. Feedback is just as important as great ideas – it’s a designer’s lifeblood. So when someone comes to you and gives it to you straight, count your lucky stars you found someone who is willing to be honest and open. Hold onto those people – their feedback will guide you well.

It’s going to hurt. You’ll want to impress people, you’ll want to be awesome. You aren’t always going to be. That’s OK. Being wrong is a step along the way to being right. Bad ideas are the kindling that light the bonfire of a good idea. Try as hard as you can not to take it personally. Getting negative feedback is vital to your growth.

Most importantly, find the people in your life who are brave enough to tell you the truth. You’ll be surrounded by people who are willing to be nice to you. Being nice is easy. It’s rare that someone cares enough about you or is brave enough to be direct. When you find those people, don’t get angry when they lay out their feedback openly. If you do that, you’re pissing away one of the best resources you’ll ever have.

Bottom line: never become a delicate flower. It’s your job to find value in the people around you. It’s not their job to figure out how to interact with you. You can’t control others, but you can control yourself. Find the gems in the rough and dig down to the meaning of the feedback you are hearing. Figure out how to encourage people to share their thoughts even more openly. The people around you are one of your greatest assets.

If you act overly hurt or defensive when receiving feedback, people won’t share with you as freely. If people aren’t sharing with you, you’re screwed. Whiny, overly sensitive designers hold themselves back and they often hold great teams back. Don’t ever be one.

Stand Up for What You Believe In

Not listening to feedback is a sure way to fail as a designer. However, listening to ALL feedback and caving into every single idea will also lead to poor design. Finding a healthy balance is a hard thing to do. I’ve screwed it up in the past. It took years for me to get to the point where I felt confident enough to make a call on what feedback is actually valuable and which ideas are worth pursuing. Even now, I probably screw it up.

But one way to certainly screw up is to just cave in to all feedback offered. Some ideas are NOT good. Some feedback is NOT valid. You can’t make everyone happy. If you know something is right, trust your gut. Put in the extra effort necessary to defend your idea. Prototype things, mock things up, test things… Don’t discard the ideas of others, but don’t roll over at the first sign of disagreement. If you do that, you’re not designing anything, you’re just pushing pixels.

One way to make sure you are making a good call is to understand why someone is providing feedback. Don’t take feedback at face value or directly interpret it. If they are suggesting a change, make sure you understand the problem they intend to solve or the benefit they are trying to provide. If you have that understanding, you may come up with an even better idea. You may find a way to integrate the value of their idea without compromising your design. Or you may decide that the benefit isn’t actually much benefit. Regardless, you’ll be armed with the value behind the feedback and more able to decide what to do with it.

Be Flexible

A designer that can figure out how to quickly adapt to changing environments is a designer that is always learning and proving their worth. If you require that teams bend to YOUR needs, then you will always be falling behind the world around you. Technology changes, processes change, times change. What worked 5 years ago doesn’t work anymore. The best practices of yesterday are the laughable blunders of tomorrow.

Keep an eye on always producing the best work you can, but learn to bend to the needs of the situation you are facing. One day you may be working in agile, the next in a startup environment, the next in some big crazy complex waterfall process. Good design can happen in any process. Keep an open mind. Besides, you are more than process – don’t ever let process define you. Tools are just tools. A designer is so much more than the sum of their tools and techniques. As long as you are making awesome experiences that customers love, that’s all that matters.

Don’t Put Limits on Yourself

Coding isn’t as hard as you might think. In fact, it can be downright fun. Don’t be afraid to get your hands dirty. Always push yourself to learn new things – every experience is valuable ammo in your problem solving belt.

Should you be able to write code? Yes. Should you be able to make graphics? Yes. Should you be able to do interaction design? Yes. Research? Yes. Why is it that you can be expected to do all these things? Cause you’re a human. You’re the brightest, most adaptable thing on Earth. Don’t underestimate yourself.

Don’t Forget What You’re Here For

You’re a designer. You’re here to make amazing products that people love – things that solve real problems and are crazy desirable. A lot of things go into making products that people love: fixing bugs, testing, research, marketing, development, going to trade shows, talking to customers, etc… Every aspect of software creation is important for you to know and be involved in. Not so that you can control it – but so that you can understand and appreciate it.

But don’t forget what you’re here for. You’re here to make amazing things. This can be surprisingly easy to forget when you are staring at a wall of tasks. At the end of the day, though, you’re not around to check boxes on a task list. Checking those boxes may be important, but you don’t sell your checked list to customers. Customers don’t buy user stories, they buy great software. Never lose sight of your goal and constantly push harder and harder to achieve it. If you don’t, you may just find yourself trapped in a downward spiral of mediocrity.

Your task isn’t complete until your users are absolutely in love with your product and you are unspeakably proud of it. It takes a LOT of time and energy to get there. So keep your eye on that prize.

Make Mistakes Quickly

Don’t be afraid of screwing up. The second you have an idea, share it with someone you respect. Have them throw rocks at it. Break the idea, fast. You’ll find better ideas.

If you think an idea is dumb, say it anyway. Someone else might have the key to unlocking your bright ideas.

Don’t stress about people who judge you for making mistakes. They are either idiots, or playing political positioning games. Life is too short for either.

It’s always easier to spot flaws than it is to create brilliance. It’s easier to have a bad idea than a good one.  So have your bad ideas – and tear them apart. Have people around you tear them apart. Always remember, nothing matters but the final product. It doesn’t matter how many mistakes happened along the way. It doesn’t matter if the final idea was someone else’s. All that matters is that your product is AMAZING. If that’s true, you’ve done your job.

In Conclusion

Those are just some philosophies I consider important… If I think of more, I may write them down. I’m curious what others think, so please chime in. There’s always more than one path to success and finding your own way is vital. But the above philosophies have served me well and turned into core aspects of my life as a designer and human. So, I figured I’d share it out and see how wrong I am.

This is my first attempt at writing a UX centered blog post, but I believe it’s likely long overdue.

Recently, I ran across Dan Willis’ blog, UX Crank, which I immediately fell in love with. Specifically, I was impressed with the relatively recent post of his, Build a Strong UX Foundation. It’s a topic I’ve thought quite a bit on recently, as I’m entering that phase of my career when I’m thinking more and more about how I can help newly christened designers be successful.

I enjoyed how he nodded to the issue of “UX” being a sort of wastebasket diagnosis of a profession, in regards to how our field loosely encompasses just about everything related to design. That inflammatory comment of mine could perhaps lead someone to think I’m dismissing my entire profession, but that couldn’t be further from the truth. Though strongly worded, I must admit, the analogy seems sound. (and yes, I know how dangerous analogies are, let’s not go there…) We, as a group, are continually stumbling around, trying to get a grip on what it is we do, why we need to do it, why people should listen to us, etc… And we can’t resist putting a label on that struggle. I’m not saying that’s a bad thing. I do the same sort of stumbling every week as I figure out how best to fulfill my role in a sea of overlapping disciplines. But despite that continual struggle, I believe we’re coming ever closer to an understanding with blog posts like Dan’s there. Specifically, I have to call out this statement:

Our real value has never been about picking the right template for the right challenge; our value is to fully define a problem from the user experience perspective and then to craft practical solutions that address that problem in specific and measurable ways.

-Dan Willis, UX Crank

This paragraph gets to the core of UX for me. It’s something I’ve personally thought on for some time now, actually. The real value isn’t in picking a template. I would take it further – it’s not about picking a tool or a process. Instead, our value is exactly as Dan says – “to fully define a problem from the user experience perspective.”

I have to admit, I feel a temptation to leave off the “user experience perspective” bit and just focus on the definition of the problem. But doing so would remove what makes us special, what makes us unique. It’s what separates us from product management. We take business goals and needs and focus them through the lens of a user’s needs. And we do this in order to enhance them and increase the likelihood of business success. That’s the “secret sauce” that’s not really all that secret.

But I was tempted to leave all of that out because, frankly, that first part is complicated enough on it’s own! Fully defining a problem is a hard thing to do. And this comes to the topic of my post. (Curse you, verbosity! I shall defeat you another day…)

If fully defining a problem is the foundation of a UX practitioner – which I believe it is – then there’s a very specific aspect to defining a problem that I would call out for any burgeoning designer. And that specific aspect is:

Why?

It’s a simple question and a simple concept, but also one of the easiest concepts to overlook. It’s the most important question to have an answer to, in any undertaking, and the most valuable bit of information to communicate to any team of knowledge workers (which we ALL are). It’s at the very center of our entire profession.

Yes, there are other details of a problem that are important. The regulars: who, what, where, how – those details are all very important. But they are all crushed under the imposing weight of why. Why? Because answering “why?” gives us intent, purpose, meaning… The rest is context. Useful, but greatly diminished without a foundation.

Years ago, a brilliant colleague/designer I work with, Sylvania Dye, first revealed to me the power of understanding why. She introduced various root cause analysis techniques, one of which was the 5 why’s, which was a quaint but wonderful beginning for me in my analytical adventure. I’ve since grown beyond that simple technique, but the essence remains. In any of my undertakings, I simply must have an answer to that question.

The true power of why is that it provides a simple, quick escape from the perils of shallow thinking. I define shallow thinking as any situation where you aren’t being deeply critical of yourself and your activities, not to mention the activities of those around you. For example, perhaps you are only designing solutions to symptoms, focusing more on aesthetic than experience, or simply trying to put lipstick on a pig. In each such scenario, simply asking why can easily break you out of self inflicted doldrums and unearth real design problems worth solving.

But here’s the kicker – asking why isn’t always easy. There’s SO many ways to ask such a simple question. Let’s say you’ve been asked to implement a big circular button. Asking “Why don’t we have a big circular button” isn’t going to get you very far. Asking “Why do users need this button” will. And from there, hell, ask whatever questions you need in order to get to that core WHY. You can be sure that something kicked off the desire for this button and you, as a designer, need to know what it was.

I can guarantee you, if you don’t know why you are implementing that big button, you aren’t going to be able to deliver the best possible solution. And it’s your job, as a UX designer, to really know why. You can’t take things at face value. You can’t make assumptions. You have to do your best to really analyze the problems in front of you and understand why they are problems and why they are worth solving.

To unearth those oft elusive whys, you may have to ask the question quite a lot and ask quite a lot of people. But you have to do it without making people look stupid. That’s vital, because I can also guarantee that someday, someone will ask you that all important question and you’ll respond by smacking your forehead, ashamed that you don’t have an appropriate answer. (Which is fine – when that happens, search deep down in your gut and find the answer. You’ll probably find one. There’s a reason good designers have instinctual reactions/ideas. But be willing to kill your babies if you find out they are just fluff.)

The main point is that it’s NOT the job of a UX designer to just implement what they are asked to implement and make it as shiny as possible. As Alan Cooper frequently points out, users don’t know what they need. Likewise, neither do your teammates in many cases. Hell, I don’t know what I need most of the time! It’s a normal thing. But it’s our job to make sure our team has done that digging, to find real needs, to get to the core of it all. Until we do that, our ability to deliver amazing designs is a crapshoot.

And I’m not saying that asking why is the one tool that will get you there. But I strongly believe it’s the start. And if I could encourage any budding designer to start doing one thing well, it would be both asking and answering that question. (For starters, you could ask “why would it be useful to ask why?”)

Of course, next up, you can ask ask all sorts of other crap. “What problem am I really solving here?” “How far do I need to solve the problem?” “How do I know if I’ve solved it effectively?” etc… But that’s all for another overly wordy blog post…