One day, I saw this tweet come through the twitterverse from one of the most awesome UXers ever, “It’s normal to hate your own work, right?”. I started thinking that it seems like everyone (including yours truly) is questioning their work these days. When I say everyone, I’m talking about the most experienced UXers down to the most novice. So, what’s the deal? Why does it seem like no one is happy, truly happy with what they are designing? And more importantly, why does it seem like the more experience you get, the more you question the work that you do?

There are a ton of problems with any of us questioning our work beyond a certain point. Of course, it is always good to look at your work and think about what might make it better. However, questioning it beyond this point starts to become self destructive. Not only does doing so start to decrease our own confidence because we start to think that we can’t produce quality work, but it can also descrease our willingness to share our ideas and have them critqued. This is one way that we, as designers, create more and better ideas. However if we become too critical of ourselves over time we tend to clam up and not let our ideas shine through.

How, then, do we solve the problem of being too critical of our work? First, we should start by thinking about why those who are at a high experience level are critical of their work, and then we can work down the chain. I would argue that having more experience means you have a wider range of knowledge that you have acquired about a certain topic, in this case UX, over time. Thus, of course you’ll be more critical, because you are judging your work against more factors than you were before you acquired all this knowledge. If we extend that down the chain we can see that the more we “know” the more critical we become. And we can also see that we are critical because of what we know or because we know we don’t know that much yet. Just focusing on the more experienced folk for this solution, how does one stop being self destructive with their criticism? I would say this… write it down.

What I’m talking about here is writing down, recording, sketching the knowledge that you are judging yourself against. For example, if I don’t like the solution I designed due to it not being easy to use then I write that down… Design not easy to use. Ok, now write down all of these things that you doubt about your design. Leave out the “becauses” (i.e. my design is not usable because), and just simply say ‘I don’t think my design is usable’. After you write down all of your doubts about a design, you’ll have yourself a checklist of what to grade your work on. So then go back to all of the attributes you just wrote down and judge your work against them meaning if you do not think your design is usable, then judge it against the characteristics that make a solution easy to you, and see how well or not well your design compares. Now you have a physical representation or ‘grade’ of how good your work is. If it’s not at a good point, make it better. If it is at a good point, show it and get feedback from others. The important part here is not to sit in your anxiety, but to move outside of it so that you can continue to be productive and awesome.

Grading the quality of your work in this way helps you to do several things. First, it will stop you from taking your critisim too far. It will stop you from going over the edge with hating your work and help you see what’s great about your work. It will make you more confident in yourself and what you do, thus enabling you to share any and all ideas in order to receive feedback and iterate. Continuing to iterate on the work brings you more ideas and knowledge which expands your brain even further and makes you even better. At the end of they day, you will start to doubt yourself less, and just see your work for what it is, your best guess at solving the problem, not a physical representation and how good of a person you are. Thereby allowing you to design better and more holistic ideas, and instead of hating our work, making it even more awesome for our users.

In my many conversations about UX, I usually run into people that are looking for advice on how to go from being a fulltime employee to an independent UXer. I love talking about this topic, because it helps me to reflect on how I can get better at being a consultant. However, there is always an underlying theme to the questions that I get, and want to point that theme out here today.

The theme that I see, as I move in and out of these conversations, is that when people ask for advice on how to become a freelancer, what they are really asking is “where and what do I focus on in this vast array of information regarding UX?”. Afterall, in this wide world of information consumption, I would be willing to wager that UX is at the top of both the content consumption as well as content generation lists. We have books, blogs, tweets and more… and all of these things contain information and conversations about how-tos, deliverables, methodologies. With all of this being thrown at us, where do we as UX professionals start?! And worse yet after we have started, how do we know which path is the right path to go down? It can all be so overwhelming and confusing.

Therefore, in order to simplify it all, I’m suggesting we start with learning one thing in order to become not only great independent UXers, but better UXers overall… Process. How many people can say they know the UX/Design process inside and out? Now, I’m not talking about memorizing one person’s or company’s way of getting their work out, I’m talking about the high level conceptual world of the way that we, as UX professionals, bring value. I’m saying that we, first, need to understand why discovery, scoping, design, etc exist. To take it further, we need to understand that we do discovery in part to define the problem, not just so that we can “talk to users” cuz that is the U in UX. We need to understand why we talk to users, and why talking to them at different phases of the project requires different types of activities & questions as well as brings different results. We should be able to access a situation, see the gaps, and know what part(s) of our process we use to fill those gaps.

So how do we learn the Process?There are a couple of different ways. Of course, we know there is a ton of information out there to consume… I would consume as much as you can about different ways to look at the design process. Also, take a look around you at how your leads are leading. What advice are they giving you? Think about how you fit into the project as a whole and what it is you are bringing or could be bringing more of. Get this stuff down pat. But the most important aspect to learning Process? Letting go of the idea that there is a right way to do things. This, is a lie. You must understand that you, as a UX professional, determine the right way for the situation. And by knowing the whys of your Process, you have a conceptual tool kit that allows you define what is ‘right’.

The outcomes of learning the Process and more importantly the whys behind the process are huge. From a consulting perspective you are now in a place where you can truly lead the UX part of a project. You will have the tools you need to listen to each different situation, access what the problem is, and be able to use your process to define and solve the problem. This is what your clients will be looking for you to do. If you want to be more than just a wireframer when you go independent you must remember that as a consultant there is no other UX Lead… it is just you. And therefore the most important thing you can learn is how and why you do your work, and what that means for those you work with. From a fulltime perspective, this is also important because it helps you to gain traction on the project team and become an invaluable member. In both instances it allows UX to begin to move out of the interface only game, and into the problem solving game. And this is where we want to be, a place where we lead by defining & solving the greater problem. Doing so is called creating an experience, and that is what the X in UX is all about.

Follow up to “Designers Are Wimps”

In one of my earlier posts, “Designers Are Wimps”, I wrote about the need for us to start earning the respect that we, as UX Designers, deserve. Currently, we are in a place where other parts of our organizations, as well as our clients, view us simply as a team of resources that will design the interface for the product being built or enhanced. They do not, at least on a large scale, include UX as part of the larger product conversations. This is obviously something we talk about a great deal, and it is something we’ve all been talking about wanting to change.

We’re also aware of the problems with this lack of respect for UX. We know that without it we are unable to “move up” the organizational food chain. The problem is not just that we don’t have “power” but it is more that there isn’t a user advocate sitting at the decision table, and because of this, the company is making unbalanced organizational & product decisions that favor the business or technology, but not the customer. This is a balance that we need to start shifting.

One way to start to be respected, as I mentioned in the previous post, is to start to earn the respect that we want by highlighting our value to the appropriate teams and people. But another way came to me first, from a comment that was made by bada$$ developer/designer Danny Hotea in the article’s comments, and second, as I was partaking in one of my favorite past times… catching up on past episodes of Khloe & Lamar. Yes, that’s right, I’m letting the cat out of the bag… I am a bad TV junkie, and yes, I probably need help. But, that is neither here nor there. I was watching this particular episode, and in it Lamar’s brother-in-law and his best friend were fighting over his attention. (I know this is hard to read, but trust me there is a lesson here) In the closing interview, Lamar acknowledges that he is glad his two friends are learning to respect each other… and then he says something that reminded me of our own situation: “Respect is something that… everybody always wants it, but everybody doesn’t realize that you have to give it.” This quote stopped me in my tracks, because quite frankly this is a point that we don’t always think about. UXers are usually the underdogs in most conversations around features, scope, etc. Thus, we are usually on the defensive about proving our point and advocating for our user. But, just like we have to earn respect, we also have to be sure to give it. That means respecting, recognizing, internalizing and using the viewpoints of our business, marketing, IT, whichever partners. The idea being that by giving others the respect that they hold back from us, there will be no reason for them not to return that same respect, as long as we are coming to these conversations well informed and with good points.

So, the outcome of giving respect is simple, our teams will start to note this and give us more respect in return. Instead of rolling their eyes when we bring up the user’s needs, they will stop and listen to what we have to say a little more each and every time. They will become more like teammates and less like enemies, because if you respect someone, it is harder to tear them down. Therefore, the change starts with you. To get the respect that you as a UXer as well as you as a professional deserves, you must first take a look at how and if you are giving that respect to others. Although this might seem like giving in, it is really being the better professional and better person. Sometimes we have to make these types of compromises if we want to get ourselves heard and get our design solutions out there so they can make the product better for our users.

I know that this topic is one that has been written about before, but in being true to my own advice, I’m going to raise it again here, today. That topic is the importance of having and being prepared with solid rationale for the designs that we create. To explain further what I mean, as designers we create some pretty awesome design solutions for the problems that we help define. We are creatives by nature, and whether we are designing solutions to holistic experiences or to detailed interfaces, we are continuously challenging ourselves to come up with something new and appropriate. These problems include things like “how do we increase page views?”, “how we we increase conversions?”, “how do we get more people to successfully complete this form?” and the list goes on and on. However, what I notice is that some of us are not always designing these solutions based on design knowledge, testing, or due to a combination of user behavior, business need and technical constraint. Instead, some of us go solely with opinion, misled gut feel, or just with what solutions are new and cool at the moment. This type of behavior leaves us with a big problem on our hands.

Let me give you an example of what I mean. Stop me if you’ve heard this one before. A designer walks into a review meeting with their larger project team in which they are showing some new designs that they have worked on all week and that they are sure will be accepted and praised. After looking through the designs, the larger project team begins to throw out questions like “This solution seems to be heavy on the server load, can’t we do instead?” or “These solutions don’t seem focused on increasing our conversion rates, i was thinking that we’d have something more like … why don’t we?”. Not getting the type of praise they expected, the designer becomes frustrated with the team and serves up such answers as “Well is doing it this way… it’s the wave of the future, so I think we should do it this way too” or “Can’t you see how much cleaner the page is? Why would we want to muddy it up?”. In short, the designer loses these arguments and is told to go back to the drawing board. The designer leaves the meeting angry and bitter… basically no one is happy.

However, this outcome could be completely avoided… if only the designer was equipped with solid rationale. Thus, instead of talking solely about the page being cleaner, the design educates the audience on form design, references the materials they’ve read in order to create their solution, and points out the behavior of users and how this solution is best. In response to questions about what the project team thought the design would be, the UXer can break down the problems with or successes of these ideas and how they relate to the rationale they have provided. Whatever the answer, the designer knows from a non-opinion, fact based standpoint why they designed what they have, how this helps the user, maps to business requirements and takes into account technical complexity.

Having and designing with this information brings the conversation to an entirely different level. It allows everyone on the team to talk about solutions and not just opinions. It allows the designer to lead the conversation and to have the most important voice, while making sure they are listening to all others. It gives you, as the designer, points from which to design, instead of that uneasy feeling you get when you walk into your project meetings afraid that your designs will be turned down. You will have all the ammunition you need in order to defend your solutions, or update them based on the conversation. Designing in this way, by looking at why you are making the solutions that you are, also forces you to be a better designer. You will begin to think differently about the solutions you are creating, why you are creating them, and who they benefit. Without rationale, though, it is simply one opinion versus another, and nobody wants that. Opinion based design only leads to erroneous compromises for the people creating the product, and that does nothing for the people that really matter… those using it.