Creating Your Personal Mission Statement

Written by: Louis Rosenfeld

You’re weird. In a good way, but weird nonetheless.

Weird in the sense that people outside of work likely have absolutely no clue what it is you do. Maybe many at work as well.

For me, this weirdness manifests itself at parties. Inevitably, a new acquaintance asks me what I do. Beads of sweat form on my forehead. My eyes dart around, desperately seeking my far more articulate wife, Mary Jean. I find her, ask her to explain me, and flee.

If you’re in UX or a related field, congrats: You probably have more work than you can manage in a time when many people are underemployed. But that doesn’t diminish the discomfort those weird moments cause.

How might we explain ourselves better?

I created a simple exercise to help create personal mission statements—something short and meaningful to say about yourself—with some help and encouragement from Christina Wodtke and Anders Ramsay. It’s fun, simple, and quick; in fact, I recently tried it out with a group at the Re:Design conference and it seemed to work well. Here’s what to do.

Start with a context.

It could be public, like something to include on your business card, your Twitter bio, or blurt out at those nerve-wracking parties. Or something private, like a statement you write down and keep in your wallet for you and you only.

Tell your story.

Find a friend or colleague—someone you don’t mind being a bit vulnerable with—who will take notes while encouraging you to talk about yourself and what’s important to you. Ten minutes is plenty.

Basic questions like these can get you going:

  • What kind of change would you like to be part of?
  • What’s your superpower?
  • What’s the difference between what you’re expected to do and what you want to do with your life?
  • What has always pissed you off?

Craft a short statement.

Together, take those key terms and phrases from the notes and work them into something that fits the context you chose. Easier said than done, so plan to iterate.

At Re:Design, I was the guinea pig. My context was finding a new Twitter bio to replace this one:

Founder of Rosenfeld Media and veritable UX action hero.

“UX action hero” is an inside joke: pointless for 99.99% of the people who encounter my bio. Time to axe it.

I started with the “What has always pissed you off” question, and told my session’s attendees a story of 20+ years of frustration with the traditional business models (and their defenders) that I’ve encountered in higher ed, consulting, publishing, and professional associations. Telling one’s “true story” is never easy—especially in front of 70 people—but two things really helped:

  1. The floor is yours. Whether you’re telling your story to one person or 70, it’s your time. Take as much of the ten minutes as you wish, and make it clear that there will be opportunities to discuss your story and brainstorm after you’re done.
  2. Vulnerability is engaging. The goal isn’t to impress anyone with a slick presentation of your many fine attributes; rather, use this opportunity to begin figuring out what you’re about. Your stumbles and your quirky, imperfect, unfinished story will actually draw in your partner(s). If they have an ounce of empathy and interest in you, they’ll be able and eager to help brainstorm ideas about who you really are.

My group was anxious to brainstorm before I was even done telling my story. They came up with these options:

  • Happy but not satisfied
  • Re-architect/Assassin of business models since 1965
  • Shapeshifter
  • Internet sherpa
  • Learning by teaching
  • Step, pivot, repeat

My faves are the second and the last one especially, as verbs (like “step, pivot, repeat”) are fairly constant when it comes to describing how we live and what we do. And if I wasn’t happy with any of these, repeating the exercise with someone else would have made sense—after all, it takes less than a half hour. In fact, I’m considering repeating it as often as I get the urge—maybe once per year.

In any case, here’s my new Twitter bio:

Founder of Rosenfeld Media. Slayer of traditional business models. Step, pivot, repeat.

And here are shiny new Twitter bios from some of the session’s attendees:

helping people be less afraid of making things better

…and…

Persuade. Connect. Convince. Judging user experiences everywhere.

Though I’m not sure which questions got each of them started, I am sure they were excited. In fact, they were anxious to share their new personal mission statements with the group.

They found it fun, simple, and quick. I hope you will too.

Information Architecture’s Teenage Dilemma

Written by: Jeff Pass

Imagine if you will information architecture as a pimply-faced, malcontent teenager.  IA is eager to express and redefine itself. It wants to be an individual yet accepted by its peers. It is simultaneously aggravated and apathetic about its parents, mentors, and role-models. It is a bit of a mess, but a wonderful, beautiful mess with endless opportunity and potential.

The IA Summit (and information architecture) enters adolescence

The first IA Summit was held April 8-9, 2000, in Boston, MA, and was titled Defining Information Architecture. Now, fast forward to this year’s 13th IA Summit held April 3-7 in Baltimore, MD, in which the Summit entered the awkward teen years against the slogan “Observe Build Share Repeat.”

Taking the slogan to heart, a number of Summit workshops, sessions, keynotes, and discussions focused on reframing information architecture as a practice and as a field. Granted, IA is closer to 40 in chronological age (many date back to Richard Saul Wurman’s 1976 declaration “I am an Information Architect,” though personally I subscribe to Andrea Resmini’s Brief History timeline), but it is also experiencing adolescence thanks to a rapidly transforming digital landscape that makes puberty seem pretty innocuous. Consider, for example, the proliferation of:

  • Big data and open machine readable datasets (e.g. DATA.gov, and AWS Public Data Sets)
  • Content syndication, especially approaches like COPE (Create Once Publish Everywhere)
    • Plus increased use (and occasionally understanding) of taxonomies and metadata
  • Free and open-source:
    • Blogging and content management systems like WordPress
    • Content management frameworks like Drupal
    • Design tools like Twitter Bootstrap and hosting services like GitHub
  • HTML 5 and CSS3 with their improved capabilities especially around design and media
  • Mobile devices and technologies
  • Responsive web design in its various approaches and permutations

Like a teen whose body is changing faster than it realizes, so too is information architecture stretching and growing and developing. But information architects (at least most of them) have gone through puberty and should be able to adapt their practice and usher their field through this tectonic change.

Remaking information architecture

Coming of age is always difficult. It requires patience and introspection. It is uncomfortable, unpleasant, awkward, and is in many ways unending. But, it offers a unique opportunity to remake and improve information architecture in the face of change and to prepare for the next tools, technologies, and even modalities altering both the digital and physical landscapes.

This means making hard choices and invariably suffering missteps and setbacks. But when the IA community comes through it, it’ll be older and wiser with a better understanding and control of its body (the practice and field of information architecture). Then IA can start realizing the unmet potential of its youth. So what is the path ahead?

Define information architecture not as a concept, but as a practice and a field

For me, the highlight of the 2013 IA Summit occurred before the opening keynote. It was the pre-conference workshop, Academics and Practitioners Round Table: Reframing Information Architecture, moderated by current Information Architecture Institute president Andrea Resmini. The all-day session consisted of 30+ information architects working to identify the requirements that would lay the foundation for a common language, grammar, and poetics for IA.

While the proceedings of the workshop will be published in the Journal of Information Architecture, the real work will begin when the larger community comes together to define and formalize itself. This necessarily includes:

  • Defining what is and is not information architecture
  • Identifying and documenting the major IA schools of thought
  • Mapping out and understanding how IA relates to sibling (such as usability, information design), parent (such as architecture, library science) and extended-family (such as psychology, linguistics) fields
  • Agreeing on a basic timeline for information architecture’s intellectual history, including formative events that pre-date the emergence of the field as well as key technological and cultural events that shaped it
  • Codifying information architecture best practices and developing standards around key artifacts
  • Formalizing the requisite background, training, skills, and certifications for practitioners and then defining the various roles within IA, noting which overlap with other fields and how

Here it should be noted that individual IA practitioners, organizations, and programs have made strides in addressing the above. But until there is a confluence from across the information architecture community, these will be little more than outposts in the wild and may even promote schisms within the community.

Accepting some basic truths about the practice of information architecture

The larger discussion around remaking information architecture also includes coming to consensus around some important concepts that every information architect needs to understand. These are discussed in my April 17, 2013, Aquilent (my employer) blog post 2013 IA Summit Themes but are summarized here:

  • You cannot control device usage. Device usage will change and evolve faster than we can keep up, and it is a fool’s errand trying to predict or determine how users access content.
  • You cannot control content. Syndication and content reuse ensure that content takes on a life of its own, so it’s essential to understand and leverage taxonomy and metadata.
  • You cannot control meaning. It is not inherent or discrete and can’t be turned on and off; information architects can only share meaning and should consider a meaning-first approach.
  • To serve the users you must serve the content. Understand and leverage syndication, promote content longevity and usefulness, and consider targeted, accidental, and future audiences.
  • Sometimes you’re the architect, but often you’re the builder. We cannot always do dramatic and innovative work, but remember, the best information architecture is invisible.

There are, of course, many other concepts that are essential to the practice and field of information architecture will be identified and defined as its adolescence continues.

The time is now…

With the IA Summit turning 13 and information architecture in a time of adolescent turmoil and transformation, it seems clear that the timing is right to define and formalize both the practice and field of information architecture.

Heading into the 2014 IA Summit, members of the community need to open their minds and roll up their sleeves for the difficult, awkward, and emotional work ahead. And they should do so knowing that once information architecture enters its adulthood, it will open up new world of influence and opportunity.

Put another way – and paraphrasing B&A founder Christina Wodtke – be bold, take risks, and fail spectacularly. Now is the time to clearly define and state the communities’ vision for information architecture then set out to realize it.

Are You Going Soft?

Written by: Kevin Jeong

When was the last time you read your resume?

Go ahead and give it a look. Read your last job description. It’s impressive, right? Chances are, you emphasize your accomplishments, your ability to create stunning deliverables, and your extensive knowledge of the user experience practice.

Now, think back to your last project. But, ignore the deliverables and design ideas. Forget the budgets and timelines. What are you left with? Aside from a handful of sharpies and post-its, you’re left with the daily conversations and experiences you had with your team. What were they? Did you have to persuade somebody to see your point of view? Was there frustration, misunderstanding, or even a heated argument? Or, did things just “click” and everybody worked in harmony right from the start?

Most of us never stop to wonder why certain projects flow effortlessly while others feel like we’ve entered into a cage match. The truth is that most of us ignore the very stuff that determines if our human interactions are a success or a failure. Most of us ignore soft skills.

What are soft skills?

Everybody has his or her own definition. Some people call them “social skills”; a popular movie scene shows a man humorously screaming, “I’ve got people skills!” at his interviewer, and there are countless books on the subject. I define soft skills as the interpersonal abilities and sensibilities we gain during our journey from children into social adults.

Whatever label you prefer, taking a look at what soft skills are and how you apply them can have a huge impact on your work performance. This holds especially true for us in the UX field where we constantly strive to redefine boundaries, achieve consensus, and persuade others to see our point of view. The road isn’t always smooth, or even paved, and it’s our soft skills that will get us to our destination.

Soft skills applied

Let’s look at three scenarios where soft skills are put to the test. Whether these scenarios are familiar to you or not, ask yourself what you would do in each situation. Ask yourself how you would apply your soft skills and what result they might achieve.

Scenario 1: You say tomato, I say UX.

It’s 12:10PM, and the rumble in your stomach confirms that it is indeed lunchtime. Instead of waiting for your favorite noodle dish to be served, you are waiting in the conference room wishing your pencil were an appetizer.

Finally, the door bursts open and Don, the marketing manager, enters the room. “Hey sorry to keep you waiting! I was chatting with Susan about my landing page, and she was saying how busy you guys are! Thanks for taking the time to meet with me about this UI stuff.”

Did he really say “UI”? Okay, it’s an honest mistake. You decide to return the smile and politely respond, “It’s actually user experience, or UX. There’s a separate group handling UI design.”

He pauses a beat and shrugs his shoulders, “Hey – UX, UI, it’s all the same, right? Now, I was thinking about my landing page design last night and I made some sketches. I know you are probably a wizard at Photoshop, so try not to laugh…”

What would you do?

Option 1: Put him in his place.

You respond, “First of all, UX is not the same as UI. I design experiences, not just interfaces. Secondly, there’s a lot of thinking that goes into it that you are unaware of. I start with something called discovery…”

Outcome: You may have succeeded in educating him on what you do, but you did it in such a way as to leave him few options but to be offended or embarrassed. Regardless of what he says next, Don won’t be coming back to you with the same openness and enthusiasm as he did today. Chances are, he might be asking your boss for somebody else who is “easier to work with.”

Option 2: Respect and be respected.

You smile and say, “Don, you know how your job as the marketing manager involves creating these great strategy plans for the year and outlining each campaign to make sure it aligns with a goal? Well, user experience is similar in that we look at the objectives for a project and strategize on how best to design the system to match those needs. UX…”

Outcome: You’ve avoided bruising Don’s ego by sidestepping the fact he doesn’t know what UX is. You show respect by stating the value of his role and you speak his language by drawing parallels with your own. By pivoting from a head-on posture to side-by-side, you have a much better chance of him accepting what you have to say and forming a new partnership.

Scenario 2: I don’t buy it.

It’s Wednesday morning and you’re ready to present your wireframes. You flip through your presentation even though you know it like the back of your hand. Your diagrams are polished, but not too high fidelity. Your annotations are thorough but concise enough to be digestible. You’ve memorized the talking points and are anxious to present the design to the entire team.

You begin smoothly enough by thanking people for their time and quickly settle into your regular cadence. The butterflies in your stomach perk up as you talk about the ever-contentious homepage redesign. People begin to nod in agreement with your strategy and you sigh in relief since the hard part is nearly over. You pick up the pace and mention the new slider design and how it can handle multiple business priorities. Suddenly, you notice a frown on the CEO’s face and your throat dries like a towel. Here it comes.

“I don’t like sliders. Get rid of them,” says the CEO.

Just like that, your presentation grinds to a halt and all eyes are on you. Even the butterflies want to know what you’ll say next.

Option 1: Dig in.

You fold your arms and say, “Well, I think the slider is the best way to go.”

Outcome: Besides the soundtrack from a spaghetti western, this head-to-head approach yields both a winner and loser. And since it’s the CEO you’re facing, the end credits will reveal you were the latter. You want to avoid win-lose scenarios as much as possible because not only will they undermine somebody’s credibility, they promote a culture that values strength over merit.

Option 2: Just the facts.

You adjust your glasses and respond, “Well, I did try different options but this one seems to be the best fit for our users. People are accustomed to using sliders in our other app and analytics shows they actually look at all of the messages before exploring.”

Outcome: The best way to deal with emotional arguments is by sidestepping the emotion. You can’t rationalize somebody out of a personal design preference. So, defer to the facts of the design. Make it about the users and business goals, not you. You are not your design.

Option 3: Turn the critic into the collaborator.

You nod and reply, “Yeah, the slider is a tricky element on this page. I explored a lot of other options but I’m open to new ideas. Let me walk you through my thinking and maybe you will see something I didn’t.”

Outcome: It’s far easier to criticize a design than it is to create a solution. Engaging people in the design process will let you be seen as a person who wants to make the work great, not someone who craves credit for every decision. Plus, by drafting critics into becoming problem solvers, you minimize on the amount of unconstructive noise without risking confrontation.

Scenario 3: There’s a storm brewing and it’s going to be a doozy.

“I don’t care about rational arguments and I don’t want to talk analytics. I don’t care what you say. I want it designed this way and that’s the way it’s going to be!”

I couldn’t believe I heard these very words during an internal design review. What started out as a simple discussion quickly escalated into a heated debate. Well, only one of us was heated, but we were clearly both debating. Unfortunately for me, he was the project owner.

Conflict is inevitable. People go to war, they fight in court, and there are small disagreements between people all the time. When faced with conflict, think about your options. There’s more than the fight-or-flight response.

Here are your options when dealing with conflict:

  1. Flight. Someone might be having a bad day and are looking for a confrontation. If you think it’s best to avoid it altogether, do so. There is no shame in knowing when to pick your battles.
  2. Fight. If you think you are in the right and don’t mind making it clear that you are to be the winner and they are to be the loser of an argument, fighting for your position is what you want to do. Just be mindful of the potential repercussions.
  3. Give in. When push comes to shove and you don’t have a solid position, you will falter. Giving in is one way to quickly end a conflict and please the other party.
  4. Ask for help. Some situations are too difficult to face ourselves, so we call in somebody bigger and stronger to do it for us. That’s how it works on the playground anyway. In the office, we can call on our boss to handle things beyond our capability.
  5. Compromise. While it sounds like a good thing that a mutual agreement has been reached, compromise is never satisfying. Neither party gets what they truly want. And, the compromise looks a bit like design-by-committee, which always looks ugly to everybody not on the committee.
  6. Consensus. This is the holy grail of conflict resolution. You work through the material and everybody agrees the solution is a “win.”

Reading these scenarios and carefully choosing your option is a bit like living with telepathic abilities. Many times, we make choices in the heat of the moment based on our emotions, our instincts, or honestly the need to be “right.” I suggest we take a page from our own design playbook and first begin with exercising empathy. Even when you don’t know the “right” answer, thinking about what the other person is experiencing will make it far easier for you to decide how to react and have the best outcome.

What about you?

As your resume grows and you travel further down your career path, your may find yourself relying on your soft skills more and more. I’m of the mind that one’s work is never finished. In practice, there is no perfect. And, even the smoothest and most charismatic of us can use a little work. Here are three steps to getting on the path to improving your soft skills.

Step 1: List your work activities that require soft skills. For example, let’s say your list includes “Give presentations.”

Now, imagine the best presentation you’ve ever seen. Maybe it was watching a Ted Talk, your CEO, or even a colleague who works in the next office. We’ll define that performance a “10.” Now, list what skill level you think you need in order to do your job well and be satisfied.

Soft Skill Activities Required Skill Level (1-10)
Give presentations 8

Step 2: Write down your current skill level in another column. This takes some honest self-reflection. And remember, cheating only hurts the cheater. Unless you are delusional, in which case, I say go for it.

In this example, maybe you feel nervous and freeze up during presentations. Or maybe you lack the ability to go “off script” and exude the confidence and charisma you saw in your CEO. But, you still get your point across and nobody really complains. So, you think you’re about a “5.”

Soft Skill Activities Required Skill Level (1-10) Current Skill Level
Give presentations 8 5

Step 3: You knew the gap analysis was coming up next, right? Well, calculate the gap between what you need to be at and your current skill level.

Soft Skill Activities Required Skill Level (1-10) Current Skill Level Gap
Give presentations 8 5 3

What do we do when we see a gap? No, we don’t go shopping. We bridge it. Here are the bricks:

Make a Plan to Better Presentations

  • Brainstorm and talk to colleagues on how they honed their skills.
  • Look for speaking opportunities and practice religiously.
  • Join Toastmasters and refine your speeches along with your listening skills.
  • Try an improv class to boost charisma and trust in yourself.

Whatever the soft skill you are looking to improve, don’t forget it takes both learning and practice. Be creative and most important, approach soft skill development with the same tenacity you do with the hard skills we hone everyday.

Level up

Developing your soft skills will yield improvements both in yourself and your relationships with others. Contentious meetings will run smoother, your opinions will be heard (and valued) more often, and you will win the employee of the month award. Okay, the award might be a stretch, but others will recognize you for your ability to handle difficult situations and influence outcomes. And best of all, you will be doing it in a way that feels natural.

Take a look at your resume again. What is the next job description you will be writing? For many of us, the UX path can wind from practitioner to leader. The transition can happen slowly, but as your responsibilities and leadership duties grow, so will your reliance on the soft skills you have developed.

Soft skills are the leader’s hard skills.

A Perfection of Means and a Confusion of Aims

Written by: Abby Covert

“A perfection of means, and confusion of aims, seems to be our main problem” – Albert Einstein

My work involves helping people to understand how to best plan circumstances in which users are engaged and satisfied with their experience. Yet, I do not call myself a user experience designer.

I am an information architect. I work on clarifying information and the structure it should take to best enable understanding. I create maps, controlled vocabularies, diagrams, flows, hierarchies, and statements of truth to facilitate groups towards a goal. I do my own research. I use interviewing, contextual inquiry, and usability testing most often.

  • I am not an interaction designer. I do not explore, define, and refine the interactions that a user has with an interface and/or service.
  • I do not code, or render what a user will actually “see” through visual design.
  • I am not a content strategist. I do not extend structures and derive templates in order to propose governance and process flow for the creation of new information and the retiring of old.
  • I have done all of the above at one time or another.

I don’t think it is worth arguing about whether you can or should have a job in which you do all of these things. But I fear that the widespread adoption of “User Experience” has had adverse effects on the clarity of our process. It has made concepts like information architecture, content strategy and interaction design harder to explain, to teach and ultimately to learn about. In my humble opinion this umbrella is obscuring others’ view of our reality.

Our hindsight is clear, but our foresight is clouded

I am afraid that there is a shortage of specialist jobs, and it isn’t because those specialities aren’t needed. I believe it is because the value of those specialities, and the impact of not considering each carefully, is in too many cases not clearly called out to our clients and partners.

A simple test of this is asking, “If a UX fails, which part is to blame?” Is it a problem with the information architecture? The interaction design? Or maybe the content strategy? Maybe it is indeed all three or none of those three. Maybe it was badly produced or written? Maybe it has technical issues? Maybe the branding is off or the marketing didn’t drive the right people to do the right thing?

In picking apart an experience, the differentiation of terms suddenly offers tremendous value of focus. In focusing on a specialty we don’t need to throw the baby out with the bathwater. We suddenly have lots of dials to play with in formulation of a strategy for improvement.

Our process is being reduced

In my experience when “UX” is the term sold-in, the resulting project plans are less likely to reflect the points at which various specialities will be relied upon to progress the team. Often prescribing a stacked to the gills list of tasks reduced to the nebulous “Design the User Experience” on the Gantt chart. The makers of these types of plans leave it to “UX Designers” to divide the time they have amongst the various specialities of a “UX” and arrange their time against it.

If you have a great generalist who is also a great salesperson, this model can work well. But more often I fear that we are putting our industry in a bad position by generalizing when communicating about these specialities with others. I hear designers say “I’m doing the UX” far too often when describing the value that they bring or the part of the process they are in.

The worst case scenarios result in teams jumping right to wireframes, prototypes and documentation. I see far too many UX designers that have become wireframe machines.

This approach is directly contrary to the truth of how things get made properly:

1. You must define the why before the what.
2. You must define the what before the how.

In other words, defining a solution before you understand the goal and prioritized requirements is often a wasted effort and a distraction. Whether you define everything on your own and work through the various specialities required is really not my point at all, my point is that these questions and these specialities are always needed and in some cases they are answered by different people.

Our specialists are struggling

I work primarily on large scale, systems-based projects. I am good at the defining the Why and the What. But when it comes to defining the How, I prefer to work with others more dedicated to that craft. Sometimes the user experience designers I work with struggle to understand and champion the value of information architecture. Sometimes they feel like I am taking away their fun. But in moments when they need the information architecture to be clearer, they are able to demarcate it clearly and ask me for what they need. After a few of these moments the process gets easier for all of us and consensus is more easily reached.

Why would I ever have to defend the value of IA on a team of like minded umbrella dwellers? Why do I see important steps skipped in favor of moving right to defining the How so often? I don’t think it is because I am working with the wrong people. I think it is because our industry has a long history of land grabbing of titles, processes, deliverables, and value.

Our road has been paved over by many, and driven over by many more

In the past year I have been told to change my title to product manager, design thinker, strategist, service designer, interaction designer and of course user experience designer.

The convergent nature of this industry has made our road a hard one to name, and I respect that deeply. But I don’t think the right strategy is giving up on naming it, stealing a name, or settling for a name that doesn’t quite fit.

I think this is about hunkering down and creating consensus. We need to define ourselves and our value. We need to learn to sell ourselves and the expertise of others under this umbrella. We need to remember what it is like to not understand these concepts. We need to create ways of explaining what we do that make sense outside of our silo. Lastly and maybe most importantly for our own sustainability as a field – we need to give permission to generalists to specialize.

These are important steps forward as we continue to become a legitimate field of practice. Our students, clients, heroes, and our peers deserve these levels of truth.

Our future is bright

Regardless of what you call what you do, it is a great time to be alive and contributing to this time of our industry. My greatest hope is that this is still fun to talk about when it is all said and done.

I am an information architect. One day I may be something else. For now, I see a need, and I want to keep on filling it.

The Music Outlives the Band

Written by: Robert Hoekman Jr

Parental advisory for strong language, guru deflating and semantics.   

A couple of years ago, I was asked to speak about “design thinking” at a web conference. The conference-speaking part was nothing new, but the topic certainly was. With the “design thinking” wave having just recently peaked, I had yet to even come up with a clear definition of the term. So I accepted the challenge and went about the business of putting a wrapper around the idea so I could map it to our work as strategists and designers.

What I found was a bit of a joke. The few snake-like definitions I was able to charm out of the depths of the interweb with magical flute-playing were no better, no worse, and no different than definitions of “interaction design,” which were in turn no different than definitions of “problem solving,” which we as a species have been doing since the dawn of humanity. So what was the big deal about design thinking? Well, the big deal was that some designer douchebag decided one day to rebrand “user experience,” presumably to bring his agency a few new dollars. Leader of IDEO or not (I’m talking to you, Tim), rebranding a profession for no good reason is not a noble nod to semantic precision, but an exercise in self-importance.

Besides this, it bothered me that those among us who spend our time fighting the good design fights were acting like we had nothing better to do, as if the world would solve its own problems while we were over in the corner deciding what to call our particular brand of ice cream. And it was at this point that I decided I no longer gave a fuck.

It doesn’t matter one bit what you name the band, it matters how good the music is. The reputation you build around the name will outlive even the stupidest, most drunkenly attempts at a moniker cool enough to guarantee future rock god glory.

And most importantly, while we were all busy debating syllables and word pairs, the world at large caught onto the moniker we’ve been using all along. On a near-constant basis these days, the term “user experience” is used by people whose expertise is in raising kids, or selling insurance, or milling sugar. It’s used by people who have no business even knowing what “user experience” means. It appears in dinner table conversations. It appears in write-ups about apps, devices, and gadgets galore. It’s in magazines, on television, and online.

“User experience,” as a term, is weak, ineffective, and inaccurate. But although I am among the many in our profession who believe this sad title we’ve assigned ourselves becomes less potent with each utterance, I happen to also believe we should guard it with our proverbial lives. “User experience,” like it or not, has become a household name. And the best chance any of us has at legitimizing a profession that invariably begs further explanation and qualification is to make it as easily recognized and banal as “carpenter” and “motorcycle mechanic.”

“User experience” either is or isn’t the best term to serve as the concrete beneath our careers. And we either give a fuck or we don’t. It’s our choice.

Let’s stop talking about what it’s called and start solidifying the world’s understanding of it. Some people build cabinets. Some fix motorcycles. We design sites and apps. It doesn’t matter how we do it. It matters how easy it is to accept that it’s real, it matters, and is a sound career path to describe when you meet your girlfriend’s parents over Thanksgiving dinner.

Fuck title debates. “User experience” has momentum. Let it roll, and get back to work.