Three Lessons About Conflict on Design Teams

I would like to take a look back on my first real conflict on a design team and document what I learned in an early stage of my career. I was in a UI/UX program, on a four-person team and we were creating a product for our first live client. Adrenaline and anxieties were high, but so was the excitement of taking a product to market.

The platform, which I will refer to as “Bridge”, is designed to help international students to the U.S. organize all the steps necessary for internship and employment eligibility. The founders also wanted the design to simplify confusing timelines and clarify deadlines for the international students. They would finally be able to see and complete their government forms and get expert help, all in one place, in order to begin a career in the United States.

The project team and I worked together the previous month and developed rapport and efficient workflows. . For example, we developed a successful system of task delegation , and, importantly, everyone seemed to be growing in their skills and maintained mutual respect for one another within the system. Granted, there were those in the group who clearly wanted to take over everything at certain points, but I quickly learned to speak up and take on responsibilities in areas where I wanted more experience, for example, designing a complicated categorization and filtering system for the site we were building.

We approached delegating tasks with Bridge in much the same way. After mapping out the essential user steps for each section of the site we would be building, we voiced which section we wanted to design and got right to work.

Lesson #1: If you neglect the basics, you will have unnecessary conflict.

Do not reinvent the wheel when designing. Always start with the basics and refer back to them often. A design system must be created for every single project. This includes design principles, the design process your team will follow, and a style guide as soon as possible.

Our client gave us a style guide that had been created by a previous team along with HiFi wireframes for a few pages of the site. We naively thought that running with those artifacts would be easy and not require as much time spent on a design system of our own. We couldn’t have been more wrong.

As half of us started to simplify the UX on the dashboard, we were changing almost all of the UI as we went. Another team member, meanwhile, was researching a long government form and designing screens for it, while the 4th member was creating a message board. We had no style guide at this point and two weeks later, this would cause a major breakdown.

We were making good progress with the UX, but the UI elements were glaringly disparate. Those with the more dominant personalities did not want to give up a single pixel of their screens for others to make design decisions and none of us were in agreement on what looked or worked best. It was halfway through week three We had ten days to finish.

Lesson #2: Know the essential criteria for making good design team decisions.

“Decisions made by the design team must meet two essential criteria:

  • It must meet the goal of the project.
  • It must move the project forward. ”

-Conflict In The Design Process

These criteria should be kept as top priority especially during conflict so that the team can quickly determine which design decisions are actually worth debating, and which disputes aren’t going to help move the project closer to MVP.

We were not meeting the goal of the project nor moving the project forward because of two things:

  • We had bypassed clearly laying out our own design system.
  • We were stuck on decisions because of who wanted to make the decision, not because that particular decision would help us meet our 2 most important criteria.

I called for a meeting with our head instructor and laid out to her the mistakes we had made, why we were stuck and asked for guidance. It was clear we needed a style guide for every single element, laid out within a day or two. My instructor asked if I would be willing to be the UI lead. I felt a bit inadequate compared to others on the team. I also knew this would highly frustrate them, but that by having a UI lead we would meet goals and move the project forward, so I said yes.

Lesson #3: Sometimes you get a much-needed opportunity to learn something new … with everyone watching.

It was my first time creating a style guide and I was nervous. What if my teammates didn’t like my final decisions? Would I be able to defend why I made the choices I did? Some of my team members were more experienced and more talented than I was. During this pressure, my personal and professional experiences helped me understand that the best thing to do — the thing that would get us to meet the goal of the project — would be to create and polish the UI elements one by one without second guessing. This would move the project forward.

It took a couple of days for our team to get back into a groove. I put the style guide together, getting all the elements, icons, buttons, bars, fields and typography tidied up and changed where needed. Teammates and I went back and forth some over a few things, but we didn’t drag things out like we had before.

The UX improved dramatically in two major sections of the site once team members were no longer trying to balance designing the user flow and user interface at the same time. After making key changes to the layout and elements in the government form, everything was looking much more cohesive. Our client was enthusiastic about the progress.

Experiencing conflict on a team is unavoidable. The better the project, the more necessary this conflict is in order to make the best design decisions. When tensions are high and your project halts, do whatever you can to get the team focused on what will meet the goal of the project and move it forward, even if you have to learn something new in front of everyone.