Let's talk explicitly about user experience designers’ ownership of design judgment.
As a UX designer, I am happy to lose a thousand arguments over what the UX of the product should be because of other considerations. “Let’s make this compromise to the UX so we can have it ready in time for the Big Trade Show.” I may believe that any number of these decisions that compromise users’ experience in the name of technical convenience, marketing advantage, or whatever are wrong for the product, but that’s okay, balancing all of the competing priorities is not my job. (This is product management’s job, by the way.) Indeed, heaven forbid UX designers always get their way in shaping the product. That would be unbalanced and wrong.
But I hate having an argument over what serves users best. If a PM overrules me saying, “no, the users will like it better if we do X instead,” that is a deep professional insult which is bad for the development process.
That does not mean I don’t want others to bring their UX design ideas to the table. I have proudly stolen UX ideas from programmers and PMs and marketing folks and others countless times. But saying “you’re right, that is better for users” is my call as designer. If judgment about what is the best UX is not located firmly in designers’ hands, that diffusion of authority means spending organizational energy on discussion and persuasion and “spinning” about it, instead of the other hard work and hard decisions which must be done.
I am not claiming designers’ judgment is perfect. We should always implement UX in a spirit of experiment, looking to learn where that judgment was surprisingly right and wrong. But wasting energy second-guessing UX designers is a bad mistake. Even if your designers don’t have superior skill and talent to the rest of your team (which they should!), they are the only ones spending all day every day thinking about their domain. That should mean they can be trusted to be more reliably correct about it. If your designers’ judgment really is weak enough that trusting their judgment is too risky, then the remedy is that you fire them and hire someone else.
On their part, UXDs must be forthright and honest in discussing implications of UX options. UXDs must equip product management with a clear appraisal of what is most important; deciding among compromises to shape the product is PMs’ job. “If we do this to make it easier to build, that's a usability sacrifice on mobile, but users should be understanding about desktop being better for this function.” A UX designer who is a proper professional will not sandbag, saying every little compromise to UX is the end of the world. A sandbagging culture will severely compromise an engineering team — they hate lies and will feel constantly disoriented by it — and it will crush designers, who cannot deliver anything if we cannot tell the truth.
In the long run the ethos I advocate here leads to better UX results. Sure, there will be occasions when other people in the org turn out to have been right when the UXDs were wrong. But most often UXDs will be most right about UXD. Play the odds.
More importantly, when you do not simply accept UXDs’ judgment in their own domain, you have added work for everyone to do. Designers need to persuade everyone on the team that they know what they are talking about, and everyone else bears a burdern of responsibility for evaluating that. It should be UXDs’ responsibility to work to persuade stakeholders that good UX is good for the product; but if they must also work to persuade everyone that their proposals are good UX in the first place, that means time & energy absorbed by that persuasion instead of thinking about better solutions: stakeholder involvement theatre, user research theatre, slick presentations, et cetera.
I don’t want to dismiss UXD communication in this critique of UXD persuasion. Making clear how and why a UXD solution works the way it does is a demanding and important part of the work. This clarity is different from selling.
Nor do I want to blur the distinction between what UXD is right for the product versus what UXD is right for users. What is right for the product is a contentious question, informed by multiple stakeholders, owned by product management. For this to work, UXDs must confer with and serve the team, and must recognize that since the UX is the product, product managers decide what UX to build.
UXDs must own the narrower question of what is right for users. It is not just because it is insulting and demoralizing to present design work that took a few weeks of skullsweat to prepare and have someone look at it for ten minutes and say blithely, “No, we are going to do it another way because I have an idea which I am sure is better for users”; I would counsel that designers swallow their pride and roll with having their expertise disrespected if I thought it was better for users or better for product success. But it isn’t. Designers serve the organization when they demand their ownership of design judgment.
UX designers must advocate for clarity about this distinction between UXD judgment about users’ needs versus UXD decisions about what serves the product as a whole. We must own the first thing, and advocate vigorously for product managers owning the call about what UX actually gets built into the product.
Examples
After the initial thread, I added references to commentaries by others which I found topically relevant.
Amen, and that goes for all roles in a product team. I’ve experienced the best teamwork when each member's ownership and authority of their domain is respected by the others (and everyone understands that this doesn't mean always getting your way).
Yes! It astonishes me how often people read me as arrogating some kind of godlike wisdom and power to designers when I am advocating for nothing more than giving every role in the team ownership of their appropriate domain. Nor am I advocating designers isolating themselves from the rest of the team; I am advocating deep engagement with an expectation of professional respect.
Pavel Samsonov, one of my favorite design commentators, has a great comment about why I harp so often on the distinction between designers’ ownership of design judgment and PMs’ ownership of product design:
Expanding a design org always threatens incumbent power centers. People unfamiliar with how design works will defend their own authority and ways of knowing.
For this reason, it’s important to explain not only what you want the design org to do, but also what it will not do.
“Design is making decisions” is confusing to stakeholders who see it as a power grab from the picture-drawing people. Unless you have the power of a huge consultancy behind you, you probably won’t be able to convince them that they have been designers all along.
Designers are no more CEOs than PMs are. When jockeying for the “seat at the table” it’s crucial to show that you’re not taking over the entire table. Even though UX is affected by everything from backend tech to the business model, a tight initial focus will be an easier sell.
Erika Hall of Mule Design, another designer I greatly admire, observation about resistance to the role clarity I advocate:
One of the snags is that explicitly defining roles and responsibilities can be very uncomfortable to guess culture people in the relevant domain. Being able to guess is often seen as a proxy for care, concern, and expertise in that domain/membership in group.
Scott Berkun, whose book How Design Makes The World I vigorously recommend as an introduction to What Design Is, offers a good description of my point about the distinction between UXDs’ and PMs’ roles.
Product managers confuse revenue with design quality. Product designers confuse design quality with success.Asked another way: Can the marketplace really decide what is the best design for something? We assume yes, but forget how many factors impact popularity that are unrelated to quality: marketing, hype trends, timing, biz partnerships and more.
(And I must note that revenue is not the only product success target: clearly naming what “success” you want is executives’ job!)
Berkun also has a good meditation on the pragmatics of designers needing to communicate to non-design colleagues persuasively about our work and our role, and our frustration at how much of that we must do. We must live in the world we have while we work for a better one.
Designers are hired to change things. The challenge is we want change on our terms, using our methods and beliefs. This creates a natural conflict with coworkers and executives. It makes sense that designers feel ignored, misunderstood or even lost.
Miriam Isaac observes how designers often confuse their correct frustration at having their design judgment dismissed by the organization with a need to get positioned to control product decisions:
Sorry to tell you this my dear designer, but becoming a product manager will not solve your problems.
Most designers think if only they became a PM they would finally be able to design in the way they see fit!! But in actuality, it will take them away from the craft they dearly love.
They may just need mentoring in articulating design decisions and how to lead / advocate for design in their company. Most designers think if only they became a PM they would finally be able to design in the way they see fit!! But in actuality, it will take them away from the craft they dearly love.
Shreyas Doshi has a few tweets about what UXD expertise entails.
While scrolling Twitter it’s easy to forget that a typical product team makes 100s of micro-decisions about the user experience & trade-offs. It is impossible to validate every one of these with user research, metrics & tactics. That is why Product Sense is such a vital skill.
Product Sense = Cognitive Empathy + Domain Expertise + Creativity
Domain Expertise arises from hardwork, interest, general IQ, openness, and experience. Experience is a major factor there.
Experience plays a role in Cognitive Empathy & Creativity, but it is a much smaller role.
I believe every product person can (and should) get much better at Product Sense, and every product person can get very good at Product Sense. Though to be really great (say top 5%), the innate factors are critical. Just like not everyone can be a great artist, musician, etc.
Looking at replies to it, I find it heartbreaking to see so many people not only unable to imagine having their professional expertise respected, but unable to conceive of it as a possibility.
This tweet from a good thread by Louie Bacaj offers a deeply frustrating framing of a good point:
As a software engineer, you are not there to take requirements blindly. You are there to partner with your business and product partners. That means you have to earn an equal seat at the table on product decisions.
A software development professional should not have to “earn” a seat at the product definition table; respect should come with the job. And roles at that table are not simply equal; they have different authority and responsibility.
Matt Murray makes a tragic observation about energy wasted on justifying one's professional expertise.
Yeah, one day it hit me — I’m an outside consultant. The person who got the funding to bring me in must have made a successful case for the value. So why is most of this project just decking up my reason for being here?
The inspiration
The thread which became this post was inspired by discussion emerging from another tweet, me saying:
When you say “everyone on the team is responsible for X” I hear “nobody on the team has ownership of X” and “expertise in X is not valued”
Patrick Sauerwein replied:
Misinterpreted, the world is not black and white. It’s shared ownership and responsibility and everybody should take care of this. And this doesn't mean that expertise in X is not valued.
I responded:
People say that. In my experience, it is generally not true.
Sauerwein replied:
Sad to hear. The best example I heard is with code ownership which is a shared responsibility for those who have the expertise to contribute. So why should writing code not be valued?
I responded:
The example in my mind is UX design. As a professional UX designer, it usually means that since “everyone” has “responsibility” for it I am just one vote at the big round table.
Sauerwein replied:
You’re the leading “dev” expert in the team with the best experience. Don’t interpret that hard, as mentioned it’s not black or white. Go and lead the team in UX, your role is very important to the team and it’s outcome. Educate, consult and lead UX.
I responded:
My point is that I end up spending a lot of time and energy at those big round tables persuading others that my design judgment is good. That is a waste of attention that should go to me actually solving design problems.
Henrik Johansson <@dahankzter> replied to that:
What if there are other experts as well? Often there isn't just one expert per area
Which Sauerwein underlined with:
Might be the case, in our discussion there is one expert not heard and valued. Challenge in UX: everyone has an opinion. Leading and fighting for your way is hard work.
And Johansson built on that:
I agree that fighting for your idea is hard sometimes but if no one ever challenge the status quo there will be little evolution. UX is special just because everyone knows a lot in the sense that we all use a lot of software. Maybe authority is good here.
I responded:
I am wary of the suggestion that “everyone knows a lot about UXD”. Many people think they do. But people who are not specialists typically have terrible judgment, which is why so many things have bad UX!
Johansson replied to that:
But UX is connected to visual design and thus taste. If a stakeholder doesn't like it esthetically it doesn't matter if it's sound UX. This applies to everyone on and off the team which is why communicating the general idea, architecture if you will, so that understanding exists
I said:
I could not disagree more. If you think UX design concerns “taste”, I conclude that you do not understand UX design.
Johansson replied:
Ah come on! A useable feature is often also a beautiful feature and that even before considering pure design elements. Saying that UX is completely orthogonal to taste is just plain wrong.
I commented
Saying that UXD is not a matter of taste is not saying that it should not be beautiful.
Johansson replied:
And beauty is in the proverbial eye of the beholder and thus taste.
Frustration with that exchange spawned the main thread which became this post.
I am proud that Marcel van Remmerden, Gitlab’s Senior Manager of Product Design says that this framing of UXDs’ ownership of design judgment is “so powerful and clear that we added a section in the GitLab UX handbook” referencing it:
As Product Designers, we are the owners of design judgment.
We start with a problem to solve and always first consider what the best experience for the user would be.
If we get additional information about constraints or context from counterparts (e.g. technical considerations or a marketing advantage), we take that as input and evaluate together if and how we need to adapt our designs. When these constraints have influenced our design proposal, we communicate proactively about the fact that these constraints exist, how they changed the design, and what impact these changes will have on the user.
If our counterparts have a different opinion on what will serve the user best, we evaluate if that's correct and how it will change our design, but we are empowered to make the final call on this question, as we are the owners of design judgment.
Identifying UX needs to aid Product Management prioritization
To support the Product Management team with their prioritization, we give them our input for UX needs. This could be both for quick wins, as well as for larger strategic initiatives.
No comments:
Post a Comment