The Triforce of UX : Part III — Humility
3 Qualities To Seek In Your Next UX Designer
Read Part I here. Read Part II here.
H aving conquered the big bosses Apathy and Indifference to obtain the Triforces of Empathy and Curiosity, at last our hero faces the greatest force of destruction the world has ever known: Pride. If our hero can overcome Pride to at last take hold of the Triforce of Humility, The Triforce of UX will be whole once more...
The Triforce of UX consists of Empathy, Curiosity, and Humility.
In each part of this three-part series I discuss why I believe each of these are the three most important aspects of a good UX Designer, and three questions to ask to discover if the candidate matches these qualities. I’m sure many of you will disagree with me on some or all of these. That’s okay. I understand how you might feel. I’m curious to better understand why you feel that way, and would be humbled by your responses ;-)
PART III: The Triforce of Humility
In The Legend of Zelda, the evil Ganon seeks the Triforce in order to conquer, rule, and destroy. The underdog hero Link must fight incredible odds to defeat Ganon’s minions, find the pieces of the Triforce, and combine them in order to defeat the much-more-powerful foe. One of the things I love most about the Triforce is the fact that it can be wielded by both good and evil. It is a tool. Like most tools in our world, the things wrought thereby are reflections of the tool-holder, not the tool itself. Additionally, if the Triforce is wielded by one out of balance (i.e. prizing one of the pieces over the others) it will grant them some short-term power, then break itself apart and scatter once more.
If the heart of the one who holds the sacred triangle has all three forces in balance, that one will gain the True Force to govern all. But, if that one’s heart is not in balance, the Triforce will separate into three parts...
— Zelda, Ocarina of Time
Over time in the Zelda universe, many people good and evil have searched for the Triforce. But inevitably, most were tainted by the lust for the power promised by its possession.
…yearning for the Triforce soon turned to lust for power, which in turn led to the spilling of blood. Soon the only motive left among those searching for the Triforce was pure greed.
— Gates to the Golden Land
For this reason, in many of the Zelda storylines, Link decides to give up the Triforce once the enemy is defeated, lest he too become corrupted by the power he possesses, and become the very thing he fights against. This is why I posit the pinnacle piece of The Triforce of UX is Humility. The same is true in UX.
When considering a UX candidate, ask yourself some questions:
Does the candidate want to build up others, or themselves? Are they seeking to impose their will, or to establish balance in the team? Do they use their position as a weapon, or a binding agent?
Or, is this another hot-shot MY Experience designer? (A UX Designer without the U is a MyX Designer). Is this person always right? Is it their way or the highway? How do they deal with criticism or critique? What happens when a junior developer tells them their design sucks and she found a better way? Humility in design isn’t new. Google it.
3 Humble Questions For Candidates
1. Tell me about a time when you were wrong. or — Tell me about a time when you failed.
I’ve been here. We all have. Sometimes we get it wrong. It sucks. What you’re looking for here is the introspection — the comprehension to know they’ve made a mistake and the courage to discuss it openly. Are they humble enough to admit that they’ve made a mistake then take action to rectify it? As leaders we don’t want to be alpha-buffalo, our herds following blindly. You need to be able to trust each other and know that when things go awry you’ve built a team that will put out the fire then tell you about it, rather than call you in a panic asking what they should do. The ability to recognize one’s own mistakes is key in design. Only then are we able to subordinate our wills and desires for the greater good of the product.
Is this candidate humble enough to accept they’ve made a mistake? That they’re wrong? How will they react when you tell them they’ve messed up and need to re-do all of their work? Are they able to see the wisdom in others’ opinions and self-introspect? Can they take criticism, learn from it, and use it as a tool for growth into something better than they were before?
Prototype like you know you’re right, test like you know you’re wrong.
There’s a saying based on a line by Robert I. Sutton to “Fight like you know you’re right, listen like you know you’re wrong.” I love it. I’ve heard it extended to UX Design thusly: “Prototype like you know you’re right, test like you know you’re wrong.” Surely there’s a healthy hubris in every designer. There has to be really. How else does someone look at something and say “I can do better than that!” or “Look at this thing I made! Isn’t it lovely!?” There is a lot of one’s self that gets imbued in the things we design — because we think or know we’re doing it right. But when it comes to testing a design with users, stakeholders, and ourselves, without humility the designer will be incapable of discerning what they did right from wrong. What is really working and what is really broken.
The struggle is real. Does this UX candidate have the humility to figure out how to help that user?
Every person you meet knows something you don’t.
— Bill Nye
Confidence is also incredibly important in a designer. They have to stand up in meetings, present, defend, and often fight for what they know is right. All of this requires a bit of pride in one’s work. However, like Zelda said if “…one’s heart is not in balance, the Triforce will separate into three parts…”. Without the balance of humility, a designer eventually stands alone and apart from the team. Empathy is supplanted by Apathy, and Curiosity by Indifference. Every person a designer interacts with has something to teach them. Humility is the key to helping a designer continue learning, and growing, even when they’ve done great things in the past. It’s also the key to binding their teammates together into an elite team capable of designing and building great things. It also takes great confidence to admit when you’re wrong.
2. A developer calls you over to their desk to show you how they implemented your design, but they’ve made some significant changes. What do you do?
If you’ve never been here, too bad. I’ve had the opportunity to work with some great developers. On more than one occasion I’ve had this exact experience. The first time it happened I thought “Oh great, the lazy dev didn’t want to take the time to execute my designs properly, now they’re going to ask me to sign off on their poor excuse for a UI.” In all honesty, sometimes that happens. But when you work with really great people often they’re about to blow your mind. I remember one such case where Jeff “Sharpie” Sharp called me over to his desk. “Now, I didn’t build this the way you designed it. Well actually I did and well, it sucked, so I did it this way instead and I want to show you why it’s better.” (I may be paraphrasing, but I’m pretty sure that’s what he said verbatim :-P) “Okaaaaayyyy…” I said. Then Sharpie proceeded to show me how, when actually implemented, what I’d designed, while valid in the prototype, didn’t function that way in the real world. After playing with it for a bit, he’d figured out a way to fix my design, and came up with a better approach. We walked through the InVision prototype I’d made, then through his approach. Sharpie’s was better. “Wow!” I said, “That’s way better. I like what you did. Let’s stick with that. I think the users will really appreciate that flow.” And we went on with our day.
Other times it went the other way, of course with less senior developers. (Sharpie has the good fortune of never being wrong). I might’ve responded with, “Well, I see why you’d think that. Honestly, that was one of the ways I’d originally solved the problem, but when we tested with users we found these problems with that approach. So I really need you to do it the way it was originally designed. It tested well, and solves these other problems you hadn’t considered in these ways. But I really appreciate that you’re fighting for the user! It’s really important to me that you care about the UX of our product too.”
What you’re seeking in this question is how they react when people move their cheese. Do they freak out? Do they get defensive? Are they inextricably intertwined with their designs, unable to let go? Are they pushovers, bending at the whim of every critique? The latter is not humility, it’s subservience. You absolutely do not want a “Yes-Man” for a designer. There’s a big difference in admitting you’re wrong, and cowing to everyone for fear of offense or antagonism.
True humility is not thinking less of yourself; it is thinking of yourself less.
— C.S. Lewis, Mere Christianity
3. You know you’re right. You have the data and evidence to support your position, but the primary stakeholder just doesn’t like it and wants something else you know is wrong. What do you do?
I have yet to be on a project where everyone agrees about everything. How will this candidate take it when the lack of humility (or sometimes intelligence) in another will adversely affect the project? Is every hill worth dying for to them? Do they pick their battles? How do they decide what’s worth fighting for, and what’s not? Do they have the necessary skills to teach without being condescending? Can they lead from the shadows? How well do they function when the conversation goes crucial?
This is something I really struggle with. I’ve been on a project where the stakeholder insisted on a feature I was convinced was not just frivolous and ultimately not useful, but damaging to the project timeline. But I was so new at the time, I just rolled with it, and put up no resistance (can you say “yes-man?”). Team morale suffered because nobody wanted the feature. It took months to properly implement. I had developers I led who refused to touch it, outright unassigning themselves from related tasks, bugs, and stories. When we finally launched, it was a huge sales talking-point. It helped sell the product like nothing else. That big increase in sales led to our acquisition. People made bank in part because of that silly feature nobody wanted. The stakeholder was right, I was wrong.
More painful though, is when ultimately, you were right, they were wrong, and the project suffered or failed because of it. How will they avoid this situation? How will they handle it when they’ve planted a flag in a hill to die for, fought the good fight and ultimately lost? What happens next?
One of my previous clients and I had a large disagreement on the tone of the language in the application. After researching, studying, and testing competing and related products I felt we needed a light-hearted, warm/fuzzy approach to the language to contrast the cold, hard numbers of the accounting platform. Other products did it to great success. It matched what I know of HCI and could’ve been a great competitive advantage. We designed it. We demoed it. The CEO/Owner hated it. We educated. We held meetings. We preached. He listened. In the end, he still hated it, and wanted the language to be “professional.” We plead. We argued. The gavel fell, and the language was sanitized. I felt defeated. I felt like a failure. I took a step back and looked at the big picture. Interestingly, this was largely the only time in two years I’d failed to convince the client to do it my way. One hill in the mountain range of UX-wins we’d been able to get implemented. The product wouldn’t fail because its language was bland. The client would be okay. I would be okay. In retrospect, I should’ve acquiesced earlier, but my ego got in the way. I was used to the client just following my lead, and the one time our opinions differed, I got defensive. Humility is really, really hard. But this is how we learn, and ultimately grow from good designers to great.
Looking back at our journey, I’m confident that if we can find designers who can effectively Empathize, are Curious to a fault, and Humble enough to know it we’ll be able to build amazing teams capable of innovative, and user-friendly products. Your UX designer is the hub of your product team. They must be willing and able to coexist and flourish among diverse personalities and contrasting, sometimes conflicting goals.
I hope you find value in applying The Triforce of UX when hiring your next UX designer. Might I also suggest we designers and leaders all seek to be a bit more empathetic, curious, and humble. I’d like to end this series with a quote from one of the great creative leaders of our time. I’ve substituted “designer” for “manager/leader”, as I believe his message is applicable to all:
I believe the best [designers] acknowledge and make room for what they do not know — not just because humility is a virtue but because until one adopts that mindset, the most striking breakthroughs cannot occur. I believe that [designers] must loosen the controls, not tighten them. They must accept risk; they must trust the people they work with and strive to clear the path for them; and always, they must pay attention to and engage with anything that creates fear. Moreover, successful [designers] embrace the reality that their models may be wrong or incomplete. Only when we admit what we don’t know can we ever hope to learn it.”
— Ed Catmull, Creativity, Inc.
