I have written UX Design meetings in previous posts (linked below) and this topic is part of an ongoing theme I have herein about communicating design.

Design meetings are often difficult to get through. I have my share of good meetings and bad meetings. Sometimes a bad meeting just stems from a difficult feature or complex set of requirements. Other times, a bad meeting can stem from poorly communicated design (i.e. bad UX specifications or confusing wireframes). But whether a meeting is good or bad, I have noticed trends over the years and they have become pet peeves of mine. Perhaps they are not exclusive to UX and rather come as a part of software development as a whole. But, they are certainly UX-related matters and seem to crop up in most meetings I attend.

Designing in the meeting

Inevitably – and in nearly every meeting I attend – there will be a number of sidetracked discussions suggesting design improvements. This is fine when it is a meeting with fellow UX colleagues. But when the the meeting is with developers and stakeholders, design suggestions are problematic. Sometimes they are good ideas, but most times they are not well thought through. These suggestions are rarely rejected for a number of reasons. The primary reason is political structure. Often, the suggestion will come from a member of the meeting who has high standing in the organization. This forces consensus because who is going to disagree with the CIO, the boss or a VP? But in a general sense, we don’t like to critique ideas in open forums. So even if the suggestion is from someone who does not hold a higher position or have any power, we still don’t always feel comfortable saying, “That’s not a good idea.” This is how bad design ideas get built into systems.

Design is a creative endeavor that takes time and requires editing, amending and iterating. Save design ideas and comments for brainstorming meetings. Meetings to approve a design should merely point out problems the UX team will have to address in the next meeting. Trying to solve these problems in the meeting ignores the expertise inherent in the UX team and, instead, places it in the hands of people who may understand the business rules better than your users or design principles.

The neverending iteration

I have a theory about designing anything and that theory is: The design is never complete. Perhaps, this is part of the perfectionist mentality instilled in me as a result of my time spent in the United States Marine Corps or my German heritage. But, I have noticed that every UX meeting I attend either results in changes or has the potential to result in changes. I believe many iterations last too long and the only reason to stop iterating in most instances is the deadline on the project.

I’m a big Guns & Roses fan – the original lineup of course. After the breakup of the original band, Axl Rose reformed a new lineup and reportedly started the recording sessions for their next album, Chinese Democracy. That was in 1998. Chinese Democracy was finally released in 2008. Axl Rose apparently had (or has) a problem with perfecting a work of art. In his autobiography, Slash relates a number of instances in which Axl seemingly took forever to develop a song. “November Rain,” for example, was a work of years.

I used have a boss who told me to get the product to 80 percent and then release it. He said you would spend forever trying to get to 100 percent and I think he was right. I think a design is never finished, never perfected. You have to go into it knowing this and avoid over-iterating a product lest you reverting to the original design as in my next point.

Reverting to the original proposed design

This happens to me on about a third of the projects I work on. We end up iterating back to something that looks quite a bit like the original proposed design. Sometimes – often times – this is a result of not avoiding my first point above. Someone will have a “great idea” and will ask for it to be incorporated into the design. Often, these great ideas won’t work. I work in the healthcare industry – a very complex environment where there are often functional reasons for why an idea will not work. In the end, it is not uncommon to undo what has been done and revert back to a version of an early design. I’d like to think this is testament to the idea that we should follow our gut instinct. But, I find my gut instinct is often wrong as well.

The best remedy for this is to avoid point one above, avoid scope creep and truly test the originally proposed design as well as all suggested changes. But, sometime it is unavoidable. What seems like a better idea takes you the long way around the barn and puts you right back on square one.

Confusing visual design with functional design and confusing both with usability

This is a meeting no-no that goes along with point one above. There is a difference between functional, usable and aesthetically appealing. Most developers and stakeholders don’t make these distinctions. Something can be highly functional, but not very usable or user friendly. Developers are mostly concerned with functionality and making something functional. Stakeholders, on the other hand, will often get wrapped around the visual design. If you have a visual design team, it is best to leave color pallets, button states, shadows, gradients etc. along with all discussions of such items to the visual design team. Those are not discussion points for the UX team in most instances unless it relates to a visual aspect that communicates something to the user. UX should mostly answer questions related to functionality and ensuring what is functional is also usable. Discussing visual design and even sometimes functionality is best left to other teams. I will often get into a rat-hole discussion with a developer about how something will function in relation to the task and then realize it is not really my problem, but rather something the developers or perhaps a business analyst should look into. Carefully delineate each discussion point in your head and ask yourself if it is really a UX matter. If it isn’t, move on to the next item.

Forgetting that it is not about you and is about the user

This last point is something I have to constantly remind myself of. Sometimes getting a design approved seems like more of an act of warfare than a business process. The design gets critiqued. You get offended. The developers are upset because the proposed design means a lot of work for them. The stakeholders are not happy because their suggestions were not incorporated into the final product. These feelings are all a result of losing focus on the user. It isn’t about you. In the words of James Carville: It’s about the user, dummy.

At the end of the day, everyone is on the same team and if your focus is not to make the best product you can for the user, you will fail. Getting wrapped up in your ego and forgetting the user will ultimately doom any UX project. So ensure there is a user somewhere in your UX.

Keeping these points in mind may help you manage your UX meetings more effectively. At the very least, they will help you maintain your sanity.

See also:

Six tips to survive UX design meetings

Five essential elements in presenting UX design

%d bloggers like this: