9 Ways to Improve Your Design Meetings

This is the second article in a series of articles where I am exploring presenting and communicating design in UX meetings. In the first article, I explored the common mistakes we make when presenting design to audiences and attempted to lay a foundation for how we must think and approach UX design meetings. In this article, I will explore how to push your design forward in meetings using 9 methods.

In the last article of this series, I primarily focused on a single theme in design meetings and presenting design – keeping on track and the mistakes that can derail a design meeting. I generally wrote about high-level meetings or those meetings where you are presenting a final (or close to final) design. In this article, I am mostly going to focus more on those meetings where you are just trying to push the design forward from an initial state. However, most of the content in both parts of this article can help in various stages of the design process when presenting your designs to a larger audience (i.e. business, developers, product owners etc.).

I am most concerned in this article with the design project that isn’t moving forward or is moving forward to slowly. We have all been there. The design or feature you thought was a slam dunk has now become a nightmare of epic proportions with meeting after meeting. Or maybe you are still stuck with a blank page. The following techniques are methods I employ to get through the epic meetings and attempt to push the design forward.

Anticipate the arguments

Take some time before the meeting to consider where you think people will stumble in understanding your design. Sometimes it’s easy to spot where your stakeholders will get tripped up. Sometimes it’s harder. And, sometimes anticipating these arguments just comes with a little experience.

If you have the luxury of time, attempt to put a little distance between yourself and the design. This allows you to come back to it with a fresh set of eyes…or as fresh as they can be considering it is your own work. You can also show it to your team (if you have one) to discover any stumbling blocks.

Anticipating arguments you might receive against a particular aspect of a design allows you to formulate a strategy for a counter-argument. It also allows you to question why you might have chose a certain direction with a design. Occasionally, I find this exercise helps me ferret out those areas where I was moving in the wrong direction. You can sometimes think of this as a self-editing method.

Delay the debate

There are arguments you will not be able to anticipate. They will come up in the meeting and they will quickly become the sole spotlight of a meeting. They will essentially derail your meeting and prevent you from covering the subsequent points your were going to make in the meeting.

Learn how to identify these “circular discussions.” Often, they are great discussions and I am not suggesting designers should necessarily close these discussions down. But, you must be able to recognize when the discussion has gone on too long. There was a designer I once worked with who called these “rat-hole” discussions. Essentially, he meant the team would fall down the rabbit hole in some discussions.

When you determine a discussion is not going to result in a solution, it’s time to delay the debate. At these points, I often say: We are not going to solve this problem in this meeting. I then direct my team to move on to the next aspect of the design and assure everyone in the room UX will tackle this problem at a later time coming back with a solution. I also ensure I am specific on when we will come back with that solution.

This tactic allows you to delay the debate and gives you an opportunity to work through a solution in a less pressured environment (and with less contradicting voices). It also allows you some breathing room to think creatively about the problem. I have often gone for a walk to think about a problem and realized it wasn’t really a problem. And, I have often come back with some sound design principles or a good reason as to why we should stick with the original design. Even more often, I have realized the voices of dissent were correct and have been able to come up with a better solution.

Confusing visual design with functional design and confusing both with usability

There is a difference between functional, usable and aesthetically appealing. Most developers and stakeholders don’t make these distinctions. A design can be highly functional, but not very usable or user friendly. Conversely a design can have a high aesthetic value, but not be very functional or possess a high level of usability.

Developers are mostly concerned with functionality and making something functional. Stakeholders, on the other hand, will often gravitate towards the visual design and aesthetics. If you have a visual design team, it is best to leave color pallets, button states, shadows, 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 ensuring what is functional is also usable and enhances the user experience.

Discussing visual design and even sometimes functionality is best left to other teams. I will often get into a rathole 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 and tell your team you need to get the right people in the room to discuss those finer points.

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

This is another element in presenting and iterating designs I have to constantly remind myself of…and have screwed up so often. 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 or product owners are not happy because their suggestions were not incorporated into the final product. These feelings all result in a loss of focus on the user. It isn’t about you. It’s about the user. Check your feelings at the door and keep in mind you are all working towards the same goal – to build the best product you can for the audience you serve.

The design is not you. Sure, it’s your idea and you put a lot of hours into it. But, it is not you the client is critiquing. Having your ideas critiqued can sting. But, if you can check your ego at the door and understand that not all ideas (or designs) will be winners right out of the gate, it will be easier to get through harsh critiques.

I often go into a meeting and open it by stating: “We have an initial design and set of concepts we’d like to present for your feedback. We need to figure out what we got right and what we will need to change. Can you help us?” (Notice I use the word “we” and not “I.”) Go into the meeting with that attitude and you’ll find that you are able to listen in a detached way and are better able to iterate your design.

Develop good listening skills, ask questions – even when they are dumb and especially when you think you know the answer

Language is elusive and can mean different things to different people. I have been in meetings where the entire room walked out and I later discovered we all had a very different interpretations of what was said in the meeting and what was meant. This happens because language, ideas and concepts are naturally filtered through our world views and professional experiences.

You should get in the habit of employing a tactic used in journalism and education where you repeat back what a person said or “teach back” what was said in order to extrapolate true meanings. So, if a client states the interface should have a day, week and month view, dig deeper into that by repeating back to them what you heard and asking them about each individual view. (You might want to also ask why those views are important to the user because you will probably learn something more about your users that you can later validate in research.)

We often, in conversations and meetings, attempt to finish sentences for others. I catch myself doing this all of the time and it is a natural habit in how we communicate. But, it is our listening skills that help us the most in design meetings. Focus on asking simple questions and listening to the answers – truly listening. Even if you think you know the answer, one of the best questions to ask in a meeting is simply: “Can you tell me more about that?” Sit back and listen. You will often discover a different answer than you thought you would.

A picture is worth a thousand words

It is natural to go through several meetings talking over a software solution. But, you can shorten the number of meetings by sketching quick interfaces and talking through them with the stakeholders or people close enough to the project who will know. I do a lot white-boarding here at Walgreens – a lot of white-boarding.

Showing a picture to someone breaks down the barriers we have in language and helps us get to a common tongue. You figure out really quick what you are thinking the interface should do and look like and what the other person is thinking. Gaps are quickly discovered and you can move forward in the iteration.

Don’t spend a lot of time in software at this stage. Use pencil and paper or a whiteboard to sketch out ideas (see below). No one reacts too much to requirements. They will react to design. It’s actually a bit amazing. I have been in hundreds of requirements meetings and have never seen a group of people get as passionate as they do in a white-boarding meeting or design review.

Requirements are not meant to be readable or sometimes even understood. So don’t feel bad. They are written from a different perspective and will sound foreign to you. Figuring out how to wade through them involves sketching out your interpretation and showing it to others. Or, just spend a lot of time at the whiteboard. Which brings me to…

Use the white board copiously and use it early in the design process

A cliche I know, but fail fast and do it early. The best way to do this with design is to sketch out ideas. Run around to people’s desks with a white pad of paper and a pencil if you have to. But, the best way to ensure you are on the same page with your clients or stakeholders is to begin sketching early in the process to align your mental model with what is required. This also saves you a lot of time building complex designs using something like Axure or Sketch and gives you an opportunity to solidify a design before making the time investment required to build wireframes and prototypes.

I’d like to pause here and offer a thought that may, perhaps, be a bit counterintuitive. One of the best strategies to get through design meetings is not to have as many of them. Don’t get me wrong. I think collaboration is great and welcome it. But, there is such a thing as having too many meetings and I believe many organizations have far to many meetings and make far too few decisions. And, that is where I am coming from with these next two items.

The never-ending 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 creatives and designer. 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 years upon years of work. (It is a great song though.)

Avoid the never-ending iteration. I used to 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 revert back to the original design as in my next point.

Reverting to the originally 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 or concept. Sometimes – often times – this is a result of not avoiding my point above concerning the never-ending iteration. 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 technical 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.

The best remedy for this is to minimize the amount of deliberation your team goes through in the design process. Sometimes this is difficult if you are a team of one or a UX team with little weight in the organization. If that is the case, you might be in the wrong position. But as is often said, the only thing worse than making a bad decision is making no decision at all and stringing a feature out far longer than it needs to be – especially when you don’t make any progress.

These last two points are about establishing clear goals and outcomes for meetings and avoiding meetings where the action item is to have another meeting. Style guides and design principles will surely help. But, not nearly as much as nailing down a clear timeline for the feature and goals or establishing outcomes for a particular meeting.

Meetings are meant to gain alignment and make decisions. There is no other reason for a meeting. Even collaboration is about alignment. That is your job as a UX professional. You are similar to a politician or sales person (see my first article concerning this). Ensure each meeting pushes you closer to a final design.

Keeping all of these points in mind may help you manage your UX meetings more effectively (or avoid having too many of them). At the very least, they will help you maintain some of your sanity as you trudge your way through the organizational jungle of meetings, opinions and lack of direction.

Feature photo by rawpixel.com on Unsplash