Great User Experience Happen When Design Is Shared Among The Entire Team.
Hi everyone, Kevin here.
Today I would like to discuss an issue I keep confronting in the design realm: design ownership and leadership. These are mainly thoughts on the subject, roughly put together after some recent discussions with colleagues and people from the community. To tackle the issue, let me start with something I always found amazing –and sometimes disturbing: everyone wants to have a say on whatever is being designed. Okay, let’s try to go further than this blank observation which leads to the same old complain designers have.
First, the reality –we have to admit it– is that when there is no “designer” per se, someone else does the job (e.g. the PM, PO, BA, or any product-related person). And yes, despite the increasing interest of more and more companies in design as a competitive advantage, there is plenty of places where there is no designer.
But, is it really a problem? One of the common bias I observe from many designers is to think that we need a designer in everything that is designed. Yet, many products/services are designed without designers participation. Or are they? Does it makes the people behind those products “designers”?
Despite what one would think, having a designer in the team does not increase the chances of success, while, however, design practices do.
Recurring Fallacies And Elitist Point Of View
Some weeks ago I published an article about a study on the Aesthetics-usability effect. I shared it on the usual social media and “design groups” where I occasionally get some kind feedback and interesting comments. A few days later, one comment caught my intention, as a fellow designer, James, wrote this under my post:
James: “35 years of observing the field has taught me that the undying attempts to quantify the complex set of considerations and experienced judgement involved in real (not superficial) design will never succeed.All putting, no driving.”
So, I asked him to develop his reasoning a bit –and he did. Here is the full “exchange” we had:
Me: “Interesting. Can you elaborate a bit more: what’s “real” design? And what’s a successful quantifying of the UX for you?”James: “‘Real design’ is where an experienced designer, educated in the full design spectrum, uses their experienced judgement and intuition (trained and gained by working alongside more experienced designers) to derive embodiment solutions that are elegant, successful but which are not crudely number-driven.
Good experienced designers have the skills to know how to approach a design and make it better, more whole, easier to use and all-around more valuable _and_ elegantly integrated.”
Me: “Well, you seem to oppose designers’ personal experience & skills-set to a verifiable, replicable, and well-proven method, denying, by the way, the actual science behind it (you know: psychology, behaviorism, neuroscience, etc.)… Sorry but beyond the fact that this sounds a bit arrogant and dogmatic, it seems to be contradictory with past and current UX literature.
Tell me, how do you know that your work is actually a success if you don’t measure anything? Using your own personal, subjective, judgment? Waiting for the recognition of the designer community, which is itself biased? Well if so, you miss a real opportunity to anticipate and improve the impact of your work on actual people lives, beyond one’s intrinsic capabilities.
Don’t get me wrong: your judgment will inherently play a role at some point, but this doesn’t mean you have to solely rely on it.
As a reminder, the main point of our work (as UX designers) is to understand and answer users (real people) needs, pains, gains, and expected outcomes in (real) contexts. All of these are measurable and factual criteria and only proper user research (for which usability plays a good part) can give you objective & unbiased insights. For that, you need a verifiable method which works regardless of one’s judgment, intuition, or experience.”
James: “A good designer _is_ a user, a “real people,” not a wonk in a tower, and understands how people look at or use things. And a good designer learns how to assess and address all of those needs in arriving at a design that integrates solutions to those needs (and which can be iteratively refined, but arriving close to the goal). You may think designers need a “verifiable method” but that’s not an objective truth.
There’s a reason that when Steve Jobs returned to Apple in 1998, he turned the “user research labs” into storage rooms.Also, every good design need not conform to nor pass some analytical test. And designers need not test or justify every decision that they make.”
James’ position is symptomatic of an opinion shared by a part of the design community. I often hear it and read it, most of the time as an underlying message, in articles about design, and these rhetorical pseudo-arguments can be found in many designers’ speeches.
Here is my last answer to James, with no response so far.
Me: “‘A good designer is a user’ → Well, it depends. I personally work in a domain where I can hardly be more than an occasional user playing with scrambled or fake content/data, so your argument isn’t an “objective truth” either.But okay, let’s assume you’re right: even tho a designer would be an actual real user of the service/product he is working on (which sounds already highly biased), he would only have a limited understanding of the experience of using it, because he is not representative of the actual audience. A part of the users might be using it in a very specific context, or on a specific device, or with specific constraints which varies between groups of users, etc. It’s without saying all the cognitive bias at play that can significantly affect this all-mighty designer judgment.
And what about this little issue → http://bit.ly/2L7qals
Note that the problem exists regardless of one’s own experience, skills, intuition, or whatever. This is just factual. And if you think that our human cognitive limitations don’t apply to you, you’re probably facing one.
Of course, an experienced designer might acknowledge some of these issues and probably would go talk to real users (a.k.a doing user research?) or do who-knows-what-magical-intuition thing, but still: correlation doesn’t imply causality –meaning this is not because some designers successfully relied only on their intuition that intuition causes success. Either way, without a proper method, the quality of the gathered insights might be compromised…
And please, why do people arguing on “not doing research” always use Steve Jobs as an argument 🤔
First, it’s a myth that Steve Jobs didn’t listen to customers.
Secondly, it’s purely rhetorical and fallacious because:
1) Steve Jobs never did UX research himself, so why would he be more relevant than my granny’s opinion on the matter (see argument from authority).
2) Steve Jobs was not a designer at all (again, argument from authority) –plus, he was not the only guy who participated in the success of Apple, so stop the glorification bias.
3) Steve Jobs judgment can be objectively criticized: he was not right on everything → see here and here. It’s easy to overestimate the successes and underestimate/overlook the failures → fundamental attribution error.
4) Apple –even under Steve Jobs’ reign– didn’t always make successful products → see here and there.
5) Apple is still making some sh*** design decisions! Proof that financial success doesn’t mean everything is fine.
6) I can find tons of companies which are not Apple nor have a “Steve Jobs way” of doing things, yet they are really “successful” while using proper UX methods: i.e. Facebook, Intercom, Monzo Bank, Google, Salesforce, and many more…”
Yeah, I know, I’m really not good at short answers… 😅
Anyway, this idea –that a designer possesses a certain higher knowledge and sophisticated skills learned from a small group of insiders, and presumably enjoys all-mighty powers allowing him to make the right decisions based on his own omniscient judgment and well-trained intuition– is not only outdated and elitist, it makes a lot of harm to the real value of design for companies.
These “lone cowboys” who, without necessarily realizing it, often behave in a way which prevents knowledge to spread, therefore preventing shared understanding to be built. In such a scenario, the team becomes dependent on the “expert” who’s entertaining some sort of obscurantism: a lack of understanding and fear of uncertainty rarely leads to good results.
Don’t aim to be indispensable, aim to be memorable.
You Don’t Own The Design.
Since many years, I consistently see my role –the designer’s role– like a facilitator, an enabler. Let me explain.
My opinion (yes, it’s just my opinion) is based on a simple reasoning elaborated around facts: before building a product or a service, you should first understand your users and their context(s). Furthermore, you want to be able to answer a few questions: what are their mental models, their paradigms? What are the different environments in which the needs occur? What are the expected outcomes? In brief, you want to create an understanding of your users –you’re building knowledge. This is true whatever the product is and whenever you do something, either it is to build a new product from scratch or update an existing one.
But as a designer, you’re probably not the only one who benefits from this understanding/knowledge. In fact, if you really aim to create a great product/service with a great experience for the users, you probably want the Product Manager, the developers, the customer support, and almost anyone working somehow on the product/service to have the same understanding, so that they can take the best decisions at their level.
“Design is a team sport” — Jared Spool
It’s illusory to think that you can –or have to– be involved in every single decision taken (well you can try… wish you good luck!). And let’s face it: you’re not the only one making design decision! When your PM or PO decide to prioritize some features instead of others, when technical constraints drive how developers implement design specifications, they’re all making design decisions.
You’re More Like A Facilitator.
To prevent the endless (and meaningless) quest to control everything, build trust and empowerment instead. Help everyone in your team build the same understanding of the users. Empower them to have a user-centric mindset, to practice UX methods, to “act like designers” –they’re the designers, as much as you are. Then trust them to make good –read well thought and informed– decisions.
“Predictable behavior leads to predictable outcomes”
For this, start not only to embed them in your process but also to participate and practice them. You’re planning some user interviews in the coming week? Some usability testing? A journey mapping or co-creation workshop? Help the team organize and accompany them to perform the activities.
Make the process transparent, understandable, and explicit. All domains have their own jargon, but while it can be understandably useful among a group of practitioners, it can create unnecessary opacity and confusion to others. “Journey Map”, “Co-creation”, “Prototype” –all these seem pretty obvious and explicit, right? Probably for you. But don’t just assume it is, makes it clear.
For each activity, remind your team what’s the purpose, what kind of outcomes are expected, for what means, and what will be the next step. While doing this, I also recommend you to show where does it stand compared to your entire process, so the people can make their own visual representation of it.
Next time you complain about “this guy” being “stupid” because “he does not understand the point of doing something this way”, or complain about your PM not buying into your “improvement” proposal, or a developer not implementing properly your design, ask yourself: did I do all my best to involve them in the process? Did I build a shared understanding of the users’ needs and context?
One thing is certain: people are putting more value on something if they participated in its elaboration. This works for ideas as well.
Designers, stop producing, start empowering!
Thanks for reading!
This article was first published on Design & Critical Thinking.