Random header image... Refresh for more!

Effective Qualities of a UX Designer: Respect for Others

One thing designers aren’t often taught in design schools is how to work with and respect the other functional areas that you’ll work with on software. For the most part, the attitude coming out of HCI or related programs is a strong belief in design as being a savior to the rampant problems of bad experience with software (a belief that can easily become arrogance). Once you are out of design school, you will then find blogs that say more of the same, often either writing about ways around constraints and frustrating developers, or touting new methods for how to instill the value of UX into one’s organization. In a way, we are trained to believe that design is everything only to find it can be quite a hard sell in the real world.

I’m not writing this to criticize design schools. In fact, I think this is probably the way it should be. Designers should leave school feeling inspired and ready to take on some of the wickeder problems out there. The problem, I think, really lies in the defensive nature the UX community often takes when confronted with obstacles in corporate and consulting environments. We believe we can change the world, only to find that our designs are hacked by developers or simply ignored by our clients. So we get upset. We blame software developers. We blame product managers. We blame “the corporation.” If we haven’t quit our job to find a company that “gets it”, then we try to find better ways to “sell” our designs. Or change the culture. We try anything to get the other functional areas to understand just how valuable we designers are.

Fundamentally, this “design first” attitude is self-centered.

How often do you think about the needs and motivations of your other functional areas? Unless someone genuinely has it out for you, it’s safe to assume all functional areas working on a product want the same end result: a product that is useful and a pleasure to use and makes money. So why do we act so differently or above other groups? Mostly, I think it is because each area has different incentives that yield different motivations along the way. Software developers, for example, are largely risk managers. They have deadlines just like any of us but they have the ability to actually break the product you’re building. As a result, they will inherently be hesitant towards any changes that they are unsure about. This manifests itself to designers as “scoping out the important stuff” or “being conservative.”

Another example (at least from my experience at Autodesk) comes from Quality Assurance (QA). Their incentive is defect counts (simplified). They are paid to pick apart the product. As a result, you may find them asking very detailed questions about designs–things you may find either inconsequential or downright annoying. They are only doing it so they can do their job better. These are just several examples of the ways different functional areas of a product development team can have a perceived negative effect on your ability as a designer.

Everyone involved in a product has the same end goal but we have different ways of getting there. And while there is nothing wrong with thinking that design can save the world, it’s not the best approach or attitude to take to really be successful. In the above examples, you could increase your chance of items not getting scoped out by planning better and working with developers or software architects earlier on in the process. You could help QA by being aware that the amount of detail they need from your specs may be more than you care about (a nice by-product is that your design will improve).

If my experience over the last 5 years has taught me anything, it’s that lecturing and selling design are easy ways to meet resistance. But respecting and empathizing with the other teams you work with are easy ways to find solutions. Helping others get what they want will help you get what you want.

Respect.

10 comments

1 Kevin Makice { 07.11.11 at 10:20 pm }

I think there is an operational distinction to be made between ‘selling’ and ‘communicating’ in design. The former implies a goal of persuasion and implies there is a right way (the one being presented). The latter, however, is about sharing evidence to explain the logic of decision making and invites others to participate by providing new or counter information.

The flaw of our design program (and probably others like it) is not a failure to communicate. We are prodded continually to seek out, evaluate, critique, and select evidence that provides the most logical path to a good decision. When done well, this evidence is derived from real-world need and leads to more efficient and well-received products. Where we fall short is with the next step: grounding these decisions in the real-world constraints on the execution side of development.

At Indiana, the PRInCiPleS framework sadly shortchanges the “S” for strategy. Grads of the program would be well served to be working with biz schoolers and attending startup weekends, where there are more development realities to face. That was the intent of Eli’s class and the focus on service learning and working with non-profits in the community. Students complained mightily about the struggles in those groups, but those lessons are tied to the conclusion you just made in this post.

2 Christian Beck { 07.11.11 at 11:08 pm }

I wouldn’t disagree with anything you say there. Of course the best opportunity for affecting this change is in school itself. For many of us, that ship has sailed so I was struck to write this as a reminder to practicing designers. There are also aspects that would always be difficult to simulate in school, like defect tracking, changes to design after implementation, and most of all, following design through over the course of several years or releases. So, some of this I suppose is a natural process for designers. I just want to do my part to fight against some of the isolationist movements in UX.

3 Joe Yelochan { 07.12.11 at 9:15 am }

Thank you for writing this. I had no idea that more experienced UX practicioners such as yourself were dealing with the same types of organizational conflicts and struggles that some of us junior practicioners are experiencing. I agree that respect for others is important, and when I work on teams of people with multiple talents, although many times I’m looked upon to be the design lead, the first thing I strive to achieve with my teammates is trust, respect, and I let them know that their opinion is valued and important. If you don’t have the trust of your teammates, then why should you expect to succeed? Design isn’t something that is dominated and dictated by us designers. In fact, I think that service to the client and to our teammates is just as important, if not more so, than what we connoisseurs call good design. Of course we want good design, but I often find myself helping others to identify the constraints and boundaries of a problem we’re facing–together. This is no one man show. If there is no respect and trust in our relationships; of our teammates and our clients, then how are we to serve each other and design for a greater need? Again, thanks for writing this!

4 Drew McKinney { 07.12.11 at 12:05 pm }

Thank you for posting this. I think you’re getting at a deeper problem most creatives in tech face, and that’s 1) getting respect for their craft, be it UX, visual design, engineering or marketing and 2) empathizing with those others that we work with.

Something that designs schools do, as you noted, is to exaggerate UX’s leadership role in the world. Along with this, to some degree, comes developer-bashing and generally negative feelings towards engineering and development. I can’t count the number of times I heard the words “code monkey” used to describe a developer. Design-led or developer-led are just chew toys; great products come when ego is put aside for the sake of the product.

This is why I tend not to work with ego-driven designers or developers. I just won’t do it. They will try to make the project about themself and complicate matters to where the product is no longer the focus.

Re: selling design. I say this all the time, but it has more to do with a designer’s approach to stakeholders and less about working with an team in a project perspective. Part of our jobs as designers is to sell. We are selling the idea of design thinking, a generative process, over more reductive processes of the past. In this same way, great designs must be advocated for, regardless of who made them. A client will often ask you for X, and when you deliver Y you need to be confident about what you did and why. Moreover, strongly advocating for this kind of process over traditional requirements->spec is part of our job. Selling ideas may be just as important as coming up with them, otherwise they might not see the light of day.

5 Jason de Runa { 07.12.11 at 4:55 pm }

Great post! My observations of why designers have this “design first” attitude is because of this mindset that “a piece of their pie” is being taken away by others. That piece of the pie is creativity.

As a designer, I want to reinforce that creativity isn’t ours. I know engineers and product managers who are just as creative and know how to tell a product idea. I even know some people in customer support who constantly hear field complaints have really good ideas to share. Some designers see this as a threat to their role (a naive design perspective), while I see it as an opportunity to be more successful. Refining and polishing that idea with them into something more compelling. In addition to communicating our ideas, it all comes down to execution and I’m sure many of us in corporate cultures have felt (or will eventually face) that successful execution and facilitation is difficult to do in isolation.

6 Christian Beck { 07.12.11 at 8:08 pm }

Thanks for the comments Joe. I don’t know what more senior designers than myself would say but yes, even after 4 years, these issues still exist. And, I’m not really sure that the adoption of UX will necessarily solve those issues alone. This means that this struggle will always exist. And as a new designer like yourself, it’s great to have that attitude from the get-go. I think for myself, it really helped working for a company full of senior developers (many who’ve been at Autodesk for 10+ years). It humbled me in the beginning and I worked hard for respect.

7 Christian Beck { 07.12.11 at 8:14 pm }

Thanks Drew, I think you brought up great points. In fact, you made me remember my feeling that terms like “code monkey” are really quite derogatory and perpetuate that kind of arrogance. My insight really came from this process I worked on with a QA lead. Of all people, I collaborate with a QA lead! From that point on, it kind of tore down my stereotypes and assumptions about the functional areas. We are all working towards the same thing. And, being on a startup product, every QA and Dev has done some design, I’ve done QA and Dev, and so on. Egos and silos were dropped.

Yeah, the whole “selling” thing isn’t quite as bad I wrote it. I hope my point got across but in reality, I guess the issue is really more about how the designer makes the sale. Just like purchasing anything, there are pushy salespeople and ones that listen to your needs first.

8 Christian Beck { 07.12.11 at 8:19 pm }

Thanks Jason. I think you are definitely right that there is an underlying fear our ‘pie’ is getting taken away. What you described is similar to a lot of things I’ve gone through myself. Hell, this post is after 4 years at Autodesk, it’s not to say I always had this perspective! One humbling thing that happened to me was that after I was so sure of something I designed, it turned out to just be wrong after the product was released. Having to backtrack from that with the team was hard while keeping whatever respect I had left as a designer. The turning point, similar to what you said, is that I kind of dropped the “design for design’s sake” attitude and realized everything is about the product. Whether it’s a customer or developer who has the idea there is still plenty for a designer to do in polishing that.

9 Christian Briggs { 07.13.11 at 8:50 am }

Excellent post, Christian!

I think this is an important topic for any of us who are integrating or re-integrating into the business context after a time spent in an academic one.

I read a book a long time ago called “A Little Exercise for Young Theologians” by Helmut Thielicke. I can’t seem to find my copy, so i’ll paraphrase one of his admonitions to recent-graduates of seminary which i think applies to all of us as well:

Theologians spends years packing their heads full of knowledge which exhorts them to love their fellow man. Many of them become so proud about their knowledge, though, that they are far from loving toward those who have not packed their heads full of the same knowledge. This creates a hypocritical condition in which the theologian’s actions go against their knowledge. It also hinders their ability to gain further knowledge from the people who have gained wisdom through their years of lived experience.

I see this same dynamic happen in every discipline. New M.D.’s do it, new M.B.A.’s do it, new designers do it, etc.

I do it too.

I wonder how we can prevent ourselves from doing this, and live up to our responsibility as designers (i think this is our responsibility at least) to better the situation for all of our stakeholders, and not just the person who gets to use our product?

I have recently tried to do more listening for the wisdom from experienced people as one potential remedy. It seems to have helped a bit. Has anyone else tried another method?

10 Nina Mehta { 02.20.13 at 10:17 pm }

YES.

Leave a Comment