Confessions of a UX Designer

Breaking Bad with UX Design

I’m about to commit a cardinal sin against the gods of UX in penning this article. My design soul will likely suffer eternal damnation. And, like Judas Iscariot, I’ll be forever haunted by the sound of thirty pieces of silver rattling about in my pocket. Forgive me father, for I am about to sin…and I have sinned.

After more than a decade of projects gone afoul, designs that never made it to development, concepts that should have never made it beyond being a concept and the snail’s pace of many projects I have worked on, this article is long overdue. I’d like to be able to write an article placing the blame somewhere other than the UX teams I have worked with. But, that wouldn’t be honest or true. It wouldn’t be a confession

At the outset, I must state there is a lot I like and love about UX and design in general. But, there is also a lot that gets under my skin. UX can be a great solution to the problems an organization faces with their products in the market. But, UX can also be part of the problem. I have often become part of the problem.

In life, I have generally found solutions do not come without cost. You often solve one problem and create another. I have seen the same thing happen with UX design in organizations. We solve a lot of problems when introduced to an organization, but often create more via our very existence.

So, I’m “breaking bad” with UX. Specifically, I’m outlining the mistakes I have made and have seen teams make — mistakes that inhibit the final product and user’s experience. In parallel, I am pushing against some of the dogmatic philosophies inherent in our profession. This article is where I see UX go awry. It’s also a short list of things that irk me about the profession. This is an article about flouting the maxims, thinking for yourself and sometimes, just sometimes, going against the crowd’s conventional thinking.

Paradoxically, these are all transgressions I have committed in my own past. My sins. These are the confessions of a UX designer.

Rules, Heuristics and Dogma

I don’t know how my mind dysfunctions. But most of the time when someone gives me a rule, I automatically question it or try to break it. This isn’t always true. Early in my career, I would follow the rules of UX to a tee. I didn’t know any better and was too green to have experiences where the rules didn’t work or to know they weren’t applicable to the situation.

We’re designers. We are thinkers. Rules are little more than cognitive offload. Now, I am not suggesting there aren’t any good design rules or there are not any rules you should follow in UX design. I am merely suggesting we think before we mindlessly follow a design rule.

Here are just a few UX rules you can find in a quick search:

• Be consistent (covered below)
• Design around real content (i.e don’t use lorem ipsum)
• You are not the user
• User research is our Golden Calf
• Humans can only remember about 5–7 pieces of information at a given time

The rules above are less rules than guidelines. Consistency for the sake of being consistent is simply being stupid as I point out below. There is a time to use fake copy and a time not to. Fake copy can actually be advantageous in circumstances when you don’t want the content to get in the way. It is generally true that you are not the user. However, there are research methods where being the user is appropriate and ads another point of data to your research. It’s called immersion. And, research of any type is only one point of data. Users do not always tell you what they need nor know what they need. And the seven plus or minus two rule is a classic example of a research study being misinterpreted or, as even Edward Tufte puts it, not read.

It seems like every week or month, a new trend starts in our profession and shortly thereafter, it will become our “golden calf” until it’s forgotten or the next new thing comes along. I get tired of rules — especially when they are mindlessly followed. I got tired of following the rules and realizing they don’t always work.

Designers don’t follow rules all of the time. In fact, they often break rules to create ingenious designs. This, of course, comes with experience. Design is part art and part science. And, great art often breaks rules.

The UX Bandwagon

About once or twice per year, I notice an uptick in the UX community on a certain topic. A few people come across an idea or concept in an article or perhaps a presentation at a conference and slowly you’ll see a larger group running to jump on the bandwagon. A few years ago, the hamburger icon became one of those topics.

The basic essence of the argument against the hamburger icon cited low discoverability, lack of recognition and lack of engagement in A/B testing, making a case users just didn’t understand or use the hamburger icon. Ultimately, the bastardization of the hamburger icon was a bit of a boring argument and was based on some pretty weak studies. It ignored the fact that an icon becomes an icon through its pervasive presence. An icon is a language. It’s a symbol representing a concept just like a letter represents a sound.

Nevertheless, a good percentage of the profession jumped on the bandwagon and bastardized the hamburger icon. Lean UX was another trend a few years ago and despite trying to move our profession out of the “deliverable business,” a brief internet search will quickly reveal we’re still in the deliverable business with plenty of writings on UX deliverables.

Mobile design is probably my favorite example. This is where teams chase that shiny object and employ a technology simply because it is there. I have been on numerous mobile design initiatives that were complete failures. Hell, even I thought some of them were a good idea at some point. But, I have been burnt so many times that I now scrutinize any proposal for a mobile design with extra vigilance. Just because you can put your design or product on a mobile device doesn’t mean it should be on one. It’s a trend teams like to embrace because all the other monkeys are doing it too. Monkey see, monkey do.

If you spend a lot of time surfing the net and regurgitating the last article you read on a specific topic (like I spent so many years doing), you’ll quickly find it isn’t much different from the current fashion you are wearing. About 5–10 years from now, you’ll look back at a picture of you sporting those new pants and the shirt you thought was so cool only to laugh at how dated you look. The UX bandwagon is no different. Five years from now, you’ll no longer believe even so much as half of what the current rage in our profession is.

Some trends will stay in our profession. Those are usually theories based on sound foundational principles — the principles of our profession from decades of research and application. They’re like 501 Levis and a solid print t-shirt. They’ll never go out of style. But, most trends will fall by the wayside. Following them will often lead you and your project astray.

As a general rule of thumb: Stay off the bandwagon, stray from the crowd and step to the beat of your own music — no matter how measured or far away. And as for those trending concepts that do stick around or seem to hold some validity — make sure you aren’t adopting them because everyone else is. Don’t build a mobile app for a user base who would benefit more from a desktop application. Don’t adopt an idea based on an article you read citing a weak study or misrepresenting a study. In short, critically and strategically evaluate the concepts you add to your repertoire.

The Little Things

I don’t know if it is a UX designer personality trait to be pedantic and detail-oriented. I don’t think so because I know a lot of designers who aren’t. But, I’ve never encountered a profession where discussions over minute details go on ad nauseam and occasionally even stop a project.

Yes, the little things count. I concede to that. And when you have the time and resources to address the little things, you should. But what I see far too often is UX teams coming unglued over the little things while they ignore the larger problems. It’s as though the house is on fire and we’re worried about the storage shed in the backyard.

I’ve had long discussions over toggle switches versus checkboxes, radio buttons versus drop menus, rounded versus square corners, save dialogs with multiple options, colors, button placement, grids and more. Long discussions. Discussions lasting weeks or months. Email threads longer than the arms and legs of an NBA All-Star.

There is an appropriate use and there are guidelines for each of these examples. And sure, if you have the time, money and resources to entertain the finer details in a design, then have at it. But if you have bigger fish to fry, your resources and energies are better placed elsewhere.

But, here is where I always land: Does it truly impact the user experience? Does the user really care whether the corners are rounded? Will that impact their experience? Do they care if all of your components snap to a grid? I’ve spent a lot of time in the field on various projects and it is rare I find a user who comments on some aspect of a feature I had discussed ad nauseam with my team. It’s usually something I never even thought of that turns out to be problematic — something we should have spent more time discussing, but didn’t.

I confess to being sucked into this in the past and even recently. I’ll get into these discussions (most of them surrounding the visual aspects of an interface) and they’ll go on forever. We’ll set up a small team to “investigate” these issues or test a group of users. But at some point, I’ll be sitting there while the discussion drones on and think about how this really impacts the overall design. Usually, it doesn’t and has very little impact on the user experience from a holistic perspective.

Always ask yourself this one question: Is this an issue, given all of the other issues I have to address, that will impact the user?

Consistency in Design

Consistency is important. But, I firmly believe the law of diminishing returns comes into play with consistency. How much time are you willing to spend with each screen to ensure absolute consistency? Time is money and will that time spent give you a good ROI?

Obviously, if you have a total lack of consistency between screens and the system doesn’t even look the same from one screen to the next, it will cause a myriad of problems. But if you are a few pixels off on button sizing from one screen to the next, will this truly impact the user experience? It’s sloppy design, absolutely. But, it won’t kill the product on release.

I’m not suggesting we ignore consistency or the little details I note above. I am only proposing a fair balance between the energy we spend on these things and the return on our investment. If you are working with Atomic Design in a large system, how much upfront work will you do versus the time you will save in designing and amending the design? If it is done right, you can probably reap a greater return on your investment. But at some point, the law of diminishing returns will take effect.

Consistency must also be contextually dependent. Consider a search component in a system. Let’s suppose you define how search should work and then state it should work the same throughout the entire system you are designing. This seems logical right? We would want search to work the same across a system and not trip the user up by switching up the functionality. The only problem with this is we have now prioritized consistency (as a primary heuristic) over the user experience.

Wait a minute, you might ask. Aren’t heuristics supposed to support the user experience? Yes. When they are used as a guide or rule of thumb they do. When they are strictly applied they may not. In the search example, a different search functionality could be warranted in different parts of a system depending on how complex the search needs to be, how many results may be returned and the size of the database being searched.

Don’t fall into the trap I have fallen into where you have screens taped up on every wall and spend weeks or months going through them with a fine-toothed comb to gain consistency. This often evolved into a major effort for me and upon release, I discovered larger items I could have been managing instead.

The context of the user’s experience should be prioritized over consistency. Component or symbol consistency in a system should not become so rigid it does not afford the opportunity to design for the context in which the user is employing that functionality. Being consistent for the sake of being consistent is often just one more way to not use your brain when designing for the user experience.

Deadlines and Release Dates

This may be more of an organizational problem than a UX problem. But, almost every team I have worked with over the course of my career has allowed themselves to be sucked into the release cycle — including myself. Yes, you have to release a product and you have to set a deadline that will allow your team to build a product with the time and resources you have. But when the focus is solely on the deadline at the expense of building a great experience and product, you have essentially sold your soul to the company store. Don’t let the deadline be the spurs that drive you forward.

I have rarely seen a project make its deadline. It happens — but not very often. That means there is room to play with a project timeline (since they are usually poor projections driven by financial concerns and put in place by projects managers who don’t understand the complexities involved in a feature or product). This means you do have the time for that research you wanted to squeeze in or that next iteration of the design.

Yet, this is really about where our focus lies and what we end up chasing in the process of building a product and experience. We often become so focused on deadlines, milestones and release dates, we forget what our true mission is. Nothing annoys me more than a project manager at my desk suggesting we aren’t going to make a milestone or deadline and we’ll be red-flagged as a result. The deadline is not the goal.

In my case, I have to constantly remind myself I am working on a patient experience. That is my “primary directive.” I am not showing up each morning to make a deadline for the next sprint. That goal is secondary. My highest loyalty must be to the patient experience.

Here’s the rub: You can meet the deadline, make all the bean counters and project managers happy and still build a shit product. I’ve done this. I have run the whole race and crossed the wrong finish line a number of times in my career. It’s not a win. It’s me sitting at the finish line wondering how in the hell I ended up here.

Stop focusing on the deadline and put your sites on the user experience. Make sure you are running in the right race and on the right track.

Tool Religiosity

If I have to listen to one more debate over design tools and how one tool is better than another, I think I might hang myself by one of my unworn neckties. I had the displeasure of working with a consulting team not too long ago who had the audacity to suggest using one tool would give our team a competitive advantage in the future workforce. Such rubbish. I don’t know if they were getting kickbacks or if they had just drank too much of their own Kool-Aid.

I grew up with a mechanic — my father. (He’s really more of a mechanical engineer than a mechanic.) But, I always remember all of the tools he had — some of which I didn’t even know what they did. There was a set of tools for every job. I learned by watching him and riding along on his trips to the Sears Craftsman store when he would need some special item. UX is no different. A design tool has a specific purpose and needs to fit the job.

Some tools are better for prototyping and others are better for visual design. You can’t beat a whiteboard and dry-erase marker to get ideas down quickly. A lot of our choices are very subjective. And, if there is any profession that should know how personal and subjective this choice is, it should be UX.

The mark of an experienced and rational designer is knowing which tool to use in which scenario. Religiosity around tools is simply dogma with no real scientific basis underlying these claims. So, stop sending tweets and writing articles debating which tool is better. If you want to make a useful contribution to the profession, write an article about a design tool’s features and how you used it in a project to solve a specific problem creating a kick-ass experience.

UX Snobbery

No one ever actually says it. But, the attitude is often evident even if unspoken. It’s often territorial. We wouldn’t want anyone infringing on our space or replacing us, right? It’s this attitude only those formally trained (or those who hold a job title with UX in it) can design.

We’ve all been there. A business analyst or a developer shows up to your desk with a rough sketch of an idea they have. And, many of us have turned our nose up to these people — effectively ostracizing them from our privileged ranks. Who are they to propose a potential solution? I’ve done this and was once a UX snob. I didn’t want anyone to do anything closely resembling my work.

Fortunately, most of us mature a little and realize this is not only a great way to develop a shared understanding, but also a method of increasing collaboration and rapport with other teams. But, I routinely encounter those insecure UX designers who believe anyone with an idea not bearing the title or training of a UX designer should be pushed out of the circle as quickly as possible. This is simply the wrong attitude to have. These are usually the same types of designers who will spend an inordinate amount of time advocating for UX in an organization and wondering why no one wants to work with them.

As controversial as it may seem (and was at the time), Jared Spool stated:

“Anyone who influences what the design becomes is the designer. This includes developers, PMs, even corporate legal. All are the designers.”

As a designer working in healthcare UX, I have generally found this statement to be true. The design of a product or service is often not rendered as I originally intended, having been influenced by other teams. Is it so far fetched to believe we build and design a product as a team through our shared understanding of what we are attempting to create? I think not.

If you are having trouble advocating for UX in your organization and looking for acceptance, ensure you aren’t a UX snob. Your career (and designs) will go a long way if you concentrate on building relationships and bringing different viewpoints (via other disciplines) to the table.