The popularity of Agile has hastened the downfall of the siloed, waterfall work approach and the growth of team collaboration. Everyone now contributes more actively throughout the entire process of creating a product, which allows team members to be more honest, raise serious issues sooner in the process, discuss issues more openly, and be open to prioritization. Without a doubt, Agile has improved team communication.

However, when collaborating and creating a solution together, we sometimes forget what ownership and responsibility means – particularly for design.

Design has been evolving to be more about collaboration and less about heroism, less about making things beautiful and more about solving a problem and meeting a need. Many things can be designed, from databases to architectures, but the visual side of things, including the user experience, gets a lot more attention – often more than it should. 

People who have ears think they can sing; people who can write a sentence, believe they can write a novel; people who can taste believe they can cook; people who have eyes, believe they can design.

Everyone has an opinion, and that's healthy. However, the reality is that some opinions are based on more facts than others, and this comes through with user experience more than anything else. Many visual aesthetic opinions are based on personal taste and experience – as if that is the best and only experience – rather than studies about an audience or the industry.

And sometimes too much attention is given to user experience. Sure, it's important, but a poorly architected system can ruin a great idea. The user experience gets a lot of attention because it's the first thing most people see with a product. And everyone wants to be a part of creating what people see. When people work in manufacturing (and these days, software is manufacturing) they want to say what they contributed to a project – and it's easier to point to a button than to an optimized database.

A key factor of successful collaboration is respecting your teammates – their views, experiences, and areas of expertise. It's about recognizing the knowledge each person brings. This is easy to lose when discussing an interface. Team members can get very passionate about design opinions and directions or word choices. All of these discussions are great, however, they come with limits. If there is a UX team, you have to let them provide suggestions and recommendations and give feedback as to why suggestions may or may not work. And these types of discussions need to be facilitated to stop a single loud voice taking over.

This is more of a guide based on my experience with teams and facilitation as to what needs to happen during these discussions and the process. Feel free to add and comment as needed.

What should be kept in mind when facilitating product brainstorming/discussions

Dos

Focus on goals of the project and what is needed

Rather than over-defining specific solutions to a problem, which limits brainstorming and keeping all options open, talk about the project goals – what the product is and what needs to be achieved. Sometimes as a team we get too tied up in the details rather than understanding what the solution needs to do.

Team members need space to come up with solutions and recommendations

Not everyone thinks well on the fly.

After brainstorming sessions, let the team members take back the suggestions, recommendations and ideas and work through options. Discuss project directions at the meeting, but don't make team members make a decision – let each one determine whether a particular solution makes most sense after the conversation. Sometimes there is pressure in a team environment NOT to make the best decision but to pacify the loudest voice. Brainstorming needs to be supported by work time; without this balance, good ideas aren't fully vetted.

Respect your team members.

Respect each individual's skill sets and ownership in discussion. I have taken a number of database design courses to know enough to be dangerous, but rather than ask "How did you design the database? Can I see?" I'll ask "What is the primary key? What data are we capturing?" It's not my job to tell the database person how to do their job. I can ask for data, but it's just inappropriate for me to ask them to revise their setup. I may know what I could ask for, but I'm not responsible for creating the database and I trust in the database developer to make a great product. The same is true with the visual side of things. Designers have experience and data to back up why certain decisions are made or why some directions are better than others. I admit that I always like getting suggestions and feedback to make a great design. But I will also admit that I don't care for suggestions that start with "I like" or "I prefer". That's based on one individual's experience – not an entire group. Personal preference shouldn't be part of the conversation. If someone suggested that a particular UI element performed well in testing – well, that's a different story.

Express your feelings in a positive, constructive  way

If you are frustrated with a conversation, tell your team! Be honest with them and tell them why you are frustrated. For all you know, they may be frustrated with things too. Don't tell your team that they are a bunch of dumb monkeys – that's not constructive. Telling your team you are frustrated because the conversation is circling and you don't know how to fix it – that's helpful, and not just for you.

Oh – and if you think your team rocks, tell them that too. And tell them why you like to work with them. It's always nice to hear that you are fabulous, but it's better to hear that you are fabulous because you get to the point and get things done. 

Know who is consuming the design

Unfortunately, your team members are NOT part of your user group. Even the UX person isn't part of the user group. The UX individual represents the users and what they want, but even his or her opinion is irrelevant when it comes to what the final design should be. Decisions should be based on research, facts, and references to what performs well from site to industry. No one on the team is a user – so their opinions based on person preference, well, just don't matter.

Test test test

Get real data – not opinions. When we design with team opinions we are designing for ourselves – not our users – and I just established that our team isn't a user. The users need a voice and the only way we can do this effectively is to test. Test. And test some more. We need to get their feedback as if they were a team member.

Don'ts

Voting doesn't make a good design

Voting on design is probably the worst way to handle a design discussion. It removes discussion about the project goals, sets-up an us/them team environment, and introduces personal preference into the discussion. Let's face it – we don't vote about approaches to the technical architecture; we don't vote on roadmaps; we don't vote on budgets. Stop voting on user experience and visual design. It really doesn't solve any problems – in fact, it creates more problems because solutions that are slick rather than functional win, and more work will often need to be done to make the slick design actually work. Keep the discussion to user feedback and facts.

Make final decisions on the fly

When teams are stressed, they often will try to come up with a solution on the fly. However, this means that some team members are having input into a decision where they didn't consider all factors. The team really needs to go back to their desks and think thru all of the options and ideas. This also refers to how a group sometimes will pacify the loudest person rather than the right person. Making decisions on the fly is just a recipe for disaster.

Override points from other team members based on power – not a debate on facts

By overriding a point made from a team member based on your position, you broke the Do rule – you no longer respect your team member. Everyone has ideas, and some ideas are backed by facts and an understanding of the users, but all ideas potentially could work. It's about being open minded, especially because even bad ideas could lead to the optimal solution. 

Focus on opinions and not facts

This goes back to previous points about basing UX decisions on data and experience with users. Sometimes we get caught up in what we like and prefer for an interface and forget that we are not designing for ourselves. We really should be talking about the facts and how the design meets the needs of the user.

Lose respect for a team member

Discussion and collaboration bring various teams together. There are people on the team with more experience with design than others – so yes, some opinions do count more than others – and that should be respected. But this is the same for architecture, budgets – some team members just know more than others. And that's what makes a team. Respect your designers as much as your developers or project owners. Everyone has something to contribute. And if there is a weak team member – give that person a chance. You just never know what may happen.

Gossip

This just kills team morale and discourages collaboration. If you don't agree with your colleague, tell him or her directly. Keep it real. See the previous item about respecting your team.

In our new world of collaboration, we need to maintain a delicate balance where we are open to new ideas no matter where they originate from and yet respect the source of the idea and the person who will be doing the work. It is a crazy juggling act, but if you follow the do's and don'ts outlined above when collaborating, you will have a project with a happy, productive team.